Category: Blogs

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.

An engineer asks:

I work with many colleagues from different cultures. Most of them are not used to how we give each other feedback in the Netherlands. Yet it is necessary to indicate what someone can or must improve if something is not going well. How do I tackle that?

The communication trainer answers:

Feedback is about delivering a message to the other person without disrupting the relationship. The direct ‘Dutch’ way may not work well when you work with cultures that are not used to this. The following ten points will help you.

1) As a starting point, it is always good to check with yourself whether you are giving the feedback to help the other person and improve the situation, and not just to confirm your authority or to kick someone’s ass.

2) It is important to invest in building a trusting relationship with your employees before you give them feedback. You’ve probably had the most valuable feedback yourself from people close to you. Building relationships in many countries often happens outside of work hours. So, it can help to pay attention to this regularly.

3) In Asian and Arab countries, avoiding losing face is important. It can therefore be helpful to start with more subtle feedback to get things done. Suppose you see that one section in a report contains errors. Then name how good one part is. The other person will pick up on the fact that the other part still needs attention. If you say something like this to an American or Dutch person, he will not understand your feedback and will prefer that you say what is still wrong directly, because that is faster. Start subtle first; then, should your message not be picked up, you can always become more direct. Backtracking when the cat is already out of the bag is harder.

4) Focus your feedback on behaviors and features of the work rather than judging. Instead of “Your work is sloppy” say “This presentation has three errors’’. Instead of “This report is incomplete” you can say “I would like to see an additional table’’.

5) To avoid losing face, you can also use the passive speaking mode instead of the active one. This sounds like the following: ‘’The front desk was unoccupied for fifteen minutes this morning’’ instead of ‘’’You were late’’. Then you avoid personal accusations. The addressed person can infer from the comment that it was his responsibility to be on time and that the absence was noticed. In many languages this passive language is already ingrained. If you are not used to this, it may take effort to do so.

6) Say what you do want instead of what you don’t. ‘’Stop doing this’’ just sounds like a rebuke whether you are 2 or 52. So, “Try to do it this way” instead of “This is not the way’’.

7) Addressing the entire team about, for example, adherence to the new work rules makes the pressure on the individual less immediate. Peer pressure can then cause that person to follow the rules anyway without you having to address them directly.

8) Speak softly rather than loudly. A quiet voice can relax a tense situation and makes it easier for the employee to hear your message.

9) Showing respect in your actions for the person you are giving feedback to is especially important. You can show this by spending time together. Or by asking the other person for advice or sending someone to them for advice. Also involving yourself in the solution shows that no one has all the answers alone and that you appreciate the other person’s vision. For example, you say “Let’s see how we can solve this’’.

10) Finally, give compliments. Your employee may feel uncomfortable when there is too much specific attention to his personal performance. In that case, it’s better to go out for dinner with the whole group and reward everyone that way. A compliment can then be given in a one-on-one situation.

During a meeting this week, I had to think of a famous quote by Margaret Mead: “Never doubt that a small group of thoughtful committed citizens can change the world; indeed, it’s the only thing that ever has.” The two senior leaders to whom I was talking complained about their R&D organization doing everything right on paper from an Agile, data-driven perspective, but still ending up with building humongous, inflated features that were released after many months of development.

This is of course a classic example of feature creep many companies fall into. When exploring how the situation developed, the discussion made clear that a very small number of influential people in the R&D organization had managed to convince the others that the initial plan of releasing a minimal viable feature wasn’t possible as it would cause angry customers.

I don’t want to focus on feature creep but rather on the ways a vocal minority in an organization, or even society at large, can have an impact that far exceeds the size of the group. In general, I’m a big proponent of a small group of individuals taking charge to initiate change within an organization. Even if the senior leaders pride themselves on leading major changes in their organization, almost always some individuals had been pushing for and championing the change for quite some time before it was picked up by senior management.

The challenge with “the vocal minority,” as I often refer to it, is that their success often depends more on the ability to use rhetoric and debating techniques than on the actual, technical nature of the change that is being advocated. The consequence is that individuals may passionately argue for changes that are detrimental to the organization and its members. To evaluate the relevance and validity of the proposed changes, I typically apply four questions or tactics.

The first test to which I subject a change proposal is to evaluate it against the fundamental principles I consider to be true. One of these is that faster feedback cycles are better than slower ones. This means that arguing for inflating a feature and consequently delaying its release, as well as the associated feedback goes against the argument for including more in the feature. My general rule of thumb is that work items should be kept to a size that allows one team to complete it in one sprint.

The second question I ask is whether the proponent of the change has considered a sufficiently broad scope of impact. It’s very easy when proposing a change to focus exclusively on the topic at hand and how to address it, without considering the broader scope. For instance, releasing larger features may offer more relevant functionality to a wider subset of customers, but it may also decrease the (perceived) quality of the system as it’s harder to test a large chunk of functionality than it is to test a small slice.

The third test is to explore second-order effects. In a famous story, Mao Zedong ordered all sparrows in China to be killed as they ate seeds. The second-order effect was an explosion of the locust population, causing a famine resulting in the death of millions of people. In software engineering, a well-known case is incentivizing software engineers to use code from a shared code library to increase software reuse. This has caused all kinds of interesting effects, including engineers first checking in their code into the shared code library and then “reusing it” to get their bonus. Although it often is very difficult to predict second-order effects, it’s generally possible to generate relevant hypotheses that either can be tested or for which at least circumstantial evidence can be collected.

The final mechanism I use is to explore if it’s possible to run small-scale experiments that provide additional evidence concerning the proposed change. The challenge with the first three tests/questions is that these are based on argumentation and reasoning and not necessarily founded in empirical reality. It’s critical to complement the beliefs that underlie the reasoning with tangible, empirical data to increase the confidence that the change will have the intended outcome and avoids unwanted side effects.

Concluding, in my experience, virtually all change in organizations is initiated by a “vocal minority.” This minority often relies on rhetoric and debating techniques to gain influence, rather than the quality of their proposal. This requires all of us to critically reflect over change suggestions. I’ve described four techniques that I use to evaluate these proposals. Rather than submitting to some form of herd mentality, it’s the responsibility of each and every one of us to maintain independent and critical thought, independent of peer pressure. Don’t be a sheep!

This week, I met with some companies in the embedded systems space that are looking to start A/B experimentation in their products. These products have safety-critical functions and subsystems and of course, it’s difficult to even imagine A/B tests that aren’t, in some way, touching safety-critical functionality. The proponents of experimentation at these companies outlined the challenges they were experiencing and interestingly, all challenges were internal to the organization. To transition from the traditional specification-based R&D to A/B testing requires changes to the way testing takes place, requires a significant reduction in system variants, needs support for deployment of new software versions (preferably over the air), changes the way safety certification takes place, the way we measure data from products in the field, and so on.

Although I believe the adoption of experimentation practices is critical for any company, my point here is to focus on the fact that in most companies I work with, to change anything requires changing everything. For the longest time, companies focused on optimizing the efficiency of their operations. As a result, every activity, every process was integrated into a larger whole, carefully aligned and then tuned to the point that the amount of slack in the system has been reduced to virtually zero.

This doesn’t just take place inside companies but across business ecosystems as well. Automotive companies are famous for demanding their suppliers to build factories next to theirs so that the OEM doesn’t need to run any inventory as it will see a constant flow of product coming in from their suppliers’ factories next door. Deeply integrated, highly aligned, very efficient.

Initially, this integration and alignment starts with individuals coordinating with each other. The next step is to define a repeatable process that everyone needs to follow. The step after that is to build systems that automate the processes. The challenge is that with every one of these steps, changing anything becomes harder and harder.

The focus on efficiency and automation works as long as you’re operating in a stable, unchanging environment. The moment disruption hits, though, the brittle system falls apart. To avoid that, companies and entire business ecosystems fight as hard as they can to resist change. In the short term, the arguments are always valid: the cost of changing the entire set of systems, business processes, interactions between individuals and even the culture of the company in response to change is always higher than the short-term gains.

The problem is, of course, that every time you resist change, you get a bit behind. You accumulate some business, process and technical debt. You become a little less “fitting” to the environment in which you’re operating.

One way to characterize the history of humanity is a constant battle to control our environment and to minimize the need to adapt to the context in which we operate. From rooting out animals that hunt humans to building houses that control the temperature and humidity of the air we breathe and from vaccines to eradicate infectious diseases to the internet that allows us to connect with others, independent of time and space – all of these accomplishments can be viewed as ways to control our environment.

Our success has created a perception that the world is stable and predictable and therefore, we can afford to build deeply integrated, highly aligned and fully automated systems. During the last months, however, we’ve been reminded of the fact that we control much less than we think. The Covid-19 situation has disrupted numerous highly efficient systems.

My point is that we need to be careful to avoid building these brittle systems. We need agility, flexibility and the ability to rapidly change direction. Instead of resisting change, we should welcome it, even initiate it by constantly reinventing ourselves. As Peter Drucker famously said: “Business has only two basic functions, marketing and innovation; all the rest are cost.” Innovation, by its very definition, changes things from how we did them yesterday. It should be easy to innovate and innovation needs experimentation as you never know what works until you try it out. Rather than focusing on efficiency through alignment, processes and systems, focus on making innovation as easy, seamless and fun as possible. In the end, that’s where the real battle is won!

Some decades after the term “Agile” was introduced in software development, one would expect that – assuming it was a good idea (which it is) – the concept should have been fully embedded in industry and we’re busy with other things. Still, and this never fails to surprise me, everyone is talking about “beyond Agile.” The notion seems to be something along the lines of “we’re still busy here implementing Agile, but perhaps we can start to think about what we can or should focus on next.” If you haven’t adopted Agile, then, for Pete’s sake, get a move on.

Business agility and all its enablers, such as agile software development, are critical for long-term business success. Because of this, going beyond Agile is, of course, the only reasonable thing to do, but one can interpret the “beyond” in a variety of ways. Here, I’ll share five “beyond Agile” concepts that I’ve been working on during the last years.

First, the traditional discussion around Agile was concerned with software and software development only. Especially for companies selling products, including mechanics and electronics, as well as software, the main question was how to combine the waterfall process associated with atoms with the Agile process associated with bits. Taking Agile beyond the realms of software and have it include the other technologies making up the product is a critical step in achieving business agility and allows for new and different business models.

The second concept is concerned with going beyond requirements. Traditional Agile, for all its discussion about customer involvement, sprint planning and retrospectives, is still concerned with building towards a specification. Especially SaaS companies have shifted towards outcomes, meaning that teams focus on improving measurable outcome metrics, such as conversion. This requires a fundamentally different approach to development as it’s now the team that has to brainstorm approaches to “move the needle,” build the alternatives to test, measure their impact and then decide on which versions to keep and which ones to drop.

Third, traditional Agile assumed that development takes place in sprints and that there’s a shippable version of the system at the end of every sprint. However, it doesn’t assume that the release of the system actually follows the sprint process. As many companies focusing on continuous deployment and DevOps have figured out, including the release process in the Agile sprint model is a natural way to increase the frequency of value delivery to customers, on top of offering real, tangible data from the field at a much higher frequency. This is a big topic and if you’re interested, you can read more here, here and here.

Over the years, software has been joined by other digital technologies, specifically data and AI. These technologies benefit from the same principles as those that underlie Agile in software and this has led to the definition of DataOps and MLOps to reflect this. The fourth aspect is concerned with adopting Agile principles for all digital technologies. Of course, there’s a lot to read, including on my blog, but you can also watch this video to learn more about my view.

The fifth and final concept is concerned with business agility. Traditional Agile, as I mentioned, is mostly concerned with software but, for sure, is confined to product development. However, the holy grail is business agility, ie the ability of a company to rapidly respond to changes in its environment, the market, customers and strategy.

Concluding, the simple words “beyond Agile” can refer to a variety of concepts. I’ve discussed five of the primary ones, including applying agile to entire systems and not just software, shifting focus from specifications to outcomes, adopting continuous deployment (DevOps), adopting Agile for data and AI and, finally, reaching full business agility. Next time someone brings up the idea of going beyond Agile, make sure you know what they’re talking about (or rather, make sure that they know what they’re talking about). It’s easy for things to get lost in translation!

During my vacation, one of the questions I spent time thinking about is why companies function as they do. And why companies that are digitally born operate and “feel” different from traditional ones. Why companies that were different from the beginning tend to fall back into traditional patterns and become like traditional ones.

I realized that, of course, the patterns in organizations are the consequence of human nature. This drives many recognizable behavioral patterns. First, the formation of hierarchies. As I wrote a few years ago, the need to organize ourselves in hierarchies goes, according to some, back hundreds of millions of years in our evolution, long before there even were mammals. Much of the behavior in society and companies is driven by our innate need to compete and jockey for position in the vast number of different hierarchies that are available to us in modern society.

Second, and a direct consequence of the first pattern, is the need to exert power over others. A higher position in a hierarchy gives power and, unless checked carefully, the need to use that power for personal gain rather than the general good.

The third pattern is that humans rely very strongly on their own beliefs and have a tendency to operate based on opinions, rather than facts. To most of us, it feels like you’re losing face if something that you believe in turns out not to be accurate. And we’ll strive to realign reality with our beliefs to the largest extent possible and easily become defensive if we’re challenged with data that counter our beliefs.

These human behaviors cause traditional organizations to operate in the way they do, including the hierarchies, the bosses that demand to be obeyed even if decisions don’t make any sense and the general tendency to ignore inconvenient data that’s just staring you in the face. This is exacerbated by the fact that most organizations became successful because of their being different in some way from the rest of society. This “us versus them” mentality only reinforces our basic human behaviors.

The emergence of digital technologies, however, brings along a fundamental shift in how companies operate. At the heart of this fundamental shift lies the awareness of recognizing human behavior and not ignoring it (which many have done at their peril), but at the same time streamlining it to ensure that these behaviors generate the desired outcomes, rather than falling back into traditional structures.

These companies are so successful because they harness instinctive human behaviors differently. For example, hierarchies aren’t ignored but are to the maximum extent possible based on meritocratic principles. In addition, they’re structured to be temporary, rather than cast in stone.

Second, the desire to exert power over others is mitigated by employing empowerment and related mechanisms that limit the power of one individual over another. Rather than relying on a boss positioned in a hierarchy, every individual is free and expected to take responsibility for his or her own decisions and actions.

Third, these companies use data to continuously challenge beliefs held by individuals and groups and encourage alternative interpretations of data to avoid the organization getting trapped in groupthink and defensive around key ideas. For instance, most SaaS companies use A/B testing extensively – an incredibly effective tool to break down “shadow beliefs” in the organization.

Over the last years, however, I’ve come to realize that the difference between traditional and these modern, digital companies is fundamental and starts with the basic assumptions and culture underlying the organization. In response, over time, the scope of my work has gone from specific areas in software R&D, such as software architecture, product lines and continuous integration and deployment, to systems engineering and end-to-end R&D. From there, I included the operations part, including DevOps, DataOps and MLOps, and the front-end part of product management. More recently, I did work on business models, ways of organizing, business ecosystems and other topics not strictly in the scope of technology.

However, I feel that what’s lacking is a holistic and complete company and organizational perspective that includes not just the product and services scope, but all functions in the company, including general management, sales, HR and finance. Although my posts over the last years have provided puzzle pieces of this picture, it’s my intention to, over the coming months, provide a more integrated perspective with the intent of helping you, dear reader, to adopt the modern best practices and avoid the pitfalls that many traditional organizations get stuck in.

 

This article is the last of four where I explore different dimensions of digital transformation. Earlier, I discussed business models, product upgrades and data exploitation. The fourth dimension is concerned with artificial intelligence. Similar to the other dimensions, our research showed that there’s a clear evolution path that companies go through as they transition from being traditional companies to becoming digital ones (see the figure).

In the first stage, the company is still focused on data analytics. All data is processed for the sole purpose of human consumption and interpretation. At this point, things are all about dashboard, visualization and stakeholder views.

Evolution of the use of AI technology.

In the second stage, the first machine learning (ML) or deep learning (DL) models are starting to be developed and deployed. The training of the models is based on static data sets that have been assembled at one point in time and that don’t evolve unless there’s an explicit decision taken. When that happens, a new data set is assembled and used for training.

In the third stage, DevOps and MLOps are merged in the sense that there’s a continuous retraining of models based on the most recent data. This data is no longer a data set, but rather a window over a data stream that’s used for training and continuous re-training. Depending on the domain and the rate of change in the underlying data, the MLOps loop is either aligned with the DevOps loop or is executed more or less frequently. For instance, when using ML/DL for house price prediction in a real-estate market, it’s important to frequently retrain the model based on the most recent sales data as house prices change continuously.

Especially in the software-intensive embedded systems industry, as ML/DL models are deployed in each product instance, the next step tends to be the adoption of federated approaches. Rather than conducting all training centrally, the company adopts federated learning approaches where all product instances are involved in training and model updates are shared between product instances. This allows for localization and customization as specific regions and users may want the system to behave differently. Depending on the approach to federated learning, it’s feasible to allow for this. For example, different drivers want their adaptive cruise control system to behave in different ways. Some want to have the system take a more careful approach whereas others would like to see a more aggressive way of breaking and accelerating. Each product instance can, over time, adjust itself in response to driver feedback.

Finally, we reach the automated experimentation stage where the system fully autonomously experiments with its own behavior with the intent of improving certain success metrics. Whereas in earlier stages, humans conduct A/B experiments or similar and the humans are the ones coming up with the A and B alternatives, here it’s the system itself that generates alternatives, deploys, measures the effect and decides on next steps. Although the examples in this category are few and far between, we’ve been involved in, among others, cases where we use a system of this type to explore configuration parameter settings (most systems have thousands) in order to optimize the system’s performance automatically.

Concluding, digital transformation is a complex, multi-dimensional challenge. One of the dimensions is the adoption of AI/ML/DL. Using AI is not a binary step, but rather a process that evolves over time and proceeds through predefined steps. Deploying AI allows for automation of tasks that couldn’t be automated earlier and for improving the outcomes of automated processes through smart, automated decisions. Once you have software, you can generate data. Once you have data, you can employ AI. Once you have AI, you can truly capitalize on the potential of digitalization.