How every discussion about 'developer productivity' ends in hell.
What's being asked, what's actually asked, and what's being answered are completely different things.
While building Godfrey, I had the privilege of interviewing 100+ leaders during the big tech layoffs in 2023 and 2024. “Developer productivity” came up repeatedly.
It’s a polarizing topic that inspires fierce debate. Can we measure it at all? If so, should we? If we should, what exactly do we track?
You’ll find hot takes all over the internet. But one thing is consistent: these conversations about “developer productivity” are going very, very badly.
It’s not for lack of trying. Most of the CTOs I’ve talked to have gone above and beyond to answer the question. They show charts on deployment velocity. They show dashboard after dashboard on latency, utilization, and performance to make cases for refactors. They show charts on feature delivery, time to first code review, and, my personal favorite, developer satisfaction surveys.
But they’ve made one big mistake. They’re answering the wrong question. When their stakeholders ask them about “developer productivity,” they’re really asking this:
“What the hell is engineering doing all day, and am I getting my money’s worth?”
The hard truth is that by the time ANY team’s productivity is in question, very bad things have already happened. People don’t know what’s happening. They suspect the team is too bloated, idle, or not working on the right things.
In other words, they’re asking engineers to explain themselves and justify their own existence. But tech leaders have largely remained blind to this. Instead, they’re answering a different question altogether.
“How can we improve our development productivity?”
This disconnect - what’s being asked, what’s actually being asked, and what’s being answered - has turned the discourse around engineering productivity into a dumpster fire.
How this plays out
Imagine you’re the CEO. Maybe a rogue consultant has whispered in your ear about how your velocity could be faster, or maybe you saw a competitor slash half their engineering team and live to tell the tale. Regardless, you’re now fundamentally questioning the integrity, speed, and execution of your engineering team.
You can’t ask outright - it would be unnecessarily aggressive, especially if your team turns out to be doing a great job. Instead, you request a meeting “to better understand and troubleshoot our engineering processes and productivity.”
You go into this expecting to be able to extrapolate a straightforward answer to what feels like a straightforward question. After all, you do this all the time for sales, marketing, etc. when you suspect an intervention might be needed.
Instead, the engineering team presents confusing dashboard after confusing dashboard. They share the results of an internal survey…on how everyone has been feeling lately (they don’t like the current architecture; so could we please prioritize this refactor that we really, really want to do?). They reinforce the importance of reducing the number of meetings to "maintain flow state.”
They cap it all off by asking for more budget to retain high performers and hire more talent.
This confirms your worst fears: your team is spoiled, navel-gazing, and certainly not working on the stuff important to the business. Even though you’re not technical, it’s now your responsibility to step in and “turn things around.”
You begin micromanaging the engineering org, even though you know you’re out of your depth. You start taking “hard lines” to whip these engineers - who have clearly been coddled - into shape. Engineering, in response, becomes hostile and creates more confusing artifacts “proving” their productivity. Money, time, and resourcing are wasted on new dashboards, consultants, and rolling out new methodologies - even though no one is clear on what exactly it is they’re “fixing.”
This is how so many conversations around developer productivity go so south, so fast. The business asks a veiled question, the engineering org answers the literal question, and the disconnect creates a devastating tailspin.
Avoiding the tailspin
It’s not surprising that so many engineering leaders misread the room so badly. For a very long time, engineers were a scarce resource and the goal was to hoard them wherever possible. It was a strategic advantage for Google to keep 60,000 engineers on its payroll, and your success as a leader was defined by attracting and retaining talent.
Today, it’s about streamlining. Bloated engineering budgets are dying. After decades of talent deficits, tech workers are struggling to find new jobs.
It’s important to keep this shift in perspective. This isn’t the decline of the Roman empire, so much as a return to normalcy. After all, Google had carving stations in its cafeteria, complete with a resident salt bae - a man whose sole job was salting the meat at said carving station. Deflating the bloat of talent locked in big tech can improve productivity by removing drag and releasing talent to sectors where tech talent is most needed - like education, non-profits, and the arts.
The problem is that most organizations aren’t Google. They never had salt baes or bloated budgets; just excellent leaders doing their very best with lean teams. For those leaders, a botched conversation on “engineering productivity” can be disastrous - there’s no fat to cut and no time to waste.
This is why it’s so important for engineering leaders to seize the narrative and proactively help their non-technical counterparts to understand their stack and the nature of engineering work. Not as a feature factory but as a complex balance of managing maintenance, resourcing, and architecture.
Once this happens, the issue of “developer productivity” virtually disappears. You’ve answered the real question, and the proxy can be seen for what it is: the canary in the coal mine.
After all, the real reason developer productivity discussions always end in hell is simple: they begin there in the first place.
Godfrey helps you map resourcing, maintenance, and architecture so that anyone can understand what engineering is doing and why. It represents the real work of engineering in all its complex glory, helps you forecast, and keeps you out of hell.