There’s something electric about a tiny team… everyone’s on the same page, decisions happen in a hallway chat, and the work just seems to fly out the door. Whether you’re two engineers knocking out greenfield features or a half-dozen folks building a prototype in a weekend hackathon, that scrappy energy feels unstoppable. But as you add people, you also add conversations… and pretty soon you’ll recognize Brooks’ Law in action: more people means more communication overhead, which can actually slow you down before it ever makes you faster.
At first it’s almost imperceptible. You snag someone new, onboard them, show them the ropes… and before they’re up to speed you’re fielding questions, syncing context, juggling reviews. Leadership asks for a quick prototype and gets an estimate in weeks instead of hours. Team members joke about moving in molasses—when all you’ve really done is swap one-on-one chats for group meetings, written memos, and calendars full of “sync” invites. Then there’s the product itself. In the greenfield days you’re adding features faster than you can test them. But once you’re in production, tech debt piles up, risk of downtime grows, and every change carries weight. A small team can push code blind and fix it later… a larger team, with more users and more at stake, needs guardrails: testing, staging, rollbacks.
What You Can Do About It
All of these protections and processes slow you down, but they’re what let you scale without burning the place down. Growth will happen in many cases whether you want it to or not (assuming your team is finding success). In many ways this growth is usually only seen in the positive ways it contributes; over time those new folks bring fresh ideas, deeper expertise, and the capacity to tackle bigger challenges. You’ll see the value in specialized roles, in clearer handoffs, and in having the bandwidth to drive multiple efforts in parallel. It just takes time—and a plan—to get there smoothly.
note: once you’re beyond a dozen people, you’ll naturally want to tap your earliest engineers as leads or first-time managers. That jump from IC → Lead → Manager demands coaching, mentoring and conflict-resolution skills few people learn on the job. I’ll save this conversation for a future post, but keep it in mind now—without intentional training, your stellar builders might struggle in their new roles.
However that growth comes with trade-offs. You can’t complain about slower cycles without acknowledging the safeguards and skills you’re building. And if you’re thoughtful about onboarding, lightweight cadences, clear decision ownership and when to introduce structured reporting, you’ll keep the momentum alive… even as the team grows. All of this requires explicit buy-in from the senior leadership team. They have to understand that moving to a larger team structure will not always result in faster delivery necessarily, at least in the short term. It's the proverbial saying of "9 mothers can't deliver a baby in 1 month" ... however 9 mothers operating as a team in "the village" could arguably help provider stronger long term outcomes for the children.
Getting stakeholders on board with a longer term vision like that can be challenging, especially when they are focused on shorter term deliverables and metrics ... but that's the challenge in leadership, to help others understand the value that comes with introducing what can sometimes feel like overhead. If you can do it thoughtfully, you can gain the benefits. If you do it mindlessly, just because "that's how its done", then you end up with worthless ceremonies.