There are four ways to start a new product when your engineers are fully consumed by the system already in production. Two of them create real capacity. The other two consume the capacity they were meant to create, which is why the new product still has not started despite everyone agreeing it should.
The constraint is not headcount and it is rarely budget. It is that your senior engineers' attention is the scarcest thing in the company, and most solutions quietly spend it.
Key takeaways
- Measure supervision cost, not day rate: The real price of an option is how much of your senior team's week it takes.
- Hiring does not help this year: Six months to productive is the optimistic case.
- Renting developers usually costs capacity: Someone has to direct and review them, and that someone is your bottleneck.
- Handing over a whole product is the only option that does not spend your team: If the boundary is drawn properly.
Option 1: hire
The obvious answer, and the right one for a permanent increase in the work you do. It is the wrong answer for starting something this year.
Realistically: several weeks to write the role and search, weeks of interviews, a notice period, then months before a new engineer is productive in a system they do not know. Through all of it, the people doing the interviewing and onboarding are the same senior engineers who have no time, so your capacity falls before it rises.
Hire if you are permanently short. Do not hire to start a project that needed to begin last quarter.
Option 2: pause maintenance
Sometimes proposed, almost never survivable. The existing system is what pays for everything, including the new product. Deferring its maintenance moves cost forward rather than removing it, and the cost comes back with interest at the worst possible time.
The honest version of this option is smaller: deliberately reduce the scope of what you maintain, retire a feature nobody uses, accept slower response on a low-value integration. That is worth doing and it frees days, not months.
Option 3: rent developers
Staff augmentation. Individual engineers join your team, work in your repository, and follow your direction.
This works when you have capacity to direct and review, and you are short of hands rather than short of attention. If your constraint is attention, it makes things worse: every rented developer needs onboarding, code review, architectural guidance and someone to answer questions, and all of that comes from the same senior people you were trying to protect. Teams frequently report being busier after adding contractors than before.
There is a version that works: renting people to take over well-defined maintenance while your own team moves to the new product. That inverts the problem usefully, because maintenance is better specified than new work and needs less direction.
Option 4: hand over a whole product
An external team takes a product, not a seat: scoping, building, running it, on its own surface, with its own on-call. You set direction and priorities and review working software on a regular cycle.
This is the only option where your engineers' time is not the input. It requires three things to be true, and it fails when any of them is missing. The new product must be separable from the existing system, connected through an agreed interface rather than woven through it. The boundary has to be written down before code is written. And you need someone internally who can make decisions about that interface, though that is hours a month rather than days a week.
Comparing them honestly
| Time to start | Cost to your senior team | Best when | |
|---|---|---|---|
| Hire | 4 to 8 months | High during onboarding | Permanent increase in workload |
| Pause maintenance | Immediate | Low now, high later | Never, at full scale |
| Rent developers | 2 to 6 weeks | High and ongoing | You have direction capacity spare |
| Hand over a product | 2 to 6 weeks | Low after the first week | The new product can be separated |
The column that decides it is the middle one. If you had spare senior attention, you would have started the product already.
We go through the mechanics of the fourth option in building a new product without pulling your team off.
Before you choose, measure
It is worth checking that the capacity really is gone. Most teams have never measured where the engineering week goes, and the split between maintenance, interruption and new work is often different from what everyone assumes. Four numbers from tools you already run will tell you, and we cover them in maintenance load versus roadmap.
Ali Boran Gazel