When we talk about scaling a team, we think about scaling up. Adding more people. More throughput. More power.

What we don’t often discuss is the very common case of scaling down.

Scaling down can happen because the product is mature and only requires a few people for maintenance. That’s perfectly healthy.

But sometimes, the market forces our hand. Maybe the budget has changed. Maybe our lead developer found a new job. All of a sudden, our team is getting smaller by accident.

When a team of 6 loses a member, it’s business as usual. Especially when it’s temporary. We adapt the planning a little, divide up some responsibilities, and continue working.

But something happens when team size drops below a critical mass.

Once a product is live, developers do more than just build features. Depending on the number of users, the quality of the product, and the rate of change, a certain FTE capacity will be dedicated to “operations” instead of building new stuff. Whether a team has 5 developers or 1, the operational load remains about the same. If the team becomes so small that almost all of its capacity is dedicated to operational tasks, its nature changes fundamentally. It has become a skeleton crew. Its mission is to keep the lights on and survive.

The team will just keep serving existing customers, but will not grow the product for a while.

It’s unfortunately common for organizations to refuse to accept the reality of a skeleton crew. People love to pretend it’s still business as usual. They’ll want to hang on to the roadmap and the promises made to customers. They want to grow the product even though they know there is no capacity.

This leads to some kind of wishful thinking where we come up with a plan to do more with less. We all know heroic tales of those teams that turned it around on a shoestring. It has been done. It is not impossible. But it is very risky. It requires strong leadership.

If we want to get through this difficult period, communication needs to be crystal clear. Empty the roadmap. Cancel deadlines. Clear the backlog.

The smaller the team the more important it is to manage expectations. To say No to ideas. To do less. Our ambitions need to be limited and our plan hyperflexible. When running a skeleton crew, we’re in operational mode first. Whatever time is left gets dedicated to development. The plan should reflect this.

Our main goal will be to get through this period without losing even more people. When the team is tiny and the workload is boring, it creates a perfect storm for discontent. The last thing we want is for another key person to go. Leadership must incentivize these people to stay by giving them a clear timeline for the end of the drought. Keep them in the loop of budget and hiring decisions. Don’t dangle the “cool work will come” carrot if we can’t guarantee it.

Scaling down before the product is mature will always stifle its growth. We need to accept this reality instead of pretending we’re still on track. Apple trees can survive the winter, but we don’t expect them to grow fruit while it’s snowing. They focus on survival and hang in there until spring.