Posts

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. ...

I’ve spent a significant part of my career as an Amazon Bar Raiser — conducting well over two hundred interviews across my own organisation and teams throughout Amazon. Somewhere along the way I stopped paying much attention to the things that most interview scorecards are designed to evaluate. Not because they’re irrelevant — behavioural anchors and competency frameworks serve a real purpose — but because I’ve found they’re much better at identifying people who are good at interviewing than people who are good at leading. ...

I have a lot of respect for the FinOps discipline. The people who do it well understand cloud pricing models deeply, can find waste that engineering teams miss, and provide genuine business value. But I’ve also watched FinOps programs fail repeatedly in ways that are predictable once you understand the underlying mistake: they treat cloud cost as a financial problem when it’s actually an engineering behavior problem — and those require very different interventions. ...

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. ...

Every organisation I’ve seen try to get cloud costs under control starts by creating a FinOps team or a Cloud Centre of Excellence. The reasoning is intuitive: costs are rising, we need specialists, let’s centralise the expertise and the accountability. And it works — for a while. The team runs analyses, identifies waste, creates savings plans, maybe sets up a tagging policy. Costs come down, leadership is happy, the team gets credit. ...

There’s a version of the stakeholder update that every engineering leader has written — the one that’s technically accurate, covers everything, and lands completely flat. The SVP skims it, asks one clarifying question that’s actually answered in paragraph four, and moves on. Nothing bad happens, but nothing good happens either. The update was noise. At some point early in my career managing large organizations, I realized that “thorough” and “useful” are not the same thing. An update that takes thirty minutes to write and thirty seconds to absorb is infinitely more valuable than one that takes thirty minutes to read and leaves the reader unsure whether to be worried. The craft is in the compression — and the honesty. ...

Hiring for potential is something most engineering leaders say they do. It shows up in job postings (“we invest in your growth”), in interview scorecards (“learning agility”), in the language leaders use when describing their teams. What gets said less often is what it actually costs when you bet on potential and the timeline doesn’t go the way you expected. Around 2017 or 2018, when I was leading a team at Capital One, I had a hire I was genuinely excited about. He came out of a smaller company, didn’t have experience with the scale of systems we were building, and hadn’t worked in financial services before — but in the interview process he’d shown something I found hard to ignore: a quality of reasoning that was unusually good for someone at his level. He asked questions I didn’t expect, he thought about tradeoffs in ways that were more sophisticated than his resume suggested, and I had a strong gut feeling that he would grow quickly into a genuinely strong engineer. ...

Technical debt has a reputation problem. In most organisations, when engineers bring it up, stakeholders hear one of two things: engineers want to do things the right way and business pressure is making them cut corners, or engineers are complaining again about problems that don’t affect the customer. Neither framing is productive, and both have some truth in them, which is part of why the conversation is so hard. I’ve been navigating this across two companies now — Capital One, where we managed genuinely complex legacy systems alongside new development, and in my current role leading a large engineering organisation in the cloud — and the thing that’s made the most difference isn’t having a better technical argument. It’s having a better business frame. ...

Most engineering hiring I’ve seen is reactive. A headcount opens up, a requisition gets approved, teams scramble to put together an interview loop, and everyone is focused on filling the seat as fast as possible because there’s work waiting. The question being asked is: who can we get, and can they start soon? That’s not a hiring strategy. That’s a response to a vacancy. I remember a stretch at Capital One when active headcount was limited and the pressure was to hold the line rather than grow. Instead of treating that as a quiet period, I stayed in deliberate contact with a handful of engineering leaders I’d worked with and respected — occasional check-ins, sometimes sharing something relevant to what they were building. When significant headcount opened up several months later, I had a short list of people I already knew and trusted. One of those conversations turned into our strongest hire of that cycle. The difference wasn’t luck. It was that I hadn’t started from zero. ...

This conversation happens across every engineering org, eventually. One of my managers comes to me — sometimes directly, sometimes as a way of thinking out loud — and the question underneath everything is: my best engineer wants to try management. What do I tell them? I always ask first how the manager is thinking about it, because their instinct tells me something. Some are quietly relieved — the engineer is expressing ambition, this feels like a good sign, let’s figure out the path forward. Others are quietly worried about losing their best technical contributor and are looking for permission to defer the question. Neither instinct, on its own, leads to a good answer for the engineer. ...