During the last few weeks, I’ve worked with several companies and identified a pattern that, in hindsight, I have seen many times before: a team gets stuck midway a change process and refuses to let go of the old ways while adopting new ways of working. In that way, the organization gets the worst of both worlds. Let me illustrate with two anonymized examples – somewhat changed to protect the innocent.
The first company has been building real-time systems as monolithic C/C++ applications for many years. For a variety of reasons, it has become clear that a new platform is required. As the company also wants to open up for 3rd-party applications, the architects have investigated the use of containers and a message bus as the basic architectural style. This would provide enormous benefits to break the monolith into smaller chunks of functionality that are largely decoupled and that can be deployed independently. The engineers have prototyped with the architecture and it turns out that the real-time needs of even the most demanding deployments can be met.
However, some of the architects were actively promoting to allow the use of remote procedure calls between containers as a second mechanism for different components to communicate as this is the way the developers are used to working in. The obvious consequence is that allowing for such a backdoor in the architecture is likely to undo all the benefits of using a container and message bus approach. It would allow for numerous hidden dependencies to be introduced into the system, obliterating the possibility to deploy individual chunks of functionality independently.
The second company is in the transition from traditional ways of working to adopting agile ways of working. Operating in an industry where regulation and certification play a big role, it has introduced new roles such as scrum master, product owner and the like while leaving the old roles in place as these were doing some of the standards and regulations work. The result is confusion concerning the old and new roles, their interfaces and the responsibilities and authorities associated with them. This, of course, has as a consequence endless meetings, high levels of frustration and significant double work.
The pattern here is caused by a very human trait that almost all companies suffer from: the desire to reduce risk by the gradual introduction of new architectures, ways of working or organizations. The problem is that, in many cases, the gradual approach, rather than mitigating risk, is, in fact, the riskiest approach you can take. The confusion, lack of clarity, overhead and general paralysis of the organization are hard to overestimate when standing with one foot in the new world and one foot in the old.
Organizations often end up here because of there being two internal factions: those that want the change and those that do not. During the discussions, there’s a tendency to look for compromises that cause the resulting agreement to be a combination of a bit of the old and a bit of the new. This ‘design by committee’ approach invariably results in solutions that are inconsistent, lack conceptual integrity, are difficult to understand and often simply don’t make sense.
Concluding, the way forward has been foreshadowed by Yoda as he says to Luke Skywalker: “Do or do not, there is no try.” As a leader, you either adopt the new architecture, way of working or organization or you do not and instead keep things as they are. You should, however, avoid any form of compromised, design-by-committee, halfway changes like the plague. This will result in tension in the organization as not everyone is ready. However, in a healthy culture, people agree and commit or disagree and commit. Not everyone has to agree with the new approach; they just have to act accordingly. This is one of those times where leadership equals courage. Now go and do your job!
To get more insights earlier, sign up for my newsletter atjan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
