Posts

I’ve watched this transition play out across a few orgs now, and the pattern that surprises me most is that the engineers who struggle aren’t struggling because they’re bad at their jobs. They struggle because they’re too good at their old job. Staff engineer is not “more senior engineer.” That sounds obvious when you write it down, but the way most companies handle this transition makes it feel like that’s exactly what it is — one more rung on the same ladder, where the expectation is better code, sharper technical opinions, and maybe a harder problem to own. Because that’s how it gets framed informally, most engineers arrive at staff level optimizing for the wrong things. ...

A few years ago, one of the best engineering managers I’d worked with told me he was leaving. Not leaving the team — leaving the company. He’d built something genuinely impressive: a team of 12 engineers who shipped consistently, calibrated well, and almost never created noise for me. He’d hired carefully and coached his people seriously. The departure of a strong manager is a stress test your org didn’t schedule. What you discover in the months that follow — about your bench, your systems, your culture — is more instructive than anything a retrospective or an all-hands could surface. ...

Ask most technology leaders where cloud cost management lives in their organization and they’ll point you toward finance. Someone on the CFO’s team owns the budget. Someone in procurement negotiates the enterprise agreement. Someone in a FinOps rotation audits the monthly bill and files a report. That is the dominant operating model in enterprise technology today — and it consistently underperforms. The organizations that get cloud economics right have made a different choice. They treat cloud cost as an engineering problem: something to architect, instrument, and optimize — not budget, approve, and audit. The mental model is different. The tooling is different. The ownership is different. And the outcomes are measurably, durably different. ...

A few years ago, when I was leading a team through a particularly chaotic product period, I developed a habit I was genuinely proud of: I gave my managers everything. Every upstream signal, every exec conversation, every bit of company context I had access to. I told myself it was respect — treating them as partners, not just executors. And honestly, at the time, I believed that. It took one of my managers sitting across from me and saying, almost apologetically, “I find it hard to make a call now without first talking to you” — for me to realise I had built something I didn’t intend to. ...

I’ve interviewed a lot of senior engineering and engineering leadership candidates over the years, and the pattern I’ve noticed in how those conversations go is fairly consistent. The first thirty minutes are almost always fluent — people come prepared, they have good stories about scale and complexity and the hard technical decisions they navigated. They’ve thought about leadership principles, they can talk about team development and conflict and cross-functional alignment. They’ve done the preparation, and the preparation shows. ...

Most cloud cost governance initiatives fail — not because engineering teams don’t care about cost, and not because finance isn’t watching the bills. They fail because they’re built as policies, not systems. Documents. Guidelines. Aspirations. Nobody enforces them, nobody owns them, and the behavior never actually changes. I’ve seen the artifacts in every organization that’s been through this cycle: a tagging policy in a wiki that nobody reads, a cost dashboard that was impressive at launch and now sits un-bookmarked, a Slack channel where someone periodically posts a chart of rising spend with a 😬 emoji. The governance exists on paper. It just doesn’t exist in practice. ...

A few years into my career, I worked on a team that I still think about when I’m trying to describe what I’m building toward. It wasn’t perfect. The project was hard, the timelines were tight, and there were personality conflicts and technical disagreements — the normal texture of a real team under real pressure. But there was something underneath all of that which made it different from most teams I’d been on before or since, and it took me years to articulate what that thing actually was. ...

I want to write an honest version of this, not the version that reads like an annual letter to shareholders. So let me tell you what I actually learned over the past couple of years — the things I changed my mind about, the things that were harder than I expected, and one or two that were genuinely easier. The first thing I got wrong, and kept getting wrong for longer than I should have: I underestimated how much context my direct reports actually need, and I overestimated how well it travels. When you’re leading other leaders — when your direct reports are engineering managers, not engineers — information passes through at least two layers before it reaches the people doing the work. I knew this in the abstract, but what I hadn’t appreciated is how much signal drops at each layer — not through negligence or incompetence, but because each person in that chain is doing the normal human thing of filtering for relevance and adding their own interpretive frame. By the time the context I thought I’d communicated reaches a senior engineer making a technical decision, it might have lost exactly the nuance that would have changed the decision. ...

For a longer stretch of my career than I’m entirely comfortable admitting, I operated with a mental model that went something like: figure out what the right thing to do is, check that someone above me agrees, then do it. I told myself this was being collaborative, building alignment, making sure I wasn’t moving unilaterally in ways that created problems downstream. And those things are real — they matter. But if I’m being honest, a meaningful part of it was also something else: I was using the approval process as a shield. If I had someone’s sign-off, then if the thing went wrong, the fault was distributed. It wasn’t just on me. ...

Early in my career, the way I learned was blunt and physical, almost. I’d build something, watch how it behaved, and pull apart whatever didn’t work. The feedback was immediate and the corrections were mine to make — which ideas connected, which broke things, which caused my senior engineers to raise an eyebrow in the particular way that meant I’d missed something worth understanding. There wasn’t much strategy to it, but there didn’t need to be. The feedback loop was tight, and I learned an enormous amount in a short time. ...