Productive teams don't measure productivity.
It's become normal for engineering teams to get stuck in a vicious cycle of waste and bureaucracy. Here's how we got here, and how to break free.
Every year, we spend $200B+ trying to quantify and understand engineering productivity. Dev teams are literally drowning in dashboards, roadmaps, and project management software that make all sorts of promises - greater visibility, higher productivity, defect reduction, etc.
None of them work. Ironically, all the effort expended to try and quantify productivity is the very antithesis of productivity.
It’s understandable why we have all this stuff. Modern software engineering as an enterprise function is relatively infantile. In B-school, you’ll learn the basics of marketing, sales, and ops but nothing about managing engineering as an enterprise function. Leaders are on their own, trying to figure out what their (very expensive) engineering organizations are doing all day.
Thus begins a vicious cycle:
A business wants visibility into what engineering is doing
They pick up a commercial Agile framework and introduce sprints, estimates, and backlogs
It works for a bit, but eventually communicating in this way makes things more confusing - ex: how do you explain the effort of a new integration in story points or T-shirt sizes?
This fresh confusion drives the business to find more reporting and set up more infrastructure to ‘understand productivity’.
Once this cycle begins, it compounds. Engineering teams can’t start any work—no matter how trivial/obvious—without making a fully scoped ticket. Hours are spent per week just to estimate, negotiate, and sequence priorities before work can be done, often across multiple teams with competing to-do lists. Teams then spend more time and resources on tooling - surveys, dashboards, a new framework - to try and understand why they feel so unproductive.
This has slowly and insidiously become the norm in enterprise software engineering. It’s a special kind of madness that we would never tolerate for any other function.
How we boiled the frog: a timeline
When we first started building enterprise software, it was a lot like physical manufacturing. In 1985, when Microsoft released the first version of Windows, you mailed a check to a PO box and someone physically shipped you a CD. There was little infrastructure for software - you had to build everything from scratch on your own island. It was also important to get it right the first time; once your software (literally) shipped, you had no way to correct errors or adjust.
Over time, this would change dramatically. Engineering became increasingly interdependent - you were no longer building from scratch, but building a system out of other systems. Open source and software services became the norm, which made software easier and faster to build.
The way we shipped software also changed. You no longer needed to make sure things were perfect on the first release - you could update software continuously and regularly. “Shipping” was now virtual, continuous, and instantaneous.
This shift turned maintenance into a critical activity. The services and systems you built on top could also now make changes continuously and instantaneously - in any direction and without warning. When these changes happen, you need to maintain your system by making the appropriate updates to make sure things don’t break. Survival was no longer a default; there was now a carrying cost for your software to simply exist.
Because of this, the way we managed software engineering needed to change. Through the 90s, software engineering was managed like traditional engineering in sequential “waterfall” stages with clear handoffs between each stage. But needing to maintain and adapt as other systems change threw a wrench in this - it was no longer possible to write all your requirements up front because those requirements could fall out of date at any time. By the late 90s, requirements were falling out of date almost as soon as they were written.
The Agile Manifesto was an elegant rebuttal to this. In 2001, 17 practitioners got together and wrote a simple, succinct call for more collaboration and adaptability in software engineering:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
This was a much-needed shift in the way we thought about managing software engineering. It pushed the industry to acknowledge the new normal of a constantly shifting ecosystem and that “shipping” no longer meant sending a physical box over the post. Over the next couple of decades, most orgs would undergo an ‘Agile transformation’.
As more companies adopted Agile, an entire industry developed in its wake. Consultants developed and sold different flavors (XP, Scrum, Agile, SAFe, etc.) Software companies sold products to manage the nuances between the flavors. Issue ticketing systems were re-branded as “Agile project management” dashboards.
This commercialization of Agile made engineering even more complicated. You now needed to speak the language of ‘sprints’, ‘retros’, and ‘scrum masters’ to engage with engineering at all. Complex technical concepts were boiled down to ‘story points’ and ‘t-shirt sizes’ - turning the diverse work of engineering into interchangeable generic currency. Whether you’re doing cross-platform refactoring, front-end work, or DevOps - 5 story points is 5 story points.
Case in point: Imagine explaining ‘story points’ and ‘T-shirt sizes’ to someone who hasn’t worked directly with engineering teams. ‘Story points’ = the number of ‘points’ required to complete a ‘user story’. A ‘user story’ is a unit of engineering work, articulated in terms of how a feature will benefit a user. T-shirt sizes are an alternative to story points - instead of giving a numerical point value, you give a T-shirt size to the effort - is it small, medium, large, or XL?
There is no way to explain the how and why of all of this succinctly. But you can’t engage with engineering without this knowledge - even though it doesn’t actually connect with the way engineering works.
As the Agile industry boomed, the practice of software engineering evolved separately. Software engineers became more specialized, focusing on specific technologies, competencies, industries, and skillsets. The work of engineering became exponentially more interconnected. It’s now virtually impossible to truly track dependencies—you might be able to map yours, but can you map the dependencies of your dependencies?
Big Agile didn’t reflect any of this new complexity, but rather reinforced its own bureaucracy. Maintenance (the act of staying alive), specialized skills (resources that drive output), and architecture (scalability and efficacy) were all rendered invisible. Engineers are now beholden to a system that doesn’t reflect their work at all.
No other function is managed this way. Imagine if a marketing team needed to make a ‘ticket’, size it with the entire team, and rank order it relative to everything else in their queue before doing every single piece of work. Imagine if other departments were empowered to pepper the marketing team with new requests/questions so that their backlog of priorities was in flux every single ‘sprint’ - ex: why can’t we just swap out this 3-point story for this other one? What’s the ROI of this rebrand anyway?
This dystopia is the accepted reality for most engineering orgs. Thanks to Big Agile, we’ve lost the plot so badly that we can’t even see the problem anymore.
Breaking out of the cycle
The only way out of the cycle is to go back to the very beginning and answer the root cause question. What does engineering do all day?
Despite how reliant most businesses are on their engineering teams, most leaders still can’t describe what their engineers actually do all day in concrete terms.
Let it sink in how weird this is. Any C-suite exec would be able to describe how a typical support/sales/finance team member spends their day. They might not know what they’re working on specifically, but they have a mental model of what their job is like. They can picture the shape of their work in real, concrete terms.
This mental model gives them empathy and helps them inherently understand their productivity and daily challenges. They don’t need a dashboard to ask the right questions and intuitively grasp how well their teams are doing.
Contrast that with engineering. Most people know that engineers code, but they don’t actually know what coding is like. They can’t picture doing it themselves and can’t describe the work in concrete terms.
This missing mental model is the root cause of the vicious cycle of self-reinforcing bureaucracy that follows. In fact, the only orgs that don’t fall into this trap are orgs where. the entire executive team has high technical fluency.
This doesn’t mean that your entire C-suite needs to know how to code; technical fluency ≠ engineering expertise. In the same way, you don’t need to be an economist to manage your personal finances; you don’t need to be a card-carrying developer to provide engineering leadership. You just need a mental model of how your platform works and what your team is doing to support it.
It is the same fluency that all leaders build for all other functions. Engineering just needs to stop being the exception.
Once you have this mental model, you can see the wasteful bureaucracy of Big Agile for what it is - a misguided attempt to understand.
From there, everything gets simpler. You’re not treating ‘developer productivity’ as a separate category. It’s just…productivity. You’ll have an intuitive and confident sense of what drives it - clear goals, empowered team members, and minimal distractions.
This is what commercial Agile has robbed us of - our own intuition and common sense. When you’re on a productive team, you feel it. Everyone is seen and supported. Everyone is efficient and effective. They know what they’re doing, and they know that what they’re doing matters.
If you’ve ever worked on or managed a team like this, you probably didn’t even think about how you were measuring and tracking productivity.
You were too busy being productive.
Godfrey helps you build a mental map of your engineering org by mapping maintenance, resourcing, and architecture in a way that anyone can understand. It builds empathetic, intuitive understandings of productivity so you stop wasting time trying to measure it and more time being it.
A huge thank you to Denis Čahuk for inspiring this article and reading drafts. And a special thank you to Alexis for giving it the non-technical once-over it needed by bringing the most insightful questions.