Hiring the second engineer

For two years the process was: sit near each other, talk. It worked completely. It stopped working the week a third person joined, and it did not stop gradually — it stopped on about day four, when two of us had a conversation the third was not in and shipped something they then had to reverse-engineer.

What actually broke#

• Shared context

  Two people in one room have one mental model. Three have two and a half, and the half is whoever missed a conversation this morning.

• Implicit ownership

  With two people, everything is obviously somebody's. With three, everything is probably somebody's, which is how a thing goes a fortnight without an owner.

• Review by chat

  “Have a look at this?” across a desk does not scale to someone who was not there for the decision that produced it.

Three artefacts, and nothing else#

1. 01
   A decision note per non-obvious call

   Half a page: what we chose, what we rejected, what would make us revisit. In the repository, next to the code. It takes ten minutes and it has ended more repeat arguments than anything else we do.

2. 02
   One name per surface

   Not a manager — an owner. Whoever is named answers questions about it and decides when it is disputed. The list is one file and it is allowed to change, but it is never empty.

3. 03
   A written review, always

   Even for the person sitting next to you. If a review is worth doing it is worth the next person being able to read why the code looks like it does.

What we did not add#

• No estimates in points. We estimate in days and we are honest about the range. Points obscure exactly the uncertainty we want visible.
• No stand-up. Three people already know. It came back later, once, at five people.
• No sprints. Client work arrives on its own rhythm and pretending it arrives in fortnights makes plans that are wrong on purpose.

Hiring for the third seat specifically#

The third person is not “more of the same”. In a two-person studio both people do everything; the third arrives into a system that has habits nobody has ever articulated. So we hired for someone who asks why, and we made the first month explicitly about them writing down the answers they got — which is how half of the decision notes above came to exist.