Before You Break the Monolith

A while ago I interviewed a group of engineering leaders at a retail organisation that was doing a post mortem for what they described as a necessary and inevitable modernisation. The monolith had to go. Microservices were the future. Teams would gain autonomy, delivery would accelerate, innovation would finally unlock itself. The target architecture was clear and the strategic narrative sounded convincing. What struck me, however, was not the ambition behind the move, but the absence of a more uncomfortable conversation. They had spent a considerable amount of time discussing how the system should look beforehand. They had spent almost no time discussing whether the organisation was ready to operate it.

As the conversations progressed, I asked how ownership was defined today, who carried operational responsibility when something broke, how product and engineering resolved conflicting priorities and what actually happened when a team failed. The answers revealed there was confidence in the vision of the future, yet a surprising vagueness about the realities of the present. It became clear that what they were facing was not primarily a technical shift. It was a behavioral one.

There is a persistent myth in our industry that engineers resist change. In my experience, the opposite is usually true. Most engineers genuinely want modern technology. They want cleaner abstractions, better tooling, clearer ownership and fewer hidden dependencies. When you say microservices they hear autonomy. What they do not always hear is the level of discipline and responsibility that autonomy requires. Distributed systems amplify what already exists. If ownership is fuzzy in a monolith, it becomes chaotic in a distributed architecture. If data governance is weak, fragmentation increases. If leadership avoids difficult trade-offs, those trade-offs simply get distributed across more services and more teams.

What unsettled me in those interviews was that everyone had a strong intuition about readiness, yet no one had a shared view of it. Leadership believed the organisation was nearly there. Engineering believed architecture was the primary bottleneck. Product perceived delivery friction as technical. Business saw technology as slow. Each perspective was defensible in isolation. Together, they formed a set of competing narratives without a shared foundation. In that vacuum, the decision to migrate risked becoming an act of optimism rather than an informed choice.

That realisation eventually led me to build a tool to address this conundrum. It is a structured way to gather input from the people who would actually have to live with the consequences of the transformation. It takes roughly twenty minutes per person. Engineers, product managers, business stakeholders and leadership respond to statements that explore architectural maturity, team capability, governance, integration patterns, cultural readiness and alignment. The responses are aggregated and analysed, patterns emerge and alignment gaps become visible. What was previously a gut feeling begins to take shape as shared evidence.

The most interesting moment is not the data collection itself, but the conversation that follows. When engineering rates autonomy high and leadership rates it significantly lower, something subtle shifts. When product highlights delivery friction while architectural confidence remains strong, hidden patterns emerge. When data readiness scores poorly despite bold modernisation plans, the future feels slightly less certain. None of these signals are accusations. They are mirrors. They allow an organisation to see itself without relying solely on the loudest voice in the room.

There is something seductive about starting a migration. It signals momentum. It feels strategic. It demonstrates ambition. Preparation, by contrast, feels slow and unglamorous. It rarely appears on a roadmap. Yet preparation is often the true transformation. You can decompose a monolith in months, but you cannot decompose organisational ambiguity at the same speed. If teams have never operated with clear bounded contexts, microservices will not magically teach them. If incentives between business and engineering remain misaligned, distributing services will not create clarity. It will distribute confusion.

Over time, I have become increasingly convinced that many migrations fail not because organisations are incapable, but because they start too early. Enthusiasm for modern technology outpaces readiness for the behavioural and structural changes required to sustain it. The cost of discovering that too late is substantial: eroded trust, rollback strategies, talent fatigue and quiet blame cycles that undermine future initiatives. The cost of discovering it early is negligible in comparison. Twenty minutes per participant is a small investment for the level of clarity it can provide.

The Migration Readiness Assessment is available on GitHub at https://github.com/kayoslab/Migration-Readiness-Assessment. You can fork it, adapt it and reshape it to your own context. It is not a product and it is not a funnel. It is simply something I built because I kept seeing the same pattern and wanted a better way to surface it. And if you believe this could be useful and would like to talk it through, feel free to reach out. Not for a consulting pitch, but for a conversation. I have learned most of what I know about culture and modernisation from people who were generous with their time. This is just a small way of giving some of that back.

The monolith, in many cases, is not the enemy. It is simply the current reflection of how an organisation makes decisions, resolves conflict and defines ownership. Before dismantling it, it may be worth examining what it reveals. If you are about to modernise your platform, my advice is intentionally slightly uncomfortable: before you modernise your architecture, modernise your self-awareness. Gather the data. Look at it together. Decide consciously. The difference between transformation and theatre is rarely technical. It lies in whether you were honest about where you started.