Last updated: September 30, 2026
By Jennifer Burdick, Recruiting Manager, KORE1
Engineering capacity planning means multiplying engineers by working days, subtracting holidays, PTO, meetings, on-call, and maintenance, and comparing what remains against roadmap estimates padded by your team’s own track record. Whatever is left over is the gap. Every way of closing it arrives on a different calendar, and a permanent hire approved on the first day of a quarter usually shows up after that quarter has ended.
October is when these calls reach my desk. An engineering manager has just done the arithmetic for the first time, usually in a spreadsheet, usually the night before a roadmap review, and the number at the bottom is smaller than the one they promised in August.
Last November it was an engineering director at a logistics software company in Overland Park, Kansas. She needed two contract backend engineers by the following Monday. Her fourth-quarter plan had committed to a carrier-integration release on December 15, and the plan had been sized as ten engineers times thirteen weeks, which is 650 engineer-days. When we went through the spreadsheet together, the number she could actually spend on the roadmap was closer to 330. Thanksgiving week had been counted as working time. So had 41 days of December PTO her team had already booked. One engineer a week was on the PagerDuty rotation and got almost nothing else done, and the support queue from the carrier portal ate about a fifth of every sprint. Nobody on her team was surprised by any of it. It was just never in the plan.
We placed both engineers. They started on November 17. The release shipped January 12, and it would have shipped then with or without them, because by mid-November there were not enough weeks left in the year for a new person to matter much. Finding the gap in week one instead of week seven would have changed the answer.
That is the whole argument of this piece, and it is not the one most capacity planning guides make. The published guides are mostly written by companies that sell planning software, and they are good on the formula. Few of them put a date on the fixes. “Hire more engineers” appears as an option on nearly every list, as if a req approved in October produced output in October.
Know who is doing the arithmetic, too. I run contract searches on our contract staffing desk, and one of the six fixes below is a contract engineer. Four of the other five cost no money at all, and I would put them ahead of mine.
A Quarter Has Fewer Engineer-Days Than the Plan Says
Engineering capacity is the number of engineer-days a team can put toward planned roadmap work in a given period, after holidays, time off, meetings, on-call duty, and ongoing maintenance are taken out. It is measured per quarter because that is how roadmaps get committed and how budgets get approved, and because a month is too short to average out vacations.
Take a team of eight engineers and the fourth quarter of 2026. October 1 is a Thursday. Between then and December 31 there are 66 weekdays. Most private companies close for Thanksgiving, the Friday after it, Christmas Eve, Christmas Day, and New Year’s Eve, which on this year’s calendar are five weekdays. The federal list is longer, since the Office of Personnel Management’s 2026 schedule also includes Columbus Day and Veterans Day, but few software companies close for either.
| Line | How it is figured | Engineer-days |
|---|---|---|
| Raw calendar | 8 engineers x 66 weekdays | 528 |
| Company holidays | 5 days x 8 engineers | minus 40 |
| Paid time off | 5 days per engineer, the fourth-quarter share of a 15-day year | minus 40 |
| Available | What is left before any work is assigned | 448 |
| Meetings and ceremonies | 15% of available | minus 67 |
| On-call | One engineer per week loses half the week, 13 weeks | minus 33 |
| Maintenance and support | 20% of available, taken from the team’s last two quarters | minus 90 |
| Roadmap capacity | What the quarter can actually be promised against | 258 |
Eight engineers. One quarter. 258 days of roadmap. Not 528.
Every line in that table is an input you should replace with your own. The PTO line is the one people argue with. So, the source. In the Bureau of Labor Statistics benefits survey, about a third of private-sector workers, 32 percent, get 10 to 14 vacation days once they have a year in. After ten years, 30 percent get 15 to 19. Software engineers tend to sit at the upper end of those bands, and a lot of companies now run unlimited policies that land in roughly the same place in practice. Fifteen days a year is a fair middle. A third of it in the fourth quarter is, if anything, light. December is when unused days get used.
On-call is the line most plans skip entirely. Google’s site reliability engineering book, in its chapter on eliminating toil, sets a goal that at least 50 percent of each SRE’s time goes to engineering project work, and reports that the average time its SREs spent on toil was about 33 percent. It also notes that in an eight-person rotation, at least a quarter of each person’s time goes to on-call and interrupts. Those are dedicated reliability engineers, not a product team. The shape still carries over. Whoever holds the pager this week is not building your feature, whatever the sprint board says.
The maintenance line should come from your own history. Pull the last two quarters of tickets out of Jira or Linear, tag what was bug fixes, dependency upgrades, customer escalations, and small requests from sales, and divide by the total. Twenty percent is common on the teams we staff. Thirty is not rare on a product with a lot of enterprise customers. Under ten usually means somebody is not tagging tickets.
Most planning guides fold all of this into a single “focus factor” and suggest something between 0.6 and 0.7. On the table above, 258 of 448 available days is 0.58, and 258 of the raw 528 is 0.49. The difference matters. A 0.65 focus factor applied to the raw calendar, which is how it usually gets applied, would promise 343 days of roadmap from this team. That is 85 engineer-days nobody has, about one and a half engineers who exist only in the spreadsheet.
The Estimates Are the Other Half of the Equation
Capacity is only the supply side. Demand is the sum of the estimates for everything on the roadmap, and estimates have a well-documented lean.
In 1994, Roger Buehler, Dale Griffin, and Michael Ross asked honors psychology students at the University of Waterloo when they expected to finish their theses. The average prediction was 33.9 days. The average actual was 55.5. When asked for a worst-case estimate, the students said 48.6 days, which was still short of what really happened. The paper ran in the Journal of Personality and Social Psychology, and psychologists still reach for it whenever somebody says “planning fallacy.” Undergraduates, not engineers. I have yet to meet an engineering team that beat them by much.
Do not multiply your roadmap by 1.64 because a 1994 psychology study says so, though. Use your own ratio. Take the last three quarters, add up what the team estimated for the work it finished, add up what that work actually took, and divide. If your tracking cannot produce that number, 1.3 is a reasonable floor until it can, and the fact that you cannot produce it is worth fixing before next quarter’s plan.
Back to the team of eight. Say the roadmap items for the fourth quarter add up to 240 engineer-days as estimated, and the team’s three-quarter ratio of actual to estimated effort is 1.3. Demand is 312. Capacity is 258.
The gap is 54 engineer-days. On this team, a little more than a fifth of the roadmap.
That is a manageable gap, which is exactly why teams tend to leave it alone. It feels like something a strong sprint or two can absorb. It rarely is. A 54-day gap discovered on October 1 has six fixes available. The same gap discovered on November 16 has about two.
Six Ways to Close the Gap, and When Each One Lands
Each fix below is priced in the engineer-days it returns inside the same quarter, starting from a decision made on October 1. The contract and permanent rows use our own ramp planning figures rather than a published study. A new contractor delivers about a quarter of a normal week in the first two weeks, half in weeks three and four, and three quarters through week eight. A permanent hire ramps more slowly, because the job is broader and the first month is full of things that have nothing to do with the roadmap.
| Fix | Lead time | Engineer-days back in Q4 | What it costs |
|---|---|---|---|
| Cut or defer roadmap scope | One conversation | Whatever is cut | A stakeholder who hears no |
| Trim meetings from 15% to 10% | About a week | About 22 | Someone canceling recurring invites |
| Defer non-urgent maintenance, 20% to 15% | Immediate | About 22 | Debt that comes back in Q1 with interest |
| Borrow an engineer from another team | One to two weeks | 20 to 35 | The other team’s quarter |
| One contract engineer | About 17 days to start | About 26 after review time | Roughly $45,000 at a $120 bill rate |
| One permanent hire | Five to eight weeks to start | Zero to five | Salary, benefits, and a search fee |
Read the first three rows before the last three. Scope, meetings, and maintenance together can close this particular gap without anyone new walking in the door, and they are the only fixes that work at full strength on day one.
Scope, Meetings, and Maintenance
Scope is the honest fix and the least popular one. A 54-day gap is roughly one medium roadmap item, and moving it to the first quarter of 2027 on October 1 is a planning decision. Moving it on December 10 is a missed commitment.
Meetings are harder to cut than they look. Everyone agrees there are too many, and nobody’s own meeting is the problem. Five points of a 15 percent meeting load is a standup that runs 25 minutes instead of 15, one recurring sync that could be a written update, and a sprint review that invites twelve people when four would do. That is about 22 engineer-days on this team. Real days. Free ones.
Maintenance is the dangerous one. Pushing dependency upgrades and small bug fixes out a quarter does return engineer-days, and for one quarter it is often the right call. The work does not vanish, though. It waits. Do it two quarters running, and the first quarter of next year starts with 30 percent maintenance instead of 20, which is a smaller team wearing the same badges. The other way out is to staff the line itself, with contract engineers on the maintenance queue so the roadmap keeps its people.
Borrowing Versus Contracting
Borrowing an engineer from another team is fast, and inside the company it is zero-sum. It only works when the other team genuinely has slack, which is rarer than a reorg slide suggests. The borrowed engineer also needs ramp time on an unfamiliar codebase. Less than an outsider needs. Not none, though.
A contract engineer is where a decision made on October 1 still pays off inside the same quarter. KORE1’s average time to hire on IT searches runs 17 days, which puts a contractor approved on the first of the month in the seat on Monday, October 19. With our ramp figures and a couple of days off around Christmas, that contractor delivers about 30 engineer-days of roadmap work by December 31. Your own engineers spend some of their week reviewing that person’s code and answering questions, which I worked through hour by hour in the piece on absorbing contractors in waves, and on this team that costs about four engineer-days across the quarter. Call it 26 net. Two contractors close the 54-day gap to within a couple of days.
They are not cheap. Nobody pretends otherwise. At a $120 bill rate, a common figure for a mid-to-senior backend contractor in our 2026 tech contractor rate data, one contractor over those 47 billable days costs about $45,000. Two is about $90,000. Whether that is worth it depends entirely on what the fourth-quarter commitment is worth. For a release a sales team has already sold, it usually is. For an internal refactor with a soft date? No. Cut scope instead.
Timing decides this row more than price does. The same contractor approved on November 1 starts the Monday before Thanksgiving and returns something like six net engineer-days before the year ends. Approved in December, close to nothing. That was Overland Park. Two good engineers, six weeks too late.
The Permanent Req Opened on October 1
A permanent hire is the right answer to a lot of capacity problems. It is almost never the answer to this quarter’s.
Our time-to-fill data for software engineers puts a search at 6 to 11 weeks on a company’s own and 3 to 6 weeks through a specialized agency, and that clock stops at the accepted offer, not the first day. Add two weeks of notice, and the Thanksgiving week that tends to swallow a start date, and a req opened on October 1 produces a new engineer somewhere between mid-November and the second week of December. A permanent engineer’s first month is benefits enrollment, laptops, architecture walkthroughs, and three different people explaining how deploys work. By our ramp figures, a permanent hire starting November 30 delivers under five roadmap days before the new year. Subtract the time a senior engineer spends onboarding them, and the fourth-quarter contribution rounds to zero. Sometimes below it.
A payments company in Charlotte, North Carolina, ran exactly that play last fall. The VP of engineering opened a senior backend req on October 1 to cover a gap on a December launch. The offer was accepted November 6. The engineer started December 1, after two weeks of notice at her old job and a Thanksgiving trip she had booked months earlier. She was excellent. Truly. She also spent most of December learning a Kotlin monolith, and the staff engineer who onboarded her lost the better part of two weeks doing it. The launch slipped to February. The hire was still the right decision, for the first half of 2027. It just had nothing to do with December.
One Gap Is a Scope Problem. Three in a Row Is a Headcount Problem.
One quarter will not tell you which fix you need. Four will.
A gap that shows up once, around a launch or a migration with a date on it, is a scope or contract problem. Close it with the first three rows of the table, and add contract capacity if what remains is still too large and the date is real. When the migration ends, the contractors leave, and the team is the right size again.
A gap that shows up every quarter is different. If the same 50 or 60 engineer-days are missing in the second, third, and fourth quarters, you do not have a planning problem. You have a team that is one or two engineers short for the work the company keeps giving it. That calls for a permanent req, opened now, with contract capacity bridging the months until the new engineer is actually productive. Our direct hire staffing desk runs those searches, and I would rather tell a client that than sell them a third quarter of contractors for work that is clearly permanent.
The annual version of this decision, how much of an entire IT organization should sit on contract and how that share moves with budgets and freezes, is covered in Mike Carter’s framework for contractor headcount planning. What this article describes is the input to that plan. Four quarters of honest gap numbers are the best evidence a budget meeting ever gets. Most never see them.
Running the Numbers in One Afternoon
No software required. A spreadsheet works. So does the back of a sprint board.
- Count weekdays in the quarter and take out the days the company is actually closed, from this year’s calendar and not last year’s.
- PTO next. Ask the team what is already booked, then add a fair share of what is not, because December fills up late.
- Your meeting load is sitting in everyone’s calendar. Pull a normal two-week sprint and add it up.
- On-call gets a real number. Who holds the pager, how many weeks, and how much of those weeks survives.
- Two quarters of tickets, tagged, give you the maintenance percentage. Guessing gives you 10 percent, which is wrong.
- Multiply roadmap estimates by your own actual-to-estimate ratio, or by 1.3 if you have never measured it.
- Then subtract. If the gap is positive, go back to the fix table and read it top to bottom, noting the lead time on each row before picking one.
When you run it matters as much as how. Late September, ideally. Not mid-October. A gap found on September 20 has every fix available. A gap found on October 20 has lost most of the contract row and all of the permanent one.
When the Spreadsheet Meets the Roadmap Review
How much of an engineer’s week is really available for roadmap work?
Somewhere around half to 60 percent of the calendar, on most product teams we staff, once meetings, on-call, maintenance, and time off come out.
Teams with heavy customer escalations run lower. A new team on a greenfield product with no production traffic yet can run much higher, and should enjoy it while it lasts.
Story points or engineer-days for the math?
Engineer-days, because the fixes for a gap are priced in people and calendar time, and points do not convert cleanly into either.
Keep points for sprint planning if the team likes them. For the quarterly number, convert with the team’s own historical points-per-engineer-day, and expect the conversion to wobble. That wobble is why the actual-to-estimate ratio matters more than the unit.
Do contractors already on the team count as capacity?
Yes, at full capacity once they are past their first two months, and at a ramp fraction before that.
Check their end dates against the quarter, though. A contractor whose assignment ends November 15 is half an engineer in the fourth-quarter math, not a whole one, and the plan should say who picks up their work after that date. Most plans I review count the contractor for all thirteen weeks and the extension as a formality. Sometimes it is. Sometimes procurement has other ideas. Ask.
Is a gap of ten or fifteen engineer-days worth acting on?
Usually not with people. Scope first.
That size of gap belongs to meetings and the roadmap. Nobody new will be productive enough inside the quarter to close it, and the onboarding cost can exceed what they return. Trim one roadmap item or one recurring meeting and move on.
What if leadership will not accept the smaller number?
Show them the table line by line, because the argument is almost never about the total and almost always about one input.
If they think 20 percent maintenance is too high, show them the tagged tickets. If they think five days of PTO is too many, show them the booked calendar. A number built from inputs everyone can see tends to survive a roadmap review. A focus factor somebody picked from a blog post does not. Mine included.
Should the estimate buffer go on each item or on the quarter as a whole?
On the quarter, as a single multiplier drawn from the team’s own history.
Padding each item invites everyone to pad their own twice, and a quarterly multiplier keeps the adjustment visible in one place where people can argue with it.
The Gap Has a Deadline Before the Roadmap Does
Work out the number before the quarter starts. Take the raw calendar down to roadmap capacity, put your own history on the estimates, and subtract. Then read the fixes in order of lead time, not in order of how comfortable they feel. Scope and meetings work on any day of the quarter. Contract capacity works if it is approved in the first two weeks. Permanent hiring works for next quarter, and it should be started now if the same gap keeps coming back.
If the gap is real and the date is real, send us the spreadsheet. We will tell you whether contract engineers can still land inside the quarter or whether it is already too late for them to help, and when it is too late, we will say that too. For the engineering roles themselves, our software engineer staffing team has run those searches since 2005.
