How to scale an engineering team up and down

Every startup’s engineering need is a curve: launches, quiet stretches, a big customer with a deadline, a pivot. Every startup’s engineering cost is a staircase that only goes up. Headcount rises to meet each peak and then stays, because the only lever for reducing it is a layoff, and nobody builds a layoff into the plan.

The mismatch between the curve and the staircase is where runway quietly goes. This is a playbook for building a team that tracks the curve in both directions. We sell elastic capacity, so we’re describing a model we benefit from; the reasoning is all on the table so you can check it against your situation.

Why down matters as much as up

Founders plan obsessively for scaling up and treat scaling down as a failure mode. But a team that can only grow converts every temporary peak into permanent burn. Hire three for the launch and after the launch you have three salaries and a post-launch roadmap that needs one and a half people. Nobody gets laid off for that. The staircase just holds, at roughly $17,500 per engineer per month fully loaded (the math), and the idle capacity starts inventing projects to justify itself. Some of those projects are useful. The Kubernetes migration usually isn’t.

Being able to scale down without firing anyone isn’t a sad contingency. It’s what makes scaling up affordable, because you can staff a peak knowing the peak’s end has an exit that isn’t a severance conversation.

The core-and-edge structure

The teams that flex well aren’t uniformly elastic. They’re built in two layers with different jobs:

The core is permanent and small. Full-time people who hold the architecture, the context, and the standards. The core is sized to your trough, not your average: the load that exists in the quietest month you can foresee. For a seed-stage company that’s often one to two engineers. The core never flexes, and that stability is the point; continuity is the asset you’re protecting.

The edge is booked against the roadmap. Specialties added for the weeks the work exists: two more full-stack during a push, DevOps two days a week during an infra change, QA in the run-up to launch, design in bursts. The edge grows and shrinks weekly, and shrinking it is an administrative action, not a personnel one. Nobody’s rent depends on your roadmap staying peaked.

The runway consequences of this structure versus hire-for-the-peak are worked through with real numbers in burn rate math; the short version is that on a spiky roadmap it’s months of extra runway at identical peak output.

Scaling up without breaking the core

Adding people to a codebase has a real absorption limit; add too fast and the core spends its whole week onboarding. Rules that keep the edge productive:

1. Scale in weeks, not quarters. Add one specialty, let it land, add the next. A 48-hour lead time (that’s our commitment; demand a number from anyone) makes incremental adds cheap, so there’s no reason to batch them.
2. The core owns the map, the edge owns workstreams. The failure mode is edge engineers waiting on the core for every decision. Give each added person a bounded stream (the integration, the migration, the redesign) with a written brief, and reserve the core’s review for seams and architecture.
3. Write the context down once, spend it many times. A one-page orientation doc (what the product does, how deploys work, where the bodies are buried) turns every future scale-up from a meeting into a link. Teams that can’t write this doc scale badly no matter who they book.
4. Same people, every time. Elasticity only pays if week five’s crew remembers weeks one through four. A rotating cast resets the ramp every booking, which is elasticity with the benefit removed. This is a provider-selection criterion, not a nice-to-have.

Scaling down without losing what you learned

The down direction has its own discipline, mostly about not letting context evaporate:

1. End workstreams with a written close-out. What shipped, what’s half-done, what we’d do next. Costs the edge an hour; saves the next booking a day. Insist on it as a deliverable, not a favor.
2. Merge or kill, don’t park. A half-done branch parked for two months is a rebase archaeology project. Get streams to a mergeable or explicitly-abandoned state before standing the seat down.
3. Keep a heartbeat if the gap is long. For maintenance-mode stretches, one booked day a week keeps deploys working and dependencies current for a few hundred dollars, and means scale-up later starts warm instead of cold.
4. Tell the edge the truth about the roadmap. Good crews plan around honest signals (“quiet until the October push”) and hold your context across the gap. Treating stand-downs as awkward breakups instead of scheduling makes providers hedge, and hedging providers rotate people.

The signals, both directions

Scale up when there’s a named deliverable with a date that current capacity can’t hit; when a specialty gap is burning generalist time (senior engineers hand-rolling deploy scripts is the classic); or when the founder is the bottleneck doing work someone else should own. Notice these are all work-shaped signals with end dates attached.

Scale down when the deliverable shipped; when the specialty’s job is done; when next month’s plan doesn’t name the seat. The test we like: for each seat, write the sentence “in the next four weeks, this seat ships ___.” Seats without a sentence go back to zero days, this week, without drama. Run the test monthly; it takes ten minutes and it’s the whole discipline.

If the same seat has had a sentence every week for two quarters, the opposite signal has fired: that seat is permanent work, and permanent daily work is what full-time hiring is for. Elastic capacity that never flexes is just an expensive employee.

What this asks of you

Honesty about the roadmap, mostly. The core-and-edge model prices your actual plan, which means it punishes the fiction that every quarter is a peak. Founders sometimes find the staircase more comfortable precisely because it never asks “what does next month really need?” The curve-shaped team asks monthly. That’s the cost. The runway is the payback.

If you want to see what your curve prices out to, the week planner lets you build the peak and the trough versions of your team side by side. The difference between those two numbers, times the months you’ll spend at trough, is what the staircase was going to cost you.