The Scaling Challenge
Scaling an engineering team is not just about hiring more people. Adding headcount to a team without changing how the team operates often makes things slower, not faster. Brooks' Law ("Adding manpower to a late software project makes it later") captures this reality: communication overhead grows quadratically with team size, and without thoughtful structural changes, the coordination cost eventually exceeds the productivity gained.
As a Tech Lead, you play a critical role in scaling decisions: defining how the system architecture should evolve to support independent teams, advising on team structure, and ensuring that quality and culture survive rapid growth.
Conway's Law
Conway's Law states: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." This is not just an observation; it is a force of nature in software engineering.
Conway's Law Implications
- Architecture mirrors teams: If you have three teams, you will get a three-part system, regardless of whether that is the right architecture
- Inverse Conway Maneuver: Design your team structure to match the architecture you want, and the software will follow
- Communication boundaries: Expect well-defined APIs between services owned by different teams, and tightly-coupled code within services owned by one team
- Reorganization = rearchitecture: When you restructure teams, expect corresponding changes in the software architecture
Team Topologies
The Team Topologies framework by Matthew Skelton and Manuel Pais provides a vocabulary for describing how teams should be organized:
Four Team Types
| Team Type | Purpose | Examples |
|---|---|---|
| Stream-Aligned | Delivers value on a specific business stream | Checkout team, Search team, Notifications team |
| Platform | Provides internal services that stream-aligned teams use | Infrastructure, CI/CD, Developer tools |
| Enabling | Helps other teams adopt new capabilities | Security enablement, Architecture guidance |
| Complicated-Subsystem | Manages a subsystem requiring specialist knowledge | ML/AI team, Video processing team |
Optimal Team Size
Research consistently shows that the optimal size for an engineering team is 5-8 people. Teams smaller than 5 lack diversity of thought and struggle with on-call coverage. Teams larger than 8-10 experience:
- Communication overhead that slows decision-making
- Difficulty for the Tech Lead to maintain context on everyone's work
- Reduced individual ownership and sense of impact
- Stand-ups and planning meetings that take too long
When and How to Split Teams
Signs that a team needs to be split:
- The team has grown beyond 8-10 engineers
- Two subgroups within the team work on largely independent areas with few code dependencies
- Stand-ups and planning meetings feel too long, with many people disengaged
- The codebase has natural service boundaries that map to different product areas
## Team Split Checklist
### Before the Split
- [ ] Identify clear ownership boundaries for code and services
- [ ] Ensure each new team has a viable on-call rotation (min 3 people)
- [ ] Define the APIs/contracts between the new teams' services
- [ ] Identify a Tech Lead for each new team
- [ ] Plan the transition of code ownership and documentation
### During the Split
- [ ] Move repositories or code ownership in your tools
- [ ] Update on-call rotations and runbooks
- [ ] Establish new team channels and communication norms
- [ ] Hold a kickoff meeting for each new team
### After the Split
- [ ] Monitor for integration issues between the new teams
- [ ] Check in after 2 weeks to address teething problems
- [ ] Establish cross-team sync meeting for shared concerns
- [ ] Update organizational charts and stakeholder contactsHiring for Scale
When scaling, the composition of your hires matters as much as the count:
- Experience balance: Do not hire only senior engineers (expensive and creates too-many-cooks problems) or only juniors (insufficient leadership and mentoring capacity). Target a ratio of roughly 1 senior for every 2-3 mid-level and junior engineers.
- Hire ahead of the curve: Start hiring before the team is at capacity. It takes 1-3 months from opening a role to having a productive new team member.
- Culture carriers: Early hires set the culture. Hire people who embody the values you want the team to have.
- Diverse perspectives: Homogeneous teams have blind spots. Actively recruit for cognitive diversity, background diversity, and experience diversity.
Scaling Anti-patterns
- Hiring into the bottleneck: Adding more people to a team whose problem is process or architecture, not headcount
- Premature scaling: Splitting teams before the work justifies it, creating overhead without benefit
- Ignoring culture: Growing so fast that cultural norms dilute because new hires outnumber existing team members
- Monoculture hiring: Hiring from the same few companies or backgrounds, creating groupthink
- No onboarding investment: Hiring rapidly without scaling the onboarding process, leaving new hires to flounder
Summary
Scaling engineering teams is an art that requires balancing technical architecture, team structure, hiring strategy, and cultural preservation. Leverage Conway's Law intentionally, keep teams small and focused, split teams along natural boundaries, and invest in onboarding and culture as you grow. The Tech Leads who navigate scaling well are those who recognize that organizational design is as much an engineering problem as system design.