Notes on running an engineering team

Most advice about running engineering teams is written by people whose teams no longer exist, or by people whose teams are too large for the advice to be relevant to anyone else. What follows is neither. It is a set of notes from a specific team at a specific stage — small, technical, ambitious, and not yet profitable.

On meetings

The honest answer is that I cannot tell you whether your team has too many meetings. I can tell you that the engineers can. If you have not asked recently, you are probably the meeting.

A standup that exists to inform the manager is a tax. A standup that exists to inform the team is a tool. The two look identical to a passing observer.

On planning

We tried two-week sprints. We tried no sprints. We tried quarterly OKRs. What worked, in the end, was a written rolling plan — one page, updated weekly, owned by the tech lead, read by everyone before any planning conversation. Almost all the friction we had attributed to process turned out to be friction from not having a shared written artifact.

On hiring slowly

The single highest-leverage thing I did in 2025 was not hire someone. I had the offer drafted. I had the budget. I had the board’s blessing. I did not send it.

The cost of a wrong hire at five engineers is the cost of redoing six months of culture. The cost of a slow hire is six months without a person. The second cost is real but recoverable. The first is not.

On code review

Code review is the single most under-rated mechanism for transmitting taste. It is also the single most over-rated mechanism for catching bugs. Treat it as a teaching surface, and the bugs are a side effect; treat it as a quality gate, and you will get neither.

On writing things down

Almost every conflict I have mediated turned out, on close inspection, to be two people working from different unwritten assumptions about the same decision. The fix is boring: write the decision down, before the conflict, with the reasoning. Boring fixes work.

A few rules of thumb that survived the year:

• Default to the written artifact, not the meeting.
• Treat code review as a teaching surface, not a quality gate.
• Hire one role slower than the org chart says you should.
• The cost of a missed hire is recoverable. The cost of a wrong one is not.