Category: Blogs

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.

Based on our research, we’ve developed a four-dimensional model for the digital transformation in the software-intensive embedded systems industry. In the last two posts, we explored the business model and product upgrade dimensions. This post is concerned with the data exploitation dimension.

As shown in the figure, the first step in most companies is focused on the use of data for quality assurance and diagnostics. In this case, the data often arrives at the company in batches and through customer complaints. In response to a complaint, company representatives download the data and investigate whether the system behaved incorrectly and seek to identify the root cause. Many companies have been using this type of data for decades.

Evolving use of data

The second step is the use of data to monitor product performance and feature usage. This form of data collection is typically introduced in combination with the more frequent deployment of software. Monitoring product performance allows the company to confirm that the product is performing well after a software upgrade. Measuring feature usage allows for more informed prioritization of R&D resources by ensuring that research and development predominantly focus on improving features that are actually used by customers.

As we now have a continuous stream of data from each customer, we can move to the third stage where we can start to collect data relevant for the customer. Each customer has KPIs for which the organization optimizes, including churn in subscription service companies, measuring service usage by end-customers or classifying end-customers into segments that require different treatments. As the company now collects significant amounts of data from each customer, it can process and analyze that data and offer relevant insights to each customer.

Finally, in the last stage, the company engages a second business ecosystem where it monetizes data collected from its primary customer base with a secondary customer base. For instance, a truck company could sell route information of the trucks in use at its customers to gas station and road service companies. Or, a telecom company could sell aggregate movement patterns of mobile phone users to city planners.

Once the company reaches the final stage, the data that’s collected in its products deployed at its primary customer base now is increasingly concerned with meeting the needs of the secondary customer base. So, the company is likely to start collecting data that has no relevance at all for its primary customer base but that is relevant for the secondary one. A second aspect is that the company can use the revenue from the secondary customer base to subsidize the products to its primary customer base and, through that, grow its market share. Many industries, as digitalization takes hold, move towards a “winner takes all” situation and this pattern of positive feedback cycles lies at the root of it.

Concluding, digitalization has implications for the business model, the way we upgrade products and the way that we collect, use and monetize data. Companies evolve in predictable and repeatable patterns through this transformation and in this post, I described the five typical stages we encounter in our research. Data is the new oil, but if you’re not able to generate business value from your data, it doesn’t do you much good. So, get going on experimenting with different ways to create value from your data!

In last week’s post, I mentioned our framework describing the transformation that companies go through when going digital. I also discussed one of its four dimensions – the business model dimension. In this post, the focus is on the product upgrade dimension.

As shown in the figure, we’ve identified five steps or phases in the transformation from a traditional to a digital company. In the first stage, the company focuses on selling a physical product. It’s sold ‘as is’ and except for warranty issues, the company spends no time or resources on it once it has left the factory. The product may well include electronics and software, but these subsystems are treated in the same way as the mechanical parts.

Evolution of product upgrades as part of the digital transformation.

As a second step, many companies set out to offer their product as a service to certain customer segments. This often starts as a mechanism to expand the clientele. Especially potential customers that don’t need the product all the time or that have issues financing the capex may need a service offering in order to become customers. In this step, the company often starts to offer periodic upgrades to the product software – predominantly to protect itself from unwanted downsides. In service contracts, there typically are service level agreements (SLAs) and software upgrades can be used to decrease the risk of violating these SLAs and avoid the associated penalties.

In the third step, the company has, from a business perspective, started to offer complementary services around the product. Frequently, the quality and appeal of these services can be improved if the core product has updated software functionality. In this case, the company upgrades the software in its products not only to protect from any downside issues, but also to create an upside in terms of additional revenue from complementary services. As a simple example, an automotive company may upgrade the software to provide an API for querying the location of a vehicle that can be used by complementary services to offer more relevant information for the context in which the vehicle and the driver may find themselves.

Finally, the concept of a physical product is completely replaced with its digital alter ego. In this case, all parts of the product can be upgraded on a periodic basis, with software being the most frequent and mechanics the least frequent. Even replacing the complete physical product is done as part of the continuous improvement of the digital product. As an example, although Apple most certainly makes the money on the physical product, from a user experience perspective, there’s a constantly improving experience that has small upward bumps when replacing the phone with a new model, but by and large, the improvement of the product is a continuous one.

Concluding, the digital transformation is a complex, multi-dimensional challenge that affects all parts of the company, including the way products get upgraded. Although this may seem like a technical challenge, it’s the business strategy that (should) drive the architecture and technology decisions that either allow for or prohibit the product upgrades discussed here. With business models increasingly moving from transactional to continuous, the product that’s being monetized by the business model needs to become continuous in terms of it constantly improving the user experience and value delivery to customers. One can’t exist without the other!

Over the last months (actually, more like years), we’ve studied the digital transformation of several companies in the Software Center. Professor Helena Holmström Olsson and I developed a model to illustrate how they actually transition from their legacy business rooted in atoms to a digital business based on bits (see the figure). It has four dimensions: business model, data exploitation, product upgrade and AI/ML/DL. In this post, we’re focusing on the business model dimension.

Based on our research with several of the Software Center partners, we identified that companies evolve through a similar pattern when it comes to transforming their business model. Especially in the embedded systems domain, the starting point is traditional product sales, eg a car, a truck, a radar, a pump or a base station. We often refer to this as “box sales” and the business model is highly transactional: I sell you the box and I will then try to sell you a new box in a few years’ time. There may be some revenue generated from services, such as product maintenance, but this tends to be a small fraction.

The digital transformation stages.

The next phase is where the product is offered as a service. Here, mostly the monetization of the physical product changes from a one-time transaction to a continuous revenue stream. There are several challenges with this, including this requiring the company to, in effect, finance the product for its customers, but it can be a very effective way to grow revenue as customers that wouldn’t have bought the product in the traditional model as, for example, they don’t need it full-time, may well want to buy it as a service.

As a next step, we see that companies start to develop all kinds of services around the product. These services tend to surround the operation of the product and may range from offering accessories in a rental model to providing information and advisory services to improve efficiency or the quality of outcomes. In this phase, the product is used as a platform to generate more revenue from complementing services.

In the fourth step, the monetization model changes again and becomes more customer oriented. Rather than associating monetization with the product, it becomes associated with customer KPIs that can be influenced by the product. Examples of these customer KPIs include the number of successful deliveries without delays, the reduction in end-customer churn or the reaction time gained by earlier detection. In this case, the company focuses on the factors that influence the customer’s bottom line and links the business model to improving those factors.

Finally, the company seeks to develop a second customer base where it can monetize the data generated and captured from its primary customer base. For example, trucks have accelerometers that provide information about the quality of roads (such as the presence of potholes) and government functions responsible for road maintenance may be willing to buy this information. The result is a two-sided market where the company still sells to its primary customer base but also monetizes the data from its primary customer base to its secondary customer base. Over time, of course, the secondary customer base may become the more important one, which then fundamentally changes the incentives within the company.

Concluding, as part of your digital transformation, the business model that you employ will have to change and evolve as well. As we’ve shown, this evolution follows a pattern and jumping over intermediate stages tends to lead to failure. Although our model focuses on the embedded systems domain, I believe that all industries evolve through similar or identical patterns. As you experiment with evolving your business model, the stages presented here may provide guidance on where to focus next. As always, we’re eager to learn more about your experiences, so please reach out to us to share them.

This week, I had an interesting discussion about data with the CEO of one of the startups I work with. The challenge is that many companies are collecting vast amounts of data, storing it and then leaving it as an unused asset. It surprises me that so many companies are maintaining such amazingly large data stores without finding good ways of using them.

The key underlying reason, in my opinion, is that collecting data is easy, but generating actionable insights out of it is hard. It requires a deep understanding of the domain, as well as insight into what provides value within the domain’s context. This calls for a mindset different from the one present at most companies, where the focus often is on doing what we’ve always done, but a little bit better or faster.

The company of the CEO I talked to operates in the media domain and has reached a point where key employees of its customers receive a daily email listing the highest-priority tasks that they should focus their energy on that day. These tasks are identified by collecting data from the relevant media properties of the customer, analyzing this data to identify deviations and anomalies and then recommending the most likely mitigation actions that will address the identified concerns. These mitigation actions are the tasks that the key employees receive in their daily to-do list. To me, this is the hallmark of being a data-driven company: it’s not about the data, but about generating actionable insights from the data that you can use to your advantage.

Of course, in this case, the insights are generated based on the customer’s own data. The next step is to get some or all of the customers to agree to anonymously share their data with the company. This allows the company to compare each customer to all the others, which allows for the next level of insights to be generated. Now, it’s not just deviations and anomalies identified within your own scope, but also those identified through comparison with others. By comparing your performance with others in the same industry, it’s much easier to gain insight into where energy should be invested to improve.

Concluding, to be a data-driven company is not about having lots of data. It’s about generating valuable and actionable insights from that data continuously and using those to generate, preferably automatically, the actions for your team that will have the most impact. It’s not about the data; it’s about what you do with it.