How to Run an Engineering Team

Running an engineering team is part air traffic control, part therapy, and part bet-the-company decision making. After a decade of leading teams from three engineers in a garage to a 140-person org shipping nightly to enterprise customers, I've collected a few opinions that have held up. Most of them are not what I would have written down five years ago.

Here is the playbook I wish someone had handed me on day one.

Hire for trajectory, not pedigree

The best engineers I've ever worked with did not come from the obvious places. One was a self-taught ex-bartender who taught himself Rust during the pandemic. Another spent six years in academic physics before writing her first production line of code. What they shared was a steep slope. They were measurably better every six months, not just more experienced.

When I interview now, I ask candidates to walk me through something they built two years ago and explain what they would do differently today. If the gap is small, I worry. If they roast their old self for forty minutes, I get excited.

Make the org chart match the architecture

Conway's Law is real, and ignoring it is the most expensive mistake leaders make. If your billing system is owned by three different teams across two time zones, your customers will feel that fragmentation in every invoice. Draw your service boundaries first, then draw your team boundaries to match. When the architecture changes, the org has to change with it. I re-org roughly every nine months for this reason. People hate it for two weeks and thank me six months later.

Defaults beat policies

You cannot police your way to a healthy engineering culture. You can, however, make the right thing the easy thing. We standardized on one language for backend services, one deploy pipeline, and one observability stack. Engineers can deviate, but they have to write a one-page proposal explaining why. Ninety-five percent of the time they don't bother, which is exactly the point. The remaining five percent produce real innovation because they had to think hard before doing something different.

Run the team like a portfolio

At any given time I want roughly seventy percent of engineering capacity on known, high-confidence work, twenty percent on bigger bets that might pay off in two quarters, and ten percent on weird stuff that probably won't ship. That last bucket is non-negotiable. It is where our best products have come from, including a feature that now drives nearly a third of revenue and started as a hackday joke.

If a leader tells me they have zero capacity for the ten percent, I read that as a planning failure, not a resource problem.

Protect the maker's schedule

Every meeting on an engineer's calendar before noon costs you roughly four hours of real output, not the thirty minutes the calendar shows. We block Tuesday and Thursday as no-meeting days across the entire org. Standups are async in Slack threads. Design reviews happen in writing first, then a thirty-minute live discussion only if the doc has unresolved comments. Our planning meeting is forty-five minutes, not two hours, because the prep happens in a shared doc the day before.

Make on-call a feature, not a punishment

If your on-call rotation is the worst week of the quarter, your system is telling you something. We treat the pager as a product. Every page that wakes someone up generates a ticket the next morning, and reducing on-call load is a top-three priority for the platform team every quarter. Our 3am pages dropped by ninety percent over eighteen months once we started measuring it like a customer-facing metric.

Tell the truth about timelines

Engineering leaders have a bad habit of giving the timeline they think the CEO wants to hear. I have learned to give three numbers: the optimistic case if everything goes well, the realistic case based on similar past projects, and the pessimistic case if the unknown unknowns bite us. Then I tell the business which one I'd bet my own money on. This has cost me a few uncomfortable conversations and saved me from dozens of broken commitments.

Praise loudly, correct privately, fire quickly

Nothing erodes a team faster than a known low performer who never gets the conversation. The first time I delayed firing someone for six months out of misplaced kindness, I watched two of my best engineers quietly start interviewing. Now, when I know, I act within two weeks. I owe it to everyone else on the team.

On the flip side, I send at least one specific, public note of appreciation every Friday. Not a generic 'great week team' but a callout of a specific decision or piece of work. It costs nothing and compounds enormously.

The only metric that matters

After all the OKRs and dashboards, the one signal I trust most is whether the team is still excited to ship on a Monday morning. If the answer is yes, almost everything else is fixable. If the answer is no, no roadmap or comp adjustment will save you. Run your team for that Monday morning energy and most of the other problems take care of themselves.

That is the whole job. Hire well, remove obstacles, tell the truth, and protect the joy of building. Everything else is just tactics.