Scrolls
6 min read
On this page

The Two to Three Person Team

Two engineers can move faster than five. This sounds wrong until you account for communication overhead. With two people, there is one communication channel. With five, there are ten. With ten, there are forty-five. The formula is n(n-1)/2, and it explains why small teams outperform large ones per capita at nearly everything.

The two to three person engineering team is the sweet spot for early-stage startups. Large enough to cover each other's blind spots, small enough that coordination is almost free. Most of the best products in tech were built by teams this size in their critical early phase.

Why Small Teams Win

Communication channels by team size:
  2 people  →  1 channel
  3 people  →  3 channels
  4 people  →  6 channels
  5 people  → 10 channels
  6 people  → 15 channels
  10 people → 45 channels

Each channel is:
  - A potential miscommunication
  - A sync meeting someone wants to schedule
  - A Slack thread where context gets lost
  - A code review that sits in a queue

WhatsApp had 35 engineers when it reached 450 million users. Instagram had 13 engineers when it hit 30 million users. At the earliest stages, both had teams of two to three people building the core product. The constraint forced focus — there was no capacity for anything that was not essential.

The magic of two to three engineers is not just fewer meetings. It is that everyone knows everything. There is no "let me check with the team." There is no information asymmetry. Everyone is in the room (or the Slack channel) when decisions get made.

How to Split Work: By Feature, Not by Layer

The most common mistake small teams make is splitting by technology layer:

Bad split (by layer):
  Engineer A: Frontend
  Engineer B: Backend

  Problems:
  - Every feature requires both engineers to coordinate
  - Engineer A is blocked waiting for Engineer B's API
  - Nobody owns the full user experience end-to-end
  - Finger-pointing when things break: "The bug is in the frontend" / "No, it's the API"

The better approach: split by feature or domain area.

Good split (by feature):
  Engineer A: User-facing features (auth, dashboard, billing) — full stack
  Engineer B: Core product features (the main value proposition) — full stack

  Benefits:
  - Each engineer owns their area end-to-end
  - No cross-team dependencies for most features
  - Clear ownership when something breaks
  - Both engineers build broader skills

This requires both engineers to be comfortable working across the stack. In 2026, that is a reasonable expectation. Modern frameworks (Next.js, Remix, Rails, Django) are designed for full-stack development. A backend engineer can write a React component. A frontend engineer can write a database query. Neither needs to be an expert in the other's domain — just competent enough to ship.

The Exception: Infrastructure

If one engineer is significantly stronger at infrastructure (databases, deployment, monitoring), let them own it. But this should be a secondary responsibility, not their primary role.

Reasonable specialization:
  Engineer A: Product features + frontend polish
  Engineer B: Product features + infrastructure & deployment

  Both still work on features. Both still ship end-to-end.
  The specialization is about who handles the shared concerns,
  not about dividing the product into layers.

Pair Programming for Critical Paths

Two engineers working on the same problem at the same time feels wasteful. It is not — when the problem is critical enough.

When to pair:
  - Designing core data models that everything else depends on
  - Building the authentication & authorization system
  - Setting up the CI/CD pipeline (both need to understand it)
  - Debugging a production incident (two sets of eyes, half the time)
  - Onboarding a new team member to the codebase

When NOT to pair:
  - Building a CRUD feature with a known pattern
  - Writing tests for existing code
  - Fixing a CSS layout issue
  - Any task where one person is watching the other type

Pivotal Labs built their entire consulting practice around pair programming. They found that two engineers pairing produced fewer bugs, required less code review, and shared knowledge more effectively than two engineers working separately. For a two-person startup, this matters enormously: if both engineers understand the critical paths, neither is a single point of failure.

The practical version: pair on design decisions and architecture. Solo on implementation. Come back together for review.

Pairing workflow for a two-person team:
  1. Both discuss the approach for 30-60 minutes (whiteboard, call, doc)
  2. One person implements while the other works on something else
  3. Quick review before merging (15-30 minutes, not a formal PR process)
  4. Both understand the design, one wrote the code

Async Communication

A two-person team does not need Slack. It needs a shared understanding of what each person is working on and a way to ask questions without breaking flow.

Async communication tools for small teams:
  - A shared TODO list (Linear, GitHub Issues, a text file in the repo)
  - Short written updates at end of day ("here's what I shipped, here's
    what's next")
  - GitHub PR descriptions that explain the WHY, not just the WHAT
  - A shared decisions log: "We decided X because Y" — prevents
    relitigating the same choices

What you do NOT need:
  - Slack (a DM or group chat works, but the full Slack experience is
    overhead for 2-3 people)
  - Project management software with sprints, story points, and velocity
    tracking
  - Daily standup meetings (a written async check-in is faster)
  - Confluence or Notion with elaborate documentation hierarchies

The goal is low-ceremony communication. Everything should take less than five minutes to write or read. If you are spending more time communicating about work than doing work, you have too much process for your team size.

Decision Logs

At two to three people, decisions happen fast — often in a quick conversation that nobody documents. This is fine until three months later when someone asks "why did we choose Postgres over MySQL?" and nobody remembers.

Minimal decision log format (in a DECISIONS.md file or wiki):
  2026-04-15: Chose Postgres over MySQL
    - Reason: Better JSON support, we need flexible schema for event data
    - Alternatives considered: MySQL (no JSONB), MongoDB (overkill)

  2026-04-10: Monolith, not microservices
    - Reason: Two engineers, one deploy target, simpler debugging
    - Revisit when: We hire engineer #4 or deploy frequency drops

  2026-04-08: Next.js over Remix
    - Reason: Both engineers have Next.js experience, Remix would
      require ramp-up time we don't have

Takes two minutes to write. Saves hours of "why did we do this?" conversations later.

Weekly Syncs, Not Daily Standups

Daily standups for two people are a waste. You already know what the other person is doing because you sit next to them (physically or virtually) and you reviewed their code yesterday.

Weekly sync format (30 minutes, max):
  1. What shipped this week? (5 minutes)
     - Demo if there's something worth showing
  2. What's planned for next week? (5 minutes)
     - Each person picks their top 1-2 priorities
  3. What's blocked or risky? (5 minutes)
     - Surface things that need joint attention
  4. Architecture or design discussion (15 minutes, optional)
     - If there's a decision to make, make it now
     - If not, skip and end early

No:
  - Status reports nobody reads
  - Estimations in story points
  - Sprint ceremonies
  - Retrospectives (just talk about what's not working when it's not working)

Linear, the project management tool, was built by a small team that deliberately minimized process. Their philosophy: process should be proportional to team size. Two people need almost none. Add process only when coordination failures actually occur, not in anticipation of them.

Code Review at Small Scale

With two engineers, code review is a conversation, not a process.

Code review for two-person teams:
  - Review everything, but keep it fast (same day, ideally same hour)
  - Focus on: "Will I understand this in 3 months?"
  - Skip nitpicks on style — use an auto-formatter and stop arguing
  - For small changes: a quick look and a thumbs-up is fine
  - For large changes: walk through it together (pair review)
  - Never let PRs sit for more than 24 hours

What to look for:
  - Missing error handling
  - Security issues (SQL injection, exposed secrets, auth bypass)
  - Breaking changes to shared interfaces
  - Logic errors in business-critical code
  - Tests for non-obvious behavior

The goal is fast feedback, not gatekeeping. If a PR sits for two days at a two-person company, that is two days of wasted work.

Scaling from Two to Three

Adding a third person changes less than you think, if you do it right.

What changes with 3 engineers:
  - Communication channels go from 1 to 3 (manageable)
  - You need clearer ownership areas
  - Code review rotation becomes possible (not everyone reviews everything)
  - Someone can take a vacation without the whole company stopping

What should NOT change:
  - The weekly sync format
  - The feature-based work split
  - The speed of code review
  - The minimal process philosophy

The biggest risk when adding the third person is introducing process prematurely. "Now that we're a real team, we need sprint planning." No, you do not. You need sprint planning when the lack of it causes missed commitments or duplicated work. At three people, a shared TODO list and a weekly sync are still sufficient.

Common Pitfalls

  • Over-specializing. "I only do frontend" on a two-person team means your frontend engineer is blocked when there is backend work and your backend engineer is blocked when there is frontend work. Everyone should be able to work across the stack, even if they have preferences.
  • Too many meetings. Two people do not need daily standups, sprint planning, sprint review, and retrospectives. That is four meetings a week for two people who sit next to each other. Cut it to one weekly sync.
  • Not reviewing each other's code. "We trust each other" is not a reason to skip review. Review catches bugs, shares knowledge, and prevents either person from building something the other cannot maintain.
  • Splitting by layer instead of feature. This creates artificial dependencies and blocks. Split by feature so each person can ship end-to-end without waiting.
  • Adding process in anticipation of problems. Process should follow pain, not precede it. If you do not have a coordination problem, you do not need a coordination tool.

Key Takeaways

  • Two to three engineers is the sweet spot for early-stage startups. Communication overhead is near zero, and everyone understands the entire system.
  • Split work by feature or domain, not by technology layer. Each engineer should own their area end-to-end, from database to UI.
  • Pair on critical decisions and architecture. Solo on implementation. Review quickly before merging.
  • Replace daily standups with a weekly sync. Use async written updates for day-to-day coordination. Keep a decisions log for the choices you will forget in three months.
  • Add process only when coordination failures actually happen, not in anticipation of them. At two to three people, a shared TODO list and a weekly sync are usually all you need.