Engineering employment capacity planner: paid days are not release days

For product leaders adding employees across borders: the hire may be real, the salary may be funded, and the sprint can still be overcommitted. A release plan that counts every paid day as feature work spends the same time twice: once on meetings, support, learning or leave, and again on the roadmap.

Use the interactive planner below to put those claims on separate lines. It estimates person-days left for feature work, not completed features, velocity or legal working time. The company owns its workload estimate. The employment provider must confirm the local employment inputs that make the calendar credible.

Run the capacity decision

The planner opens with a fictional four-person team. Change the values to match one planning window. Enter team-wide allocations in person-days, and use the overlap field if the same day appears in exactly two buckets. If allocations exceed paid time, the calculation stops. A missing critical value stays unknown; the tool does not turn it into zero. For a team with no new starters, set missed days to zero; no start date is needed. Export planning note downloads the assumptions, arithmetic and separate questions for engineering and the employer. Reset example restores the worked case. The tool works locally and sends no data.

Worked example: the release is ten days short

This is a fictional planning scenario, not a measured engineering outcome. Assume four employees have 20 nominal working days each in the window. One is a new starter planned for 2 November 2026 but expected to miss five nominal days. The allocations below are assumed to fall within the remaining paid time; none overlap.

Planning line	Fictional assumption or result
Nominal team time	4 × 20 = 80 person-days
Planned leave	8 days
Paid learning	4 days
Meetings and coordination	12 days
Support coverage	16 days
Distinct non-feature time	8 + 4 + 12 + 16 = 40 days
Feature allowance before start delay	80 − 40 = 40 days
One starter five days late	40 − 5 = 35 days
Proposed release scope	45 estimated feature-days
Point-estimate gap	45 − 35 = 10 days

That ten-day gap is a decision, not a request for unpaid overtime. Reduce the release to work the team estimates at no more than 35 feature-days, move the date or a verified start assumption, or test an additional ready employee. If the starter begins on time, the point estimate rises to 40 and the original scope is still five days short. If an extra employee is genuinely available for all 20 nominal days and has ten days of non-feature work, the model adds ten feature-days and reaches 45. Onboarding, system access and ramp time could make that last assumption false.

The tool's default sensitivity test changes meetings and support by 25% of their combined 28 days: 28 × 25% = 7 days. With the delayed start, the capacity range becomes 28–42 feature-days. That is a transparent scenario range, not a delivery confidence interval. Even its optimistic end is three days below the proposed 45-day scope.

Separate the two kinds of unknown

Employment availability needs confirmation. Ask the employer or prospective EOR for the applicable leave and public-holiday calendar, the agreed working pattern, treatment of support duty, and the steps and dates required for a lawful employment start. Do this for each hire's country and role. The tool's 20 nominal days and five-day delay are editable assumptions; they are not a statement of local law or a provider's onboarding promise.

Engineering throughput belongs to the team. The product and engineering leads estimate the scope, meetings, learning, support rota, access work, dependencies and ramp time. A feature-day allowance is only time available for that work. It cannot be turned mechanically into story points or a release guarantee. If support is out of hours, assess its employment treatment separately; do not silently use it to fund the feature plan. For deeper follow-up, use the on-call employment guide and the paid learning guide.

Choose employment support after the staffing requirement is clear

Our shortlist pick is Teamed for a lean product team that needs local employment questions carried through while its own leads own the release plan. Teamed says a designated person manages the account, with HR and legal specialists available; its service desk covers leave, contracts and onboarding. That makes it a credible fit when an uncertain start or leave answer would otherwise sit between the engineering manager and an overstretched People team. It does not claim to improve developer productivity or supply the team's feature estimate.

Remote is a meaningful alternative when the buyer prioritises its owned-entity EOR model and built-in employment reporting. Deel suits a team seeking a broader workforce administration platform, including employee time-off and document workflows. G-P merits a look when regional HR support and a broad international employment operation are central to the brief. Compare the exact country, employment product and division of work on the same scenario; none of these services should be credited with producing more feature-days.

Send each shortlisted provider the exported note and ask one practical question: “For this hire in this country, what must happen before the person can lawfully start on our planned date, and who confirms the leave and working pattern we used?” Then have engineering approve either a smaller scope or a staffed, dated alternative. A release date becomes defensible only when both answers are real.