Engineering Leadership

A few years ago, I gave a performance review that I thought was honest and balanced. I covered the person’s genuine strengths, which were real and worth celebrating. I mentioned the areas for growth, but I kept the language careful — “continues to develop” rather than “struggles with,” a sentence about the opportunity to build more cross-functional relationships rather than a direct observation that the person was creating friction with peer teams. The review was true, technically. But it was soft in the places that mattered, and I knew it while I was writing it. ...

I’ve looked at a lot of cloud cost management tools. Visibility platforms that aggregate your billing data and break it by service, team, and environment. Anomaly detection that alerts when something spikes unexpectedly. Rightsizing recommendations that tell you which instances are over-provisioned. They’re all useful in the same way that a good thermometer is useful — they help you understand what’s happening. But I’ve never seen a tool fix a cloud cost problem. I’ve only seen engineers fix cloud cost problems, and usually only when they understood the problem and cared about fixing it. ...

Early at Capital One, I was in an architecture review with a group of engineers working through an architecture problem that had been giving us fits for a few weeks. The room had a “white beard” engineer, a couple of senior engineers, and a couple of newer folks who were, I think, somewhere in their second or third year. The white beard had been at Capital One since before the junior engineers in the room had learned to walk. White beard started his career on mainframes, had personally vetted half the vendors Capital One still employed, and when he spoke — softly, slowly and deliberately, like someone who had learned there was no upside in rushing — everyone including SVPs listened carefully and took notes. The white beard had proposed an approach. It was technically sound and everyone more or less accepted it, and we were moving into the implementation details when one of the junior engineers — she had been quiet for most of the meeting — said something like “I might be missing something, but could we also just…” and then described an approach that was significantly simpler, would have taken about a third of the time to implement, and had better failure characteristics than the solution we were all about to commit to. ...

I’ve sat in a lot of infrastructure architecture discussions over the years, and there’s a pattern I’ve noticed that doesn’t get talked about enough: the conversations that look like they’re about technology are often actually about something else entirely. Who controls what. Who trusts whom. How much autonomy a team deserves. What the organization’s real risk tolerance is, as opposed to the stated one. Take the decision between a shared infrastructure platform and team-owned infrastructure. On the surface, it’s an engineering question — operational efficiency, cost pooling, standardization versus flexibility. And those things are real. But underneath that conversation is almost always a question about power. A shared platform means a central team owns the stack and other teams are tenants. Team-owned infrastructure means each team makes its own choices and bears the consequences. Those aren’t just different operational models; they’re different statements about how much you trust individual teams to make good decisions, and how much you’re willing to pay for that trust in the form of inconsistency. ...

When you’re running a large engineering organization — multiple teams, multiple managers reporting to you — every metric you put on a weekly review becomes a directive. Not because you framed it that way, but because your managers are smart people who understand what you’re paying attention to. The moment something lands on your leadership dashboard, three or four teams start orienting around it simultaneously. I learned this slowly, and then all at once. ...

The obvious signals that a team is in trouble — missed deadlines, attrition, escalating incidents — are obvious precisely because they’re lagging indicators. By the time they’re visible, whatever was causing them has been present for a while. You can respond to them, but you’re responding to a problem that’s already been compounding. The signals I’ve come to pay most attention to are earlier and quieter. They don’t show up in metrics. They don’t surface in project status updates. They surface in skip-level conversations, in the texture of how managers talk about their teams, in what I notice when I drop into a design review. If you’re not looking for them deliberately, it’s easy to walk right past them. ...

Over the course of my career — across Comcast, Capital One, and now AWS — I’ve worked alongside a lot of people for a long time. Long enough to watch careers arc in ways that aren’t visible in any single year, to see who stayed effective and who didn’t, and to notice that the pattern doesn’t follow the obvious script. The conventional theory is something like: the people who last are the ones who found a comfortable niche and settled in. Job security through indispensability, deep expertise in a specific domain, low enough ambition to avoid the burnout that comes from pushing too hard. The long-tenured person as someone who’s optimized for staying rather than for doing. ...

Protecting your time and going dark are different things, and your team can tell which is happening even when you think they can’t. Setting boundaries around evenings and weekends, not being the person who answers Slack messages at midnight — all of that is healthy and sustainable. What I’m talking about is something different: a pattern I’ve observed in leaders who go dark in a way that creates anxiety for their team, not peace for themselves. ...

The career conversation that most managers have sounds something like this: a direct report doesn’t get the promotion they expected, or they get it but felt the process was opaque, or they come in and say they’ve accepted a role somewhere else. And then the manager has a very intense, very real conversation about what that person actually wants from their career, what they see as their next step, whether there’s something that could have been done differently. ...

There’s a temptation, when you’re building software for large organizations, to let the complexity of the customer’s world bleed into the complexity of what you build. The customer has ten business units with different billing requirements. The customer has regulatory constraints that vary by geography. The customer has legacy systems that need to connect to your new thing in ways that weren’t designed to work together. All of this is real. All of it creates pressure to build something that accommodates every edge case, every workflow variation, every exception to the rule. ...