Engineering Culture

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

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

“Move fast and break things” is a mantra built for a specific context: small team, early product, learning fast — figuring out whether you’re building the right thing at all — matters more than stability, the cost of a broken thing is recoverable. In that context, it makes real sense. Speed is the only asset a small team has that a large organization doesn’t. Breaking things, learning, and fixing quickly is genuinely the right tradeoff when the alternative is being slow and careful about something that might not matter at all in six months. ...

Every engineering team has a brand. Most of them haven’t built it deliberately — it formed on its own, through the experience of people who worked there, the things those people said when they left, the code quality visible in open-source projects or interview processes, and the stories that circulated inside the company about how the team operates. You don’t always choose it; you inherit it, or build it by accident. ...