The Number You’re Using Is Wrong
When a product manager asks how much a feature will cost, the answer that comes back is almost always derived from headcount and time. Take a developer’s annual salary, divide by working hours, multiply by estimated days. Clean, fast, wrong.
The error isn’t in the math. It’s in the inputs. Salary is one component of developer cost, and depending on how you account for everything else, it can represent less than half the true figure. Engineering leaders who build budgets and prioritization frameworks on salary-derived hourly rates are making every resource decision on a number that understates reality by a factor of two or more.
This isn’t a rounding error. It’s a structural misreading of where the money actually goes.
The Multiplier Stack Nobody Talks About
Start with total compensation. In major tech hubs, benefits, employer payroll taxes, and equity add 25 to 40 percent on top of base salary before you’ve accounted for anything else. A developer earning $180,000 in base salary costs something closer to $230,000 to $250,000 in direct employment expense. That’s well-understood, if frequently underweighted.
The next layer is overhead allocation. Office space, hardware, software licenses, IT support, HR, legal, and recruiting costs all exist because engineers exist. The recruiting cost alone is substantial: industry data consistently puts the cost of hiring a mid-level software engineer, including recruiter fees or internal recruiter time, sourcing, interview hours from existing staff, and onboarding, somewhere between $25,000 and $40,000 per hire. Spread over a two-year average tenure, that’s $12,000 to $20,000 per year before the person has written a line of production code.
Then there’s management overhead. A senior engineer doesn’t just produce output independently. They participate in planning meetings, code reviews, incident response, 1:1s, and the ambient coordination work that keeps teams aligned. Engineering managers typically spend significant fractions of their time on people work that doesn’t directly produce software. That time has a cost, and it’s correctly attributed to the developers being managed.
The Hours That Disappear
Here’s where the calculation becomes genuinely uncomfortable. A developer’s year contains roughly 2,000 working hours. That’s the denominator most people use. But the number of hours actually spent in focused, productive coding work is substantially smaller.
Research on knowledge worker productivity, including studies from the University of California Irvine on workplace interruptions, consistently finds that recovery from a single interruption takes more than 20 minutes. The cognitive cost of context-switching and notification-driven work compounds across a workday. In most engineering environments, between meetings, Slack, email, code review, incident response, and administrative tasks, a developer is doing deep focused work for perhaps three to five hours per day on a good day, less on a bad one.
Take a conservative estimate: 1,000 hours per year of genuinely productive development work, out of 2,000 nominal working hours. The denominator just doubled the effective hourly cost. A developer whose all-in annual cost is $280,000 isn’t costing you $140 per hour. The productive hours are costing you closer to $280 each.
This isn’t an argument for surveillance or productivity theater. It’s an argument for understanding what you’re actually paying for and designing systems accordingly.
What This Does to Project Economics
The practical implications are significant enough to change how you evaluate almost every engineering investment.
A feature estimated at two weeks of developer time is rarely two weeks of full-time focus. It’s two weeks of calendar time during which the developer is also handling other responsibilities, context-switching between projects, sitting in planning sessions, and dealing with infrastructure surprises. Studies of software project estimation consistently show that developers underestimate task duration, partly because estimates are made in idealized-focus-time units and executed in interrupted-calendar-time units.
This connects directly to the economics of technical debt and scope decisions. Projects that come in under budget often do so because scope was quietly compressed, not because delivery was efficient. When the true cost of a developer hour is $250 instead of $100, the calculus on cutting corners changes. Rework is extraordinarily expensive.
It also changes how to think about developer tooling investments. If a new tool saves a productive hour per developer per week, and you have 20 developers, and the real cost of a productive hour is $250, that’s $260,000 in annual value. Most tooling that delivers that return costs a small fraction of it. Companies that treat developer tooling as a cost center rather than a leverage point are making the same mistake as the ones using payroll-derived hourly rates: they’re working from a number that flatters the status quo.
Building Decisions on Honest Arithmetic
None of this is an argument that developers are too expensive or that engineering organizations are inefficient by nature. The point is precision. When you make prioritization decisions, build versus buy analyses, or staffing plans using an hourly rate that’s half the real figure, you systematically undervalue engineering time and make choices that would look different on accurate inputs.
The companies that get this right tend to do a few things consistently. They account for fully-loaded cost including overhead allocation when evaluating projects. They build prioritization frameworks that treat developer time as genuinely scarce and expensive, which pushes back against low-value work. They invest in reducing coordination overhead because they understand that reclaimed productive hours have a measurable dollar value. And they’re honest that the engineer who writes the least code is sometimes worth the most, because their value is in the productive hours they create for others.
The number on the payroll report is not the cost of building software. It’s the floor of that cost, and not a very useful floor at that. Engineering leaders who internalize the real figure tend to make better decisions about what to build, when to buy, and where to focus the attention of the people they’re responsible for. That’s the whole point of knowing the actual price of a thing.
