Category: Blogs

Over the last few weeks, I’ve been in discussions with several companies and the same problem occurred: my contacts raised a change that they were looking to realize in their organizations and asked me for help to realize it. When I asked how they had ended up in the situation that required the change, most were stumped – it was clear that this had crossed their minds.

Of course, as engineers, we’re trained to think in terms of solutions and many of us follow that training to the dot. However, developing a solution for a problem that actually is a symptom and the consequence of something else is entirely useless as the likelihood of the solution solving anything is about as high as the survival chances of a snowflake in hell.

For example, several R&D departments want to introduce continuous deployment or DevOps in their company but run into strong resistance from sales and customer support. Many lament that the people on the other side of the fence just don’t get it. However, when analyzing the situation, it’s obvious that the introduction brings along significant cost and a fundamentally different relationship with customers. And without a business model to monetize the continuous value delivery, there’s no point in adopting DevOps. So, rather than stressing that the folks on the business side are idiots, work with them to figure out how to create business models and customer engagement models that make sense and then work with lead customers to experiment with this new model.

Many know the “rule of 5 why’s”: the notion of, after observing a problem, asking “why” five times to go from the observed symptoms to the actual root causes. The challenge is that in practice, this rule is followed not nearly as often as it deserves.

A related and subsequent challenge is that even if we’ve identified the root cause and we have an idea to solve it, there’s huge resistance in the organization to actually implement everything that’s needed to actually make progress. Instead, there’s a tendency to support the implementation of something small enough to make it palatable for all in the company. The result frequently is a watered and scaled-down proposal that gets broad support but that offers little more than a token effort with little real impact on the company. As a general observation, my experience is that the more politicized an organization is, the more it tends to focus on symptoms instead of root causes and the more it tends to focus on watered-down change initiatives that create the illusion of action but don’t result in any genuine change.

My advice is obvious. First, use your intelligence and experience to develop a solid understanding of the root causes underlying observed phenomena. Don’t fall into the trap of believing what everyone else believes. Second, use your social and interaction skills to confirm your understanding with others and to build a common platform of a root cause focused understanding. Third, once you’ve established a common understanding, explore multiple (rather than only one) avenues to address the identified root cause and build a platform for the one that has the required impact while minimizing collateral damage. Fourth, when sufficient agreement is in place, move forward with execution in an iterative, experimental manner where you take one end-to-end slice of the organization through the change, observe and measure the impact, adjust accordingly and proceed with the next slice. Throughout all this, find the right balance between driving and being committed to realizing the change and an objective, reflective attitude where you’re able to identify the downsides of the change and the need for adjustment where necessary.

As the Buddhists say, the difference lies in the small window between trigger and response. Rather than instinctively reacting to what life throws your way, pause, reflect and decide on a course of action that actually results in what you’re looking to accomplish. In other words, think rather than react.

Recently, I expert-facilitated a workshop at a company having the desire to become data driven. Different from the product companies that I normally work with, this company is a service provider with a large amount of staff offering services to customers. The workshop participants included the CEO and head of business development, as well as several others that are in or close to the company’s leadership team.

In many ways, this looks to be the ideal setup as one would assume that we have all the management support we need and some of the smartest people in the company with us. This was even reinforced by several in the company sharing that they’ve been working with data for quite a long time. Nevertheless, we ran into a significant set of challenges and we didn’t nearly get as far as we’d hoped.

The first challenge was becoming concrete on specific hypotheses to test. Even though we shared concrete examples of hypotheses and associated experiments when we kicked off the brainstorming and teamwork, everyone was having an incredibly hard time to go from a high-level goal of increasing a specific business KPI, eg customer satisfaction, to a specific hypothesis and an associated concrete experiment. There are many reasons for this. An obvious one is that many people feel that ‘someone’ should ‘do something’ about the thing that they worry about but never spend many brain cycles thinking about what that would look like.

The second challenge was that, for all the data the company had at its disposal, the data relevant in the situation at hand was frequently unavailable. Many companies I work with claim to have lots of data and many in the organization get really surprised that ‘just’ the data they need hasn’t been recorded. When you reflect on it, it’s obvious that this would be the case as the number of hypotheses that one can formulate is virtually infinite and, consequently, the likelihood of data not being available is quite significant.

The third challenge we ran into was that even in the cases where the data was available, it turned out to be aggregated and/or have a too low frequency of recording to be relevant for the purpose at hand. So, we have the data, but it’s in a form that doesn’t allow for the analysis that we want to do.

The response to these challenges is, as one would expect, to go out and collect what we need to pursue the experiment to get to a confirmation or rejection of the hypothesis. The funny realization that I had is that the more relevant and important the hypothesis is from a business perspective, the more likely it relates to regulatory constraints that limit what can be collected without going through a host of disclaimers and permissions. So, we ran into the situation that several of the more promising hypotheses were not testable due to legal constraints.

Finally, even if we had a specific hypothesis and associated experiment and we were able to collect the data we needed, it proved incredibly hard to scale to the point of statistical significance. Running a large-scale experiment that has a decent chance of failure, but that’s very expensive and risky to run kind of defeats the purpose of experimentation.

Becoming a data-driven organization is one of the highest-priority goals that any company should have. It allows for much higher-quality decision-making and operations while preparing for use of AI as a key differentiator and enabler. However, going from word to action is a challenging journey where, ideally, you learn from other people’s mistakes before making new ones yourself. We need the data, but we need to be smart in execution.

Soon after the introduction of agility in software development, the notion of business agility was introduced as well. The basic idea was to scale the concepts behind agile software development to larger scopes, with the ambition to reach the entire organization, including R&D and IT. In practice, however, for many organizations, it proved difficult to go beyond the software part of the organization and things often got stuck at DevOps. Also, the basic mindset often was to treat changes as disruptions in a steady-state system, focused on returning to a steady state as soon as possible. Agile was concerned with minimizing the impact of changes by rapidly responding to them. The notion of business agility was very popular around 2010 and then started to fade as it didn’t provide the benefit that companies were looking for. To quote a manager in one of the Software Center partners: “We use Safe and say we’re all agile but we didn’t change a thing…”

More recently, we can see a development that’s not entirely dissimilar to the first incarnation of business agility (1.0) but that has a number of unique characteristics and is leading up to a 2.0 version of business agility. This version has, at least, three unique aspects: business models, technology scope and fast feedback loops.

First, many companies have started to realize that agility at the business level starts with the business model that you employ. It has to start with a transition from a transactional to a continuous model. If you build the capability to deliver value to customers but don’t have a way to monetize the continuous value capture, there’s no business incentive at all. If you improve the product, system or offering along some dimension, you need to be able to capture some of that value. For instance, if you run a truck company and you conduct A/B testing on the engines of your customers in the field to improve fuel efficiency, you want to capture some of the savings that your customers are enjoying. Why else would you bother with experimentation in the first place? So, whereas business agility 1.0 started bottom-up with the software development teams, the 2.0 incarnation starts top-down from the business model.

Second, in the embedded-systems industry, there’s a growing awareness that continuous deployment or DevOps doesn’t need to be limited to software. Under the right incentives and business models, it’s entirely feasible to periodically update electronic and mechanical parts of systems in the field to improve system performance. Among others, Tesla offers chip upgrades and hardware retrofits providing significantly improved capabilities, which the software can then use to improve the functionality in the car. So, business agility 2.0 doesn’t just focus on software but extends to electronics and mechanics on the one end and includes data and AI on the other.

Third, the focus in business agility 2.0 is on fast feedback loops across the company and all technologies. This has two aspects. First, each technology has an optimal feedback length where the customer and business benefit of new releases are balanced with the cost of manufacturing, distributing and installing. This of course means that software (including AI models) can afford to have very fast cycles as the cost of distribution and installation is very low and there’s no manufacturing cost. For electronics, especially when keeping the mechanical interface constant (pin configuration, power usage, EMC, and so on), the cost is higher and perhaps a yearly or biannual cycle makes the most sense. Finally, for mechanical parts, the update frequency should be even lower as they’re even more costly to manufacture, distribute and install. Still, when the continuous business model has liberated you from the “let’s save all improvements for the next product” attitude, also improved mechanical parts can be distributed, say, every three to five years.

Business agility 1.0, digitalization and business agility 2.0

The second aspect is that no slower cycle can slow down the faster cycle. Traditionally, the software release frequency was bound to the product release cycle. In business agility 2.0, no faster cycle (software or electronics) can be slowed down by a slower cycle (eg electronics or mechanics).

We’re entering the era of business agility 2.0, which starts from the adoption of a continuous business model and then optimizes the entire company to capitalize on fast feedback loops that allow for all technologies in products to improve at their own pace. Even if your customers aren’t asking for it yet, your suppliers are complaining and your partners aren’t yet ready to play ball, you better get going on this as the second incarnation of business agility provides major benefits, as well as improvements in efficiency and effectiveness that you can’t do without. Go agile, but go 2.0!

Last week, we had a strategy workshop at Software Center, the public-private digital transformation acceleration partnership that I lead. During one of the breakout sessions, we had a fun discussion around business agility that illustrated a very recognizable pattern. In a discussion around how to realize business agility, the focus was on who could be considered to be responsible for it. And then more examples of various people and roles abdicating responsibility were shared than you can shake a stick at.

In many ways, it has been the journey of Software Center. We started to work with software engineers around Agile practices, but soon the engineers mentioned that the architects should be involved as agility affects architecture as well. Once we had the architects involved, soon the requests came to involve development managers in the discussion as those are line managers to both engineers and architects. The development managers of course soon asked to involve product managers because they were just telling their teams to build what product management requests. It didn’t take long after we got product managers involved until they started to complain that we needed to involve the salespeople as whatever we were doing on the product development side had to be sold by them. The salespeople immediately remarked that if we wanted to change what we were selling, we had to get the C-suite involved as it would have a material impact on the bottom line. And the C-suite, obviously, responded with the argument that our customers weren’t asking for it and that our suppliers and partners weren’t willing to work with us on realizing these changes.

What’s going on here? Well, it relates to a column that I shared some months ago: to change anything, you have to change everything! And it aligns perfectly with our instinctive desire to keep things as they were and to control our environment to the maximum extent possible.

There’s an additional perspective though: the R&D organization in most companies that I work with considers itself to have the duty to build what the business side of the company asks for. The problem is of course that the business side doesn’t know what it wants until it’s blatantly obvious what’s needed and then they want it immediately. The new requirements from business often come up late and demand an immediate response from R&D.

The reality is that in practice, it’s the R&D organization that sets the business strategy for any organization. The design decisions taken by key people in R&D make certain business opportunities impossibly expensive to pursue, in terms of cost and time, and other business opportunities are easy and fast to realize. For all the talk around agility, realizing any significant architectural change in a large, established system takes a long time, often measured in quarters and years. The consequence is that it’s the responsibility of the R&D organization to predict the most likely business strategy options that the company will pursue a year or more down the line and prepare the system architecture for this.

This means that if you’re in R&D, you need to take responsibility. It’s your job to have a clear idea of what the future may look like and ensure that you’re creating a future for your company while delivering on today’s challenges. It’s critical to be ambidextrous and to balance the short and longer term. Most organizations rapidly build patterns for this, with a tendency to focus on the short term predominantly. It’s your responsibility to not blindly follow the established patterns but to continuously question the status quo. As Andy Grove used to say, only the paranoid survive.

In most organizations, there’s a tendency to use excuses to explain why certain changes aren’t realized. One of the most effective excuses is to abdicate responsibility and to point to others in the organization as being responsible for holding you back. As the saying goes, your comfort zone is a beautiful place but nothing ever grows there. It’s up to each of us to shoulder the heaviest responsibility we can carry and to step into an uncertain, unpredictable future, taking calculated risks and delivering for today and tomorrow. It’s up to you!

There’s an interesting development going on in the embedded-systems industry. Initially, data was only used for internal purposes and quality assurance. Customers would send log files to product companies who would analyze them to figure out why the product wasn’t operating as it should and what to do about it. Over time, the periodic data sets have turned into more or less continuous data streams and the data collected has evolved from being concerned with QA to focusing on product performance and measuring value delivery to customers.

As the volume and expenses associated with collecting and storing data have increased, companies have been investigating ways to create novel value from this data through direct or indirect monetization. We can identify at least four phases that companies go through.

The first step is where the company gives the data away as part of the overall product offering. Typically, the data is processed and provides nice dashboards for customers to gain an understanding of the product’s performance. However, as the customer gets this for free, there’s limited focus on the data part of the total offering. This is similar to how, in many industries, software was given away for free as part of the mechanical or electronic product. We’re now getting paid for software, but many are now giving data away for free.

The second step is where the company has developed some form of data-driven service to customers using the data from each specific customer. Here, the first monetization of the data starts and even if it often is a minor revenue stream, both customers and the company itself are now, in fact, benefiting from the collected data.

Once the second step is in place, often customers ask the company how they perform when compared to others. This is where the third step is initiated as it allows the company to provide data-driven services to customers using data from all customers. Now, customers can benchmark themselves and understand where to improve and where to extend their lead over competitors.

The fourth step is where the company moves to find alternative markets/customers for the data from its primary customer base. Here we see the start of a two-sided market where the primary customer base generates the data that is then monetized with a secondary customer base. If played right, this can allow the company to transition from a product to a platform company and to ignite a thriving business ecosystem where the company can ‘tax’ transactions between ecosystem partners and thus create highly profitable revenue streams that, in time, may outweigh the revenues from products.

In our discussions with companies in Software Center, there are three main challenges that companies struggle with, ie pricing, disruption risk from suppliers and partnering. The first challenge, pricing, is simply concerned with putting an actual value on data sets or data streams. The preferred model, though difficult to execute on, is value-based pricing, meaning that you estimate the value that the receiver of the data gets from it and then negotiate a fair share of that value.

The second challenge is that product companies are constantly asked by suppliers for data. Initially, this concerns data from the subsystem provided by the supplier, but over time, it tends to broaden and cover a larger and larger scope. The risk becomes that, with enough data, suppliers can become powerful competitors in data-driven services. They often serve multiple companies in the same industry and if they manage to negotiate data from all of them, they’re much better placed to generate a competitive advantage. Of course, many companies have little interest in this, but finding the right balance between sharing and avoiding creating a new competitor is a difficult one. The best practice seems to be the insertion of a control point, meaning that you can cut off a supplier at any point in time when it becomes clear that they’re starting to compete with you.

Finally, even for potential partners from other industries that are interested in gaining access to the data collected by the company, it’s often very difficult to decide which of these potential partners are worthwhile to participate with and which ones should be ignored. There are few generic guidelines here, but in general, a potential partner that can help you build a two-sided market and, in due time, become a platform company is much more valuable than alternatives.

The embedded-systems (or cyber-physical-systems) industry is becoming increasingly aware of the importance of data but is struggling with operationalizing this awareness into a solid business. I’ve outlined the typical pattern that I see companies follow, as well as the key challenges experienced. Engaging in data is very difficult for companies that still think of themselves as metal-bending experts, but it’s critical to get going. Not using your data, or just giving it to someone else to build a business around, is the worst thing you can do. For all the risks and challenges, in a digitalizing world, you need to be world class at software, data and AI and the only way to achieve that is to experiment and learn. Go digital!

A senior engineer asks:

I manage a team of engineers in terms of content and in doing so I get stuck quite often. For example, I think one of my engineers should do things differently, but I don’t get through to him with my criticism. I worry that I will have to redo the work later. How do I get the engineer to listen to my criticism?

I also have a colleague from whom I need information. I have already kicked his ass a couple of times, but to no avail. I am fed up with it. Because of this irritation I’m afraid that if I say something about it it won’t come out ‘nicely’. How do I deal with this?

The communication trainer replies:

In both situations, it’s all about giving feedback. In other words, telling someone what you think, with the goal of improving behavior. This is a tricky soft skill, especially when it comes to negative criticism. Two pitfalls come into play here: you avoid the issue, which means the message does not get through to him/her, or you are too blunt, which damages the relationship. We often choose to avoid these pitfalls by just not saying anything. Of course, this does not make the problem go away. Even worse: it becomes worse. It is even the case that if you open your mouth after long delay, your pent-up criticism will indeed come out too unsubtly. So, what you wanted to avoid is actually created, namely a discussion that leads nowhere.

If you’re not careful, you draw the conclusion that ‘saying something about it’ next time is not a good idea either. The threshold for giving feedback thus becomes higher. This is bad news, because, as human beings, we can only learn by receiving feedback. If we are not aware of what we are doing and what the effect is, we cannot adjust our behavior to what is needed. In short: if you want to develop, you need feedback from your environment. Whether you like it or not. So, this also applies to your colleague. With this intention, it already becomes easier to start saying something. After all, you say it to improve the situation, to help the other person improve.

To effectively influence the behavior of the colleague and make your feedback land, four steps are necessary. The steps are all necessary and you take them one by one.

Step 1: Announce that you want to say something about the work or the collaboration (do not dive straight into the content). The other person then knows that they have to pay attention. Say, for example, “I want to talk to you about what has struck me (or what bothers me)’’.

Step 2: State in concrete and factual terms the other person’s behavior and what effect it has on you and/or the work (this can also be an emotion). So don’t say: ‘You’re handling it wrong’. This is not clear. Say: ‘I see that, for the third time, you are delivering your work later than we agreed’ (behavior of the other person). I am falling behind with my work as a result and so have too little time to do it properly (effect on the work). I am afraid that I am getting stuck and I worry about that. Moreover, it irritates me that you do not keep our agreement (effect on me)’. Note that we often forget about the effect on yourself and this makes the message just not get through to him/her.

Step 3: Take a step back and let the other person respond. You do this by asking a question. Say, for example, “Do you recognize this?” or “What do you think about this?” and then wait for an answer (a silence of at least four seconds stimulates the other person to react). This may be uncomfortable for the other person for a moment. If so, it means your message is getting through. It is important to let it be for a while and not to rush to the solution.

Step 4: Have you made up your mind? Look for a solution together. Being able to give good feedback is no guarantee of success. It does give you the tools with which you can positively influence the majority of situations.

One realization that I had recently (only to show that I’m not too bright) is how much energy we all spend on controlling our environment and trying to keep everything the same. The trigger was a car trip from Gothenburg to Stockholm during one of the warmest days in Sweden this summer. Unfortunately, the air conditioning in the car had broken down right before the trip and the inability to keep the temperature in the car within a narrow band led to a significant amount of complaining during the ride.

We’re always looking to control our environment, including the temperature inside our homes, the safety of the area we live in and the selection in the supermarket we shop in. Even the climate change activists who constantly lament about the climate changing seem to forget that the climate has been changing continuously for eons. Companies plan and budget for the coming quarters and years and managers get rewarded for their accuracy in predicting the future. In the same way our bodies use homeostasis to create a stable system, we’re constantly looking to address the deviations from an anchoring point we consider ideal.

In many ways, our desire to control our environment is a great asset. As George Bernard Shaw so eloquently said, “The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.” And over the last century or so, humankind has seen more progress than during its entire history combined. Based on all metrics that we use to measure quality of life for everyone on the planet, life has never been better. And it’s driven by our constant desire to control our environment and avoid bad outcomes.

The concern I’m trying to raise here is that our success over the last century has lulled us into believing that we’re in control. That, because we know how to treat certain diseases, have found ways to avoid world wars, globalized our economies to achieve new levels of efficiency, and so on, we can stop worrying about these things and assume the horrors of the past will never come back. And this is of course a complete fallacy as the Covid-19 crisis clearly shows. The shifting power balance in the world increases the risks of new wars. And the anti-globalization sentiment that we see in many countries pours oil on the fires of disagreement and conflict.

Similar to these developments on the macro level, we tend to confuse effort and outcome on the personal level as well. We can exercise and eat healthy, hoping for a long, productive life. We can work hard and hope for recognition and promotion at work. We can invest in relationships and hope for a rich social life. However, the risk is that we feel entitled to these outcomes because we put in the effort. As the Stoics so beautifully identify, confusing what we can control and what we cannot is one of the biggest sources of suffering. We can control how we behave and where we spend our time and energy, but we can’t control the outcomes of our efforts. Despite our best efforts, things can go to hell in a handbasket.

“Change is the only constant” is a phrase often used but seldomly actually lived by. Most of us are trying as hard as possible to keep things as they were before. This is one of the reasons that driving improvements and change such as digitalization is so hard: deep down, we want things to stay as they are. The fact of the matter is, though, that nothing ever stays the same. So, we either move forward or we’re left behind. Unless we embrace change proactively, it will be forced upon us. And I, for one, prefer to at least pretend that I’m in control of my own destiny, rather than a victim of circumstances.

My main message is that we don’t control anything, or at least very, very little. Everything that we feel we’ve accomplished can be ripped out of our hands at any point. Nevertheless, we need to relentlessly work to make things better. Right now, in industry, that means digitalizing your business and letting go of the belief that everything was better before. Because it wasn’t, and even if it was, we can’t go back there anyway. So, get to work, focus your energy on what you can control and don’t bother about the outcomes that aren’t under your control. You’ll be busy enough as it is.

During the last year, I’ve been in several discussions that, to a large extent, boiled down to “why is this product so stupid?”. The stupidity was defined by the lack of the system to anticipate user actions, the inability to learn to function better in a specific context or the total reliance on the user initiating activities by the system even if it was completely obvious what needed to be done. A few examples.

A representative of a company building radars relayed the story of being asked by a customer why the radar, once placed in a specific location, functioned the same after 2 minutes, 2 hours, 2 days and 2 months. Why wasn’t the radar learning from its context and improving its ability to detect objects by knowing what the static elements in the environment are and using that to better distinguish new objects?

A user of a route planning system complained about frequently being late for meetings because he wasn’t proactively warned for traffic jams that didn’t exist when he looked up the expected travel time the day before. Why doesn’t the system warn me, he lamented, for an unexpected traffic jam due to an accident or something so that I can leave earlier?

A company using expensive, high-tech equipment complained about the system being unable to adapt and get the hang of their very predictable schedule of operations. The equipment required adjustment time between different types of usage and even though the company ran virtually the same schedule day after day, the system didn’t learn to initiate the reconfiguration and subsequent adjustment by itself.

All these systems are built to the specifications that were put up before the start of development. All of them passed the validation and verification tests with flying colors. And yet, they fail to delight customers and users and provide significantly less efficiency and effectiveness than what they could.

Being in the age of AI, we have a set of tools in our toolbox that can help address the stupidity of products. Using different forms of learning and experimentation, we’re able to include behavior in systems for detecting patterns, developing hypotheses on these patterns being consistent, running experiments of proactive system behavior, measuring the effect of the experiment and then learning from it.

A theoretical AI researcher may claim that this is reinforcement learning and at its core, that’s a correct conclusion. However, it would also violate the Einstein principle of making everything as simple as possible, but not simpler. The key challenge around making systems smarter isn’t the basic reinforcement learning, but rather our ability to realize the aforementioned activities and behavior in systems without causing safety or security risks, without annoying the user (remember Clippy?), managing the stochastic nature of feedback and to focus on those things that actually add value for the user.

Still, customers are increasingly expecting their products to get better every day they use them. I want my car, my phone, my computer, my apps, my wearables to get better every day. I want my devices to learn from me and my behavior to deliver more value to me by adjusting accordingly. To achieve this, it’s not enough to adopt DevOps and run A/B tests, but it also requires fully autonomous experimentation by systems at speeds that R&D organizations simply cannot match.

Our systems shouldn’t nudge us into different behaviors, as many social media apps tend to do, but rather act proactively on our behalf and to our benefit. I want the systems that I use and interact with to take the lead and remove the burden of always remembering and initiating activities from my shoulders and free me to focus on the things that I’m uniquely good at. Please stop building stupid systems and focus on adding smart, proactive behavior instead of yet another feature.

With all the focus on data and AI, it was simply a matter of time before the countermovement started. Reflecting on several discussions around this topic that I’ve had over the last year, the key theme seems to be that data and AI are predicting the future based on the past and as long as the future is like the past, this works fine. However, the world is in constant flux and these technologies cause stagnation as we can’t predict fundamental shifts and disruptive innovations. Even worse, we don’t even look for them as we look at data in a short-sighted fashion.

Although I most certainly believe that there’s a very important place for human creativity and insight, I also think that not exploiting the advantages data and AI offer is simply akin to shooting yourself in the foot or tying one arm behind your back. There are several reasons for this.

First, for all the criticism on machine learning for predicting the future, the fact is that in most cases, humans are even worse at it. Even for highly variable data, ML algorithms often manage to exploit patterns that humans fail to detect. For large retailers, predicting the amount of product to order and then allocating it to each individual shop used to be a human task, but it’s clear that ML algorithms, given sufficient data, do a better job. A counterargument used frequently recently is that these algorithms didn’t predict the Covid-19 disruption, but of course, humans didn’t predict it either, leaving many stores with a significant surplus of goods.

Second, I still meet people that continue to express beliefs about the world, their industry, their customers or their own performance that simply aren’t true. Although some, like Steve Jobs, were known for their “reality distortion field,” for virtually all of us, just wishing for something to be true doesn’t make it so. As William Edwards Deming famously said: in God we trust; all others must bring data.

Third, data-driven practices don’t remove human creativity but instead focus it on the formulation of hypotheses. In traditional organizations, one can build a career on making strong statements that are hard to verify and being vocal about them. Often, these are based on individual instances and storytelling, to which we as humans are very sensitive. When adopting data-driven practices, the focus should be on formulating testable hypotheses and being less concerned with being proven wrong. Even hypotheses that are creative and novel but don’t pan out provide ample opportunity for learning.

Fourth, when using data-driven practices, you need to know what you’re optimizing for. In virtually all companies that I work with, features are prioritized and developed based on the beliefs of some product manager. The effect of the prioritized feature on the customer or system behavior and the way it generates value is often described in qualitative and vague terms. The worst argument here is that it’s a “strategic investment.” Rather than prioritizing a feature to be developed based on the beliefs of a product manager, it’s much better to treat the feature as a hypothesis, define its expected, quantitative effect and then measure its impact as you iteratively develop the feature slice by slice.

Working in a data-driven fashion doesn’t make you boring. Instead, it instills a higher level of discipline in the organization, uses technology where it fits best and focuses creative energy on the areas where humans provide the most value. It helps organizations to shed so-called “shadow beliefs” (beliefs that everyone in the organization considers to be true but that are not) and, through that, remove hypotheses that don’t hold from the pool of ideas. Neither humans nor machines can predict the future. However, although history never repeats itself, it often rhymes. And machine learning is better at detecting the rhymes than you.

The common theme over the last weeks, as I started to talk to more and more folks in companies, is the difficulty of realizing digital transformations. Granted, I work with many who are expected or having taken it on themselves to drive the digital transformation of their organization, but I believe the challenge is widespread.

Especially in the embedded systems industry, there’s a large group of people who originate in the mechanical or electronics world and can’t see beyond the limits of their technological perspective. With a digitalizing business, mechanics and electronics don’t go away – we still need a chassis and a computing platform. The main difference is that these technologies shift from being differentiating to being commodity (see figure). This causes a shift in perspective as you drive innovation when something is differentiating and you look to minimize cost when something is commodity. When the precious engine, braking system or propulsion chain suddenly needs to be optimized for cost instead of innovation, all working with that technology suddenly resist change. But the fact of the matter is that in virtually every industry, the differentiation is largely generated through digital technologies, ie software, data and AI.

Differentiating versus commodity technologies

We also see a shift in business model. In industries dominated by ‘atoms,’ the primary business model tends to be transactional. You buy a box, use what’s in the box until it’s old and then you buy a new box. Industries that focus primarily on ‘bits’ tend to use continuous business models such as subscription and service models. In these industries, customers expect the offerings that they’re using to get better all the time. This shift may seem trivial but has huge implications on the architecture of your products, the way R&D is conducted, how you support your customers and even the company’s financial model.

With digital transformations, it seems to me that there are at least six behaviors that can be identified. First, the “it’s not my problem” syndrome. Here, the patient thinks that digitalization has to do with data being shuffled back and forth between boxes that are outside his or her area of responsibility. As it’s not in scope, it’s not a problem that the individual has to contend with nor worry about.

The second challenge is the “too complicated” case. I recently read about a study where people were offered to sit on a chair and think without distractions (like their mobile phone) or receive mild electric shocks while being allowed to distract themselves with an app of their choosing. Interestingly enough, a large majority preferred to receive electric shocks over being ‘forced’ to think. Digital transformation represents a fundamental paradigm shift and there’s a significant group of people in companies that simply can’t be bothered to logically think through the consequences of this.

Even when individuals and teams accept data-driven practices, one interesting observation that we recently got confirmed in several companies is that although many organizations have top-level KPIs and many teams have local KPIs, there’s no real connection between the two. The consequence is local optimization based on team metrics as there’s no agreed-upon way to connect local and global KPIs. As local metrics typically are short-term and based on the current, traditional business, they slow down or stop any digital transformation.

A consequence is the “local bastardization of global strategy” challenge. As the link between the company strategy and the team actions is tenuous at best, team members will develop a rhetoric on how what they’re doing today is actually supporting the company strategy. Any overly obvious mismatches are then explained away by referring to the local and short-term challenges that need to be overcome first.

The fifth behavior I run into a lot is the “it’s too early” argument. Here, the protagonist claims to agree with all the points made related to the consequences of digitalization but in the same sentence claims that these implications will only realize themselves years down the line. Consequently, it’s too early to start making changes.

The final excuse that gets used almost continuously is that “customers aren’t asking for it.” This seems like a quite reasonable argument until you realize that all companies that waited until customers asked them for new functionality, business models or technologies have gone out of business because they were disrupted by more enlightened competitors or new entrants. Customers will simply go somewhere else when you haven’t predicted their needs. They won’t ask but simply vote with their feet.

Concluding, the realization of digital transformation in many companies is a slow, brutal, uphill battle that leaves proponents frustrated, tired and scarred. I’ve described six typical behaviors of so-called “rejectors” that you should be aware of if you’re to have any hope to overcome this resistance. The digital transformation is real, but many incumbents are moving too slow to avoid disruption.