Engineering Capacity Planning for Small Teams
Engineering capacity planning at small team scale is the practice of knowing what your team can actually ship in a quarter and aligning commitments accordingly. The discipline does not require Jira ceremony. It requires honesty about velocity, time absorbed by maintenance, and the difference between scheduled hours and shipping hours. The teams that plan honestly ship what they promise. The teams that do not promise more than they can deliver.
What you actually need to know
- Engineers ship 60 to 70 percent of their time. The rest goes to overhead.
- Reserve 15 to 25 percent for unplanned work.
- Reference past work for effort estimation.
- New hires ramp over four months.
- The honest plan that includes reserves survives reality.
Element
Reality
Pure shipping time per engineer
60 to 70 percent
Meetings, review, overhead
20 to 30 percent
Maintenance and support
10 to 20 percent
Reserve for unplanned
15 to 25 percent
New hire month one
10 percent of full capacity
New hire month four
90 percent of full capacity
The core argument
Capacity planning at small team scale is one of those disciplines founders avoid because it feels bureaucratic, like something you graduate into once you have a PM and a Jira board. It does not need any of that. What it needs is honesty, and honesty is the difference between a team that ships what it promised and a team that disappoints quarter after quarter.
The honest plan acknowledges that engineers do not spend 100 percent of their time shipping new work. Roughly thirty to forty percent goes to meetings, code review, support escalations, maintenance, and overhead. The plan that assumes 100 percent capacity always slips. The plan that assumes 60 to 70 percent ships on time.
The other reality is unplanned work. Customer escalations. Security issues. Production incidents. Each is unavoidable. The plan that has no reserve for unplanned work converts every emergency into displaced planned work. The team falls behind. The reserve absorbs the chaos without destroying the plan.
The teams that get this right have realistic plans. The teams that do not commit to fiction. The fiction breaks at the end of the quarter when the work was not shipped. The team gets the blame. The plan was the problem.
The capacity model
Component
Typical share of engineer time
Active shipping work
60 to 70 percent
Meetings and reviews
15 to 20 percent
Maintenance
5 to 15 percent
Support escalations
5 to 10 percent
On call when scheduled
Variable
Reserve for unplanned
15 to 25 percent (overlapping with above)
How much does this cost
The cost is the time to plan honestly. A quarterly planning session of a day. Monthly reviews of an hour. Weekly check ins of fifteen minutes. The total is roughly a day per quarter of explicit planning time. The savings is the slippage that does not happen.
Features the planning practice must have
- A reference set of past work for effort estimation.
- An explicit reserve for unplanned work.
- Honest accounting of overhead time.
- A quarterly planning session.
- Monthly progress reviews.
- A way to surface blockers early.
- A retrospective on the plan at quarter end.
Expert opinion
The small teams that ship what they promised plan honestly. They acknowledge the overhead. They build in the reserve. They reference past work for estimates. The teams that miss this commit to fiction and watch the plan fail. The discipline is small. The cost of skipping is the credibility of every future commitment.
Yashveer Singh, founder of Yashveer Labs
How this played out on a real project
A client SaaS engineering team of seven was missing every quarterly commitment. The founder was frustrated. The team was burned out. The pattern had been going for three quarters.
We rebuilt the planning. Honest capacity per engineer of 60 percent for shipping. Reserve of 20 percent for unplanned work. Effort estimates referenced against the last six months of shipped features. Quarterly commitment was set at 70 percent of the new honest capacity to leave room.
The first quarter under the new plan shipped on schedule. The team had room for the unplanned work that arrived. Morale improved because the team stopped feeling behind. The founder's trust in the engineering commitments came back over the next two quarters.
The honest plan would have committed to less in headline scope than the previous quarters had. The honest plan shipped more in real value because it did not blow up.
For more on the related work, see the engineering velocity question how fast should you be shipping and engineering roadmaps that survive reality.
Common mistakes teams make
- Planning at 100 percent capacity.
- No reserve for unplanned work.
- No reference for effort estimation.
- Quarterly plan that does not survive month one.
- New hires planned at full capacity from day one.
- No retrospective on the plan at quarter end.
- Treating planning as bureaucracy rather than as honesty.
- No surface for blockers to be raised early.
A quarterly planning session structure
- Hour one. Review last quarter. What shipped. What slipped. Why.
- Hour two. Calculate honest capacity for the new quarter.
- Hour three. Identify the candidate work. Estimate against references.
- Hour four. Build the commitment. Leave reserve.
- Hour five and six. Cross functional review. Adjust.
- Hour seven. Communicate. Set up the monthly review cadence.
For more on the related work, read engineering roadmaps that survive reality and the roadmap vs reality gap a founder discussion. On the broader strategy side, the engineering velocity question how fast should you be shipping is the natural next read.
FAQ
Frequently asked
- What is the realistic shipping capacity of an engineer?
- How do I estimate effort?
- What is the right planning horizon?
- What about emergencies?
- How do I plan around hiring?
- What is the worst capacity planning mistake?
- How does AI assisted coding affect capacity?
Author
Why this is the work I do
The work in this article is not theoretical for me. It is what I shipped last quarter, last month, and this week. Yashveer Singh, founder of Yashveer Labs. I do not write about things I have not done. I do not pretend to expertise I do not have. If the topic here is the topic you are dealing with, I am the person who has dealt with it. Multiple times. Recently.