Architecture

Somewhere in the early 2010s, “microservices” became the answer to a question most engineering organisations hadn’t finished asking yet. The benefits were real — independent deployability, team autonomy, the ability to scale specific components without scaling everything — and the pattern spread rapidly, often outpacing the organisational and architectural maturity needed to do it well. What many organisations ended up building, without necessarily realising it, is what I’d call a distributed monolith: a collection of services that are deployed independently but are so tightly coupled in their runtime dependencies that they behave like a monolith in every way that matters. When service A breaks, services B, C, and D break. When you want to change the data schema, you have to coordinate a deployment across six teams. When you want to understand the blast radius of a configuration change, you have to trace dependencies through a graph that nobody has fully documented. ...

For the first several years of my career, I was used to being the person with the answer. Not always the best answer — I got things wrong plenty — but when a technical question came up, my instinct was to engage with it directly. To think through it, form a view, and advocate for that view. That’s what good engineers do. When I moved into management and eventually into leading teams of teams, I had to confront something I hadn’t fully anticipated: there were rooms I was walking into where I was genuinely not the most technically knowledgeable person. Not by a little — by a lot. My engineers had spent the last three years doing the work I used to do, which means they’d gone deeper on the specifics than I had. And yet, in those rooms, people were still looking to me for something. I just had to figure out what that something was. ...