When I became CTO at BeyondIRR, the engineering team was me and one other engineer. Today it's 15 people across data, backend, and frontend. Here's what nobody tells you about making that jump.
Mistake #1: Hiring for Skills, Not Judgment
In the early hires, I optimised for technical skills. Could they write clean Python? Did they know FastAPI? The result was a team of individually capable engineers who made locally correct decisions that were globally wrong. Someone rebuilt a service from scratch instead of extending an existing one because they personally preferred Go. Nobody told them not to.
Judgment means knowing when to build and when to reuse. When to push back and when to move fast. This is coachable but only if the person already has the instinct.
Mistake #2: Not Writing Things Down
At two people, everything lived in Slack and my head. At five, cracks appeared. At eight, we had three different engineers who had independently made different assumptions about our database migration strategy. We spent a week untangling it.
We introduced Architecture Decision Records (ADRs) — short documents that capture what we decided, why, and what alternatives we considered. The format doesn't matter. The discipline does.
Mistake #3: Staying Technical Too Long
This one hurt. I loved writing code. At 10 engineers, I was still reviewing every PR, still involved in every architecture discussion. I was the bottleneck I never saw coming.
The fix wasn't to stop being technical — it was to be technical differently. Write the RFC, not the code. Set the standard through the review, not by doing it yourself. The hardest skill in engineering leadership is trusting that someone else will find a solution you might not have thought of, and that's actually a good thing.
What I'd Do Differently
- Write an engineering principles document before you hire engineer #3.
- Give engineers explicit ownership of systems, not just tasks.
- Do weekly 1:1s religiously — this is where you learn what's actually broken.
- Celebrate decisions made without you. That's the sign the team is healthy.
The 2-person version of this team shipped faster on any individual feature. The 15-person version ships more, more reliably, with less bus factor. Both are correct. They're just different organisations.