Jan Bosch is research center director, professor, consultant and angel investor in start-ups. You can contact him at jan@janbosch.com.
For decades now, I’ve been in workshops with a number of companies that seek to change some aspect of their business. Reflecting on the more recent workshops, however, made me recognize patterns that seem to reappear frequently or typically. As we all know, change is hard. For individuals and even more so for organizations. However, the patterns discussed below lead to less than optimal or simply bad outcomes.
The first pattern that I see occurring very frequently is teams starting from where they are and from the reality they’re experiencing right now. The misconception is that the world will continue as it is today. So, rather than focusing on what the world will likely look like when the change has been realized – which often takes years, especially in large organizations – the team focuses on the status quo and assumes it is static. A good example, concerning DevOps, is when many teams simply refuse to accept that customers will, also in their industry, start to ask for frequent deployment of new versions of software. The argument for this refusal is that customers aren’t asking for it today, even if it’s clear that industry after industry is transitioning in this direction.
The consequence of starting from where you are is that the changes you’ll be introducing tend to be quite small, resulting in the tallest pygmy problem: even if you’re constantly growing and improving, you may end up being the tallest pygmy, rather than the giant you aspire to be.
The second pitfall I see many companies step into is to start with the organization and changes that are required for the organizational structure, reporting relationships, lacking roles, and so on. Although I’m the first to admit that the organization matters, it should be the consequence of everything else. In an earlier post, I introduced the BAPO model. In short, this model suggests that you start with the desired business, innovations and business strategy. Based on that, you define the system, product or portfolio architecture, as well as the technology choices. Once these are defined, the next step is to define the processes, ways of working and tooling. Only after the “B”, “A” and “P” have been defined, should the discussion on the organization start.
The consequence of starting with the organization is that your change process becomes “OPAB”: the organization dictates work processes, these processes result in an accidental architecture, which, in turn, gives a very limited set of business strategy options to the company.
A third observation is that, depending on the organizational culture, there are teams or team members that focus exclusively on the limitations exhibited by the team, the organization and the business ecosystem. So, rather than focusing on the things that we can do, the team or part of the team focuses on the opposite, ie the things that are holding us back. Especially in complex ecosystems with unbalanced power relations, teams may easily fall into the victim role and have great difficulty taking responsibility for their own destiny.
Finally, the fourth pattern that I’ve seen is teams falling into analysis paralysis. Even if the team is future-oriented, starts with the business strategy and takes charge of its own destiny, it may still end up in a situation with so many options and constraints that it loses track and is unable to come to a concrete set of actions to move into the future.
Concluding, change is hard, both for individuals and organizations. Having said that, starting from the desired state and the desired business strategy, focusing on what you can control and ensuring concrete actions in the right direction are very helpful strategies to avoid the main traps and significantly increase the likelihood of the desired outcomes. Don’t start from where you are but start from where you want to be. After all, the future is where we spend the rest of our lives!