When I joined the fintech startup as CTO, the engineering team was small enough that we could hash out every decision over lunch. Five of us in a room, whiteboarding architecture, shipping features the same week we specced them. It was fast, messy, and it worked.
Then we started growing.
By the time we hit fifteen engineers, things that used to happen naturally – knowledge sharing, aligning on priorities, knowing who owned what – stopped happening on their own. Nobody did anything wrong. The team just outgrew its own communication patterns. I remember one week where two engineers independently built overlapping caching layers because neither knew the other was working on it. That was the moment I realized: scaling a team is a fundamentally different problem than building a product.
The stages nobody warns you about
There’s no smooth curve from small team to big team. It’s a series of phase transitions, and each one breaks something that was working fine before.
Around 10 engineers, everything runs on shared context. You all know the codebase, you all know each other, decisions are fast. Feels great. Savor it.
At 25 to 30, you wake up one morning and realize you have actual teams now. Dependencies show up. Duplication shows up. That thing where you just shout across the room to coordinate? Gone. You need to be intentional about who talks to whom about what.
At 40 to 60, you need real structure. Managers. Defined roles. Onboarding that goes beyond “ask anyone.” I watched this transition at the fintech startup and saw it at Google for Startups Seoul in 2018 too – startup founders hitting this wall where the informal culture that made them fast was now making them slow. Every single one of them resisted adding structure. Every single one eventually had to.
At 80 to 100, you’re doing organizational design whether you like it or not. Cross-team alignment becomes someone’s actual job. Architecture decisions need governance. Career paths matter because people will leave if they can’t see a future.
Ownership has to be explicit
This was the hardest lesson for me. At a small startup, ownership is fluid. Whoever cares most picks it up. That’s a feature, not a bug – until it stops working.
At the fintech startup we moved to small, mission-focused teams. Each team owned a clear slice of the product: the domain, the code, the on-call rotation, the technical direction. We wrote it down. A simple team charter – here’s what we own, here are our interfaces, here’s who’s on-call. Nothing fancy.
The effect was immediate. Fewer “who should I ask about this?” questions. Faster decisions. Less duplicated work. Turns out people move quickly when they know their boundaries.
The classic team shapes held up well for us:
- Stream-aligned teams delivering customer value end to end
- Platform teams providing shared infrastructure
- Enabling teams – temporary experts that unblock others
- Deep-speciality teams for the genuinely hard subsystems
Communication doesn’t scale by accident
At 10 people, context spreads by osmosis. You overhear things. You absorb the state of the project just by sitting in the same room.
At 50, that’s completely gone. If you don’t write it down, it didn’t happen.
We learned this the hard way. The practices that actually helped:
- Short written updates after decisions. Not meeting notes. Actual “here’s what we decided and why.”
- Weekly demos. Not polished presentations. Just “here’s what shipped, here’s what’s stuck.”
- Lightweight architecture decision records for anything that changes a shared interface.
- Clear escalation paths. When something is on fire, people need to know who to call without digging through a wiki.
The goal is never more meetings. It’s fewer surprises.
Process should follow pain
I’ve seen teams add process preemptively – policies for problems they haven’t hit yet. It rarely works. Process should show up when the pain of not having it outweighs the overhead of maintaining it.
At the fintech startup, our process grew roughly like this:
- Early days: Code review. A deployment checklist. Basic on-call.
- Growing pains: Incident response runbooks. A planning cadence. Team charters.
- Later: Engineering levels. Hiring rubrics. Decision records for cross-cutting changes.
One thing that helped a lot: tiered decision authority. Small decisions stay inside the team. Medium decisions involve peer teams. Big decisions get a written proposal and a review window. This kept us from bottlenecking everything through a single approval chain.
Hiring is the long game
Scaling headcount without scaling hiring quality will hurt you for years. We put rubrics in place before we ramped hiring. Trained interviewers. Calibrated scoring across panels. It slowed us down initially but the consistency paid off.
Onboarding was the other half. A 30/60/90 day plan with real milestones. A buddy for every new hire. A living checklist that we actually updated when things changed. The faster someone ships their first meaningful change, the faster they feel like they belong.
Invest in the platform early
Every team rebuilding the same deployment pipeline or logging setup is a team not shipping product features. We stood up a small platform team earlier than most people would recommend, and I’d do it again.
Standardize the expensive stuff – languages, infrastructure patterns, observability tooling, security practices. Leave room for teams to make their own choices where it doesn’t create systemic risk. That balance is never perfect. You just keep adjusting.
Technical debt compounds with team size. The more people writing code, the faster it accumulates. Give it an owner. Give it time. If nobody is responsible for paying it down, nobody will.
Culture doesn’t transmit itself
This one hit me at Google for Startups Seoul. Talking to founders from all over Asia, the pattern was the same. They had a strong culture at 10 people. At 40, new hires didn’t absorb it. The founders were frustrated because they thought culture was something you just had, not something you built and maintained.
Culture scales when values are written down, repeated constantly, and – most importantly – modeled by leaders. Recognize behaviors, not just outcomes. Document expectations in an engineering handbook instead of relying on tribal knowledge. Celebrate progress. Do blameless postmortems and actually mean it.
What it comes down to
Scaling from 10 to 100 engineers isn’t an engineering problem. It’s an organizational design problem. The technical work is the easy part. The hard part is making ownership, decisions, and communication explicit enough that dozens of people can move fast without stepping on each other.
Get that right and growth is a multiplier. Get it wrong and every new hire makes you slower.