Why salary divided by 2,080 is the wrong number
Every internal cost comparison eventually needs a price per engineering hour. The reflex is to divide salary by 2,080 — 52 weeks at 40 hours — and quote that. It is wrong twice over, and both errors point the same way, so they compound instead of cancelling.
The first error is the numerator. Salary is not what an employee costs. On top of base pay sit employer payroll taxes, health and insurance contributions, retirement matching, and the accrual for paid leave. Then sits overhead the individual never sees: laptops and tooling licences, office or remote-work allowance, recruiting cost amortised over expected tenure, and a share of management, finance and HR. Together these add a substantial multiplier to base pay; the exact figure is yours to measure, and the U.S. Bureau of Labor Statistics Employer Costs for Employee Compensation series is the standard reference for the benefits half of it.
The second error is the denominator. Nobody delivers 2,080 hours of project work. Vacation, public holidays and sick leave take out several weeks. Of the weeks that remain, a share disappears into standups, planning, reviews, one-to-ones and all-hands, and another share into production support, on-call and escalations. What is left is the capacity a project plan can actually consume.
This is the fully loaded labour rate method, and it is the same construction a professional services firm uses to set a billing rate, applied inwardly. The result is the number you should carry into every build-versus-buy comparison, every automation payback case, and every estimate that converts weeks of effort into money.
The two halves of the calculation
The numerator is a multiplier on salary. If benefits run at 28% and overhead at 25%, the load factor is 1.53, and a $160,000 salary becomes $244,800 of fully loaded annual cost. Keep the two percentages separate even though they are added, because they come from different owners: finance knows the benefits load, and only you know what your team's tooling, hardware and recruiting actually cost.
The denominator is built in two stages, and the order matters. First take weeks actually worked — 52 less leave — and multiply by contracted hours to get paid hours. Then remove the share of those paid hours that never reaches project work. Deducting leave as a percentage alongside meetings is a common mistake: leave removes whole weeks from the year, while meetings remove a slice of every remaining week, and folding them into one percentage makes the result sensitive to which convention you used.
One relationship is worth noticing because it makes the result easy to sanity-check. The cost of a full engineer-week of project work is loaded annual cost divided by weeks worked, and the hourly figures cancel out entirely. At $244,800 over 46 weeks that is $5,321.74 a week, regardless of how the meeting and interrupt percentages are split. If a vendor quotes you a fixed price, this is the figure to compare it against — not the hourly rate, because the hourly rate invites an argument about how many hours the work would have taken.
Raising either meeting or interrupt time raises the rate, because both shrink the denominator while the numerator stays fixed. That is not an accounting artefact: it is the honest statement that an organisation which consumes 40% of its paid hours on things other than the project has to charge the project more for each hour it does get.
Worked example: a $160,000 engineer at 46 working weeks
Take the defaults: $160,000 base salary, 28% benefits, 25% overhead, 46 weeks worked, 40 contracted hours, 20% of hours in meetings and 15% on interrupts and support.
- Form the load factor. 1 + 0.28 + 0.25 = 1.53.
- Load the salary. $160,000 × 1.53 = $244,800 fully loaded annual cost. Of that, $44,800 is benefits and $40,000 is overhead.
- Count paid hours. 46 weeks × 40 hours = 1,840 hours.
- Remove non-project time. 1 − 0.20 − 0.15 = 0.65, so 1,840 × 0.65 = 1,196 project hours.
- Divide. $244,800 ÷ 1,196 = $204.68 per project hour.
- Cross-check the week. A project week is 40 × 0.65 = 26 project hours, so 26 × $204.68 = $5,321.74 — the same as $244,800 ÷ 46, as the formula says it must be.
Compare that with the naive figures. Salary ÷ 2,080 gives $76.92. Loaded cost ÷ 2,080 gives $117.69. The correct rate of $204.68 is 2.66 times the first and 1.74 times the second. A build estimated at 1,040 engineering hours prices out at 1,040 × $76.92 = $80,000 on the naive rate, and at 1,040 × $204.68 = $212,870 on the loaded one. It also takes 1,040 ÷ 26 = 40 working weeks to deliver, not six calendar months. That pair of corrections decides most build-versus-buy arguments on its own.
How to use the rate without misusing it
Use it for comparisons, not for chargeback. The rate is a decision tool: it tells you what an internal build costs so you can weigh it against a licence fee, a managed service or a contractor. It is not a price you should bill another internal team, because that turns an estimating device into a budgeting fight.
Feed it into the build versus buy calculator as the labour rate, and into the technical debt interest calculator as the loaded cost per engineer. The same number sets the engineering component of an outage in the incident response cost calculator, and the migration effort in the cloud migration payback calculator. Using one rate everywhere is what makes those cases comparable with each other.
Do not compare it directly to a contractor's day rate. A contractor rate already contains that firm's benefits, overhead, margin and non-billable time, but it also carries no notice period and no long-run knowledge retention. The like-for-like comparison is contractor cost against loaded internal cost for the same delivered work, including the internal time spent briefing and reviewing the contractor — which is project hours you have already counted as available.
Recalculate when the shape of the week changes. Adding an on-call rotation, a support tier or a new ceremony does not change anyone's salary, but it does change the denominator, and therefore every estimate that depends on it. A team that moves from 15% to 30% interrupt load sees its project hours fall from 1,196 to 920 and its rate rise from $204.68 to $266.09, without a single pay review.
Loaded hourly rate by salary and non-project share
| Base salary | 25% non-project | 35% non-project | 45% non-project |
|---|---|---|---|
| $100,000 | $110.87 | $127.93 | $151.19 |
| $130,000 | $144.13 | $166.30 | $196.54 |
| $160,000 | $177.39 | $204.68 | $241.90 |
| $190,000 | $210.65 | $243.06 | $287.25 |
| $220,000 | $243.91 | $281.44 | $332.61 |
Each cell is salary × 1.53 ÷ (1,840 × (1 − non-project share)). The $160,000 row at 35% is the worked example's $204.68.
Mistakes that make the rate wrong
- Deducting leave twice. If your benefits percentage already includes accrued paid leave as an employer cost, that is correct — but the weeks-worked figure must still exclude the leave itself, because those weeks produce no output. Counting leave once in the numerator and once in the denominator is right; counting it twice in the denominator is not.
- Using actual hours worked instead of contracted hours. Setting the week to 50 hours because the team works late prices unpaid overtime as free capacity and lowers the rate. Use the contracted week.
- Estimating meeting load from memory. Calendar exports give the real number and it is usually higher than anyone guesses. Export a representative month and measure it.
- Overhead built from a single line item. Laptops and licences are the visible part. Recruiting cost spread over average tenure, management time, finance, HR and facilities are the larger part, and leaving them out understates the load factor.
- Applying one rate to every level. A staff engineer and a graduate have different salaries and often very different interrupt loads. Run the calculator per level and use a headcount-weighted average when you need a single figure.
- Quoting the rate to the cent in a business case. The inputs are estimates to within a few percent. Round to the nearest $5 in prose and keep the precise figure only inside the arithmetic.
This rate is not a productivity measure
A high loaded rate is not evidence that anyone is working badly, and driving it down by cutting meetings to zero would not be an improvement. The rate simply reports how much of a paid year reaches project work at your current operating model. Use it to price decisions. If you want to change it, change the operating model — reduce interrupt load with better runbooks, or consolidate ceremonies — and then recalculate, rather than adjusting the percentage to a figure that looks better.
Where the loaded rate fits among other cost measures
Three related figures get confused with each other. Cost per employee is the fully loaded annual cost, useful for headcount budgeting. Cost per available hour is what this calculator produces, useful for project estimating. Cost per unit of output — per story point, per deployment, per ticket — is a productivity metric and depends on things no cost model can see. Only the middle one belongs in a build-versus-buy comparison.
For a total-cost view of a software decision rather than a labour view, the software TCO calculator covers licences, implementation and ongoing administration alongside the internal effort that this rate prices. If the question is whether a SaaS product is worth its seat count at all, the seat utilisation calculator answers a different and cheaper question first: whether you are paying for seats nobody opens.
Finally, remember what the rate measures. It is a cost of consumption, not a cost of hiring. Hiring another engineer adds a full loaded annual cost and adds project hours at whatever your current availability fraction is — it does not add 2,080 hours, and a plan that assumes it does will be short by roughly the same proportion this calculator has just corrected for.
Key terms
- Load factor
- The multiplier applied to base salary to reach fully loaded cost: 1 + benefits fraction + overhead fraction.
- Project hours
- Paid hours remaining after leave, meetings and interrupt work. The only hours a plan can actually consume.
- Fully loaded cost
- Total annual employer cost of an employee including salary, employer taxes, benefits and allocated organisational overhead.
- Engineer-week
- One person working for one week. Its project-work cost is loaded annual cost divided by weeks worked, independent of how the week splits between meetings and delivery.