At 2 engineers, you do not need process. You sit next to each other (physically or virtually), discuss everything in real time, and ship fast. At 10 engineers, the lack of process is why nothing ships. The transition between these states breaks most engineering teams.
The 2→4 Transition: Adding Minimum Process
What Breaks at 3-4 Engineers
When your third or fourth engineer joins:
- Not everyone is in every conversation anymore
- Decisions happen without full team awareness
- Code conflicts increase because people work on the same areas unknowingly
- Knowledge starts siloing — person A knows the payment system, person B knows the API
What to Introduce
Written daily standups (async)
Done yesterday: [specific tickets]
Working on today: [specific tickets]
Blocked by: [specific blocker or "nothing"]
This takes 3 minutes to write and eliminates "what is everyone working on?" confusion.
Mandatory code review (1 reviewer minimum)
Every PR requires at least one approval before merging. This:
- Catches bugs before production
- Spreads knowledge (reviewer learns the code)
- Establishes coding standards organically
- Creates accountability
Set a target: reviews completed within 8 hours of submission.
2-week sprint cadence
- Monday: Sprint planning (1 hour). What are we building this sprint?
- Daily: Written standup (async)
- Thursday (week 2): Sprint demo (30 minutes). What did we ship?
- Friday (week 2): Retro (30 minutes). What worked, what didn't?
This cadence provides rhythm without bureaucracy.
Basic documentation
- Architecture diagram (one page showing all services and their connections)
- Setup guide (how to run the project locally)
- Deployment process (how code gets to production)
What NOT to Introduce Yet
- Sprint points or velocity tracking (too few data points)
- Multiple project management tools
- Formal architecture review process
- Dedicated project manager role
The 4→7 Transition: Adding Structure
What Breaks at 5-7 Engineers
- Code review becomes a bottleneck (everyone reviews everything)
- Sprint planning takes too long (too many voices, too many opinions)
- Someone needs to make final technical decisions (consensus does not scale)
- Communication overhead increases quadratically (5 people = 10 communication paths, 7 people = 21)
- Onboarding new engineers takes longer because the codebase is larger and less familiar
What to Introduce
Tech lead role
Designate one senior engineer as tech lead. Their responsibilities:
- Final say on architecture decisions
- Code review for critical paths
- Mentoring mid-level engineers
- Sprint planning facilitation
- Technical debt prioritization
The tech lead still writes code (50-70% of their time). They are not a manager — they are an engineer with additional decision-making responsibility.
CODEOWNERS file
Assign ownership areas:
# .github/CODEOWNERS
/src/payments/ @alice @bob
/src/api/ @charlie @david
/src/frontend/ @eve @frank
/infrastructure/ @alice
This routes PRs to the right reviewers automatically and establishes clear ownership.
Structured communication channels
Replace one #engineering channel with:
- #eng-standups (daily updates, no discussion)
- #eng-discussion (technical debates, architecture questions)
- #eng-deployments (automated deploy notifications)
- #eng-incidents (production issues, on-call communication)
Definition of Done
Write it down:
- Code reviewed and approved
- Tests passing (unit + integration)
- No linting errors
- Documentation updated (if applicable)
- Deployed to staging and verified
- Product owner accepted (if feature work)
This prevents "done means different things to different people" arguments.
On-call rotation
With 5-7 engineers, production issues cannot always go to the same person. Establish a weekly on-call rotation with clear escalation paths.
What NOT to Introduce Yet
- Multiple teams (stay as one team until 7-8)
- Engineering manager (tech lead handles people topics)
- Quarterly planning (sprint-level planning is sufficient)
- Complex CI/CD governance
The 7→10 Transition: Adding Teams
What Breaks at 8-10 Engineers
- Single team standup is too long (10 people × 2 minutes = 20 minutes, feels unfocused)
- Sprint planning is unwieldy (too many tickets for one session)
- Code review across all areas slows everyone down
- Technical decisions require too many stakeholders
- Deployments conflict (teams step on each other)
What to Introduce
Sub-teams (2-3 teams of 3-5 engineers)
Split by product domain:
- Team A: Core product features (4 engineers + tech lead)
- Team B: Platform/infrastructure + integrations (3 engineers + tech lead)
- Team C: Growth features + analytics (3 engineers)
Each team runs its own sprint. Cross-team dependencies are identified in planning and coordinated by tech leads.
Cross-team coordination meeting
Weekly, 30 minutes. Tech leads only:
- What is each team working on this sprint?
- Are there dependencies between teams?
- Any architectural changes that affect multiple teams?
- Any shared infrastructure changes needed?
RFC (Request for Comments) process
For changes that affect multiple teams or establish precedent:
- Author writes a short document: problem, proposed solution, alternatives, tradeoffs
- Shared with relevant stakeholders for 48-hour async review
- Comments addressed, decision made by tech lead(s)
- Decision recorded in decision log
This prevents both: "one person made a decision without consulting anyone" and "we had a 2-hour meeting that could have been a document."
Feature flags
With multiple teams deploying frequently, feature flags become essential:
- Teams can merge code without immediately exposing it to users
- Reduces deployment conflicts
- Enables gradual rollouts
- Simplifies rollback if something goes wrong
Dedicated CI/CD pipeline per team (or domain)
Monorepo with per-team pipelines, or separate repos per domain. The goal: Team A's deployment does not block Team B's deployment.
What NOT to Introduce Yet (at 10)
- Engineering VP or Director (tech leads report to CTO/founder)
- Formal performance review process (informal 1:1s are sufficient)
- Complex multi-quarter roadmapping
- Separate QA team (testing is still every engineer's job)
Tooling Evolution
At 2-4 Engineers
- GitHub + simple PR process
- Linear or Trello for task tracking
- Slack for communication
- Manual deploys or basic CI/CD
At 4-7 Engineers
- GitHub with CODEOWNERS + branch protection
- Linear with proper sprint boards
- Slack with structured channels
- CI/CD with automated tests, staging auto-deploy
At 7-10 Engineers
- GitHub with required reviewers per area, status checks
- Linear with team-specific projects + cross-team views
- Slack with team channels + cross-team coordination channels
- Full CI/CD: automated tests, staging deploy, production deploy with approval
- Feature flags (LaunchDarkly, Flagsmith, or custom)
- Error monitoring (Sentry) with team-specific alerting
- Performance monitoring (application + infrastructure)
The Augmentation Advantage at Each Stage
At each transition, augmented developers can accelerate the process:
2→4: Add 1-2 developers immediately while you hire for the leadership role you need in-house.
4→7: Add a team while your tech lead establishes process. Augmented developers follow process — they do not need to create it.
7→10: Add a full sub-team with its own tech lead. This team operates semi-independently, following your established patterns.
The advantage of augmentation during scaling: you get capacity immediately while building the process infrastructure to support permanent growth.
Warning Signs the Transition Is Failing
Watch for these signals that your current process has outgrown your team size:
- Sprint completion rate below 70% for 3+ consecutive sprints
- Cycle time (ticket to production) increasing month over month
- Developers frequently blocked waiting for reviews or decisions
- Same bugs appearing repeatedly (systemic issues not being addressed)
- New engineers taking longer than 3 weeks to ship their first feature
- Retrospective action items never getting implemented
If you see 3+ of these simultaneously, you need a process intervention. Do not add more developers until the process supports your current team size.