The engineering team is the product. Not in the cliché sense — literally. The architecture of your software is a mirror of the architecture of your team. Conway’s Law has been validated a thousand times: organisations build systems that replicate their own communication structure.
This means building a great engineering team is your most important technical decision. More important than cloud provider, framework choice, or any architectural pattern.
Here’s what I’ve learned building engineering teams from scratch.
Team Size and the Communication Problem
The most common startup engineering mistake: growing the team before you understand the work.
A 3-person engineering team can move extremely fast. They share context implicitly, communicate in real-time, and have no coordination overhead. When that team hits 8 people, something changes. Decisions need more explicit communication. Knowledge isn’t automatically shared. Coordination becomes work.
Jeff Bezos’ two-pizza rule is a useful heuristic, but the deeper principle is: communication cost grows as n². Every person you add increases the number of communication pathways by n-1. A 3-person team has 3 pathways. A 10-person team has 45.
Before hiring, ask: what’s the bottleneck? If it’s engineering velocity, hire engineers. If it’s clarity of direction, hire a product manager first. If it’s infrastructure reliability, hire a senior DevOps/platform engineer. Adding general headcount to a problem of focus makes the problem worse.
What I Actually Look For in Interviews
Most engineering interviews test what someone knows. I try to test how they think.
The debugging question
I give candidates a broken system with a production bug: here are the logs, here are the metrics, figure out what’s wrong. I’m not checking whether they find the bug. I’m watching:
- Do they form hypotheses before diving in, or do they immediately start changing things?
- Do they verbalise their reasoning, or go silent?
- When they hit a dead end, do they step back and re-evaluate, or keep digging in the same direction?
The debugging question reveals problem-solving character better than any algorithm question.
The system design question for a system they’ve built
“Walk me through a system you’ve built end-to-end. What would you do differently now?”
This surfaces intellectual honesty. Engineers who can’t critique their own past decisions either haven’t grown or aren’t self-aware. Both are problems.
The disagreement question
“Tell me about a time you disagreed with a technical decision that was made anyway. What did you do?”
The answer I’m looking for: they made their case clearly, then committed fully once the decision was made. The failure modes are: never disagreed (low agency), didn’t raise their concern (poor communication), or sabotaged the decision after losing (toxic).
Onboarding: The 90-Day Investment
A new engineer’s first 90 days determine 80% of their long-term trajectory on the team. Most startups under-invest here.
Week 1: Context only. No coding expectations. Every meeting, every Slack channel, every system diagram. The goal is understanding before contributing.
Weeks 2-4: Small, self-contained tasks with clear boundaries. Bug fixes, small features, test improvements. Success builds confidence and surfaces gaps.
Month 2: First independent feature from design to production. Pair with a senior engineer, but they drive. This is where the real learning happens.
Month 3: Lead a small project end-to-end including the non-engineering work: stakeholder communication, scoping, timeline estimation.
The most important thing: assign a onboarding buddy (not their manager) on day one. Someone they can ask “stupid” questions without worrying about performance perception.
The Career Ladder Nobody Told Me to Build
Early-stage startups often have no career ladders. Engineers are “engineers.” The first time someone asks about growth and promotion, you’re scrambling.
Build it early. Not because it’s bureaucratic — because it answers the question every engineer has: “what does good look like, and what does the path forward look like?”
Ours has five levels with three dimensions at each: technical scope (what problems you can independently tackle), leadership (what influence you have beyond your own work), and leverage (how much you multiply the output of people around you).
The levels aren’t about tenure. A 2-year engineer who has expanded their scope and is actively multiplying others should move up. A 5-year engineer who is doing the same work they were doing in year 1 should not. This needs to be explicit and communicated.
Psychological Safety Is a Performance Variable
Google’s Project Aristotle found that the highest-performing teams shared one characteristic above all others: psychological safety. Team members felt safe to take risks and be vulnerable.
In engineering terms: they could say “I don’t know,” raise concerns about technical decisions, point out mistakes (including their own), and propose unconventional ideas without fear of embarrassment or punishment.
Creating this as a leader requires:
Modelling it yourself. If I, as CTO, say “I got this wrong, here’s what I should have done” — it gives everyone permission to do the same.
Responding well to bad news. When an engineer comes to you with a production incident they caused, your response in that moment shapes the team’s behaviour for months. React with curiosity (“what happened?”) not blame (“why did you do that?”).
Rewarding the raising of problems, not just the solving of them. An engineer who surfaces a risk early — before it becomes a crisis — has provided enormous value. Acknowledge it explicitly.
The Feedback That Changed How I Manage
About a year into the CTO role, I had a 360-degree feedback session. One piece of feedback from a senior engineer I respect deeply:
“You’re brilliant at seeing the right answer, but you sometimes short-circuit the team’s thinking by sharing your view before they’ve had a chance to develop theirs.”
It was accurate. And it cost us ideas I’ll never know about — because people who reached a different conclusion than me in the first 10 seconds just nodded along.
Since then, I’ve adopted a practice: in any technical discussion, I speak last. If I have a strong view, I ask questions that help the team surface the considerations themselves. Often, they reach the right answer without me having to say a word. When they don’t, my reasoning lands differently — as a final input rather than an anchor.
Strong technical leaders are often the least vocal person in the room. The team’s clarity is more important than your own.