Why your productivity initiatives keep disappointing

Productivity efforts usually start in the right place. Build times, CI/CD, tooling — technical problems with technical solutions. These are real wins, and they matter.

But as the technical obstacles get knocked down, what’s left are the problems that aren’t purely technical: coordination overhead, unclear ownership, structural bottlenecks that require someone with organizational authority to fix. These problems are harder to measure, harder to solve, and politically complex. So teams drift toward interventions that are easier to accomplish and easier to claim credit for — even when those interventions are small compared to the systemic issues they’re avoiding.

That drift is where productivity initiatives start to disappoint.

DORA, part of Google Cloud, has spent a decade studying what actually predicts software team performance. Across years of research, certain factors consistently matter far more than what most productivity efforts focus on. Three stand out: generative organizational culture (which includes psychological safety), loosely coupled teams and architecture, and organizational stability.

Psychological safety means people can raise concerns without fear. When engineers can say “this process is costing us” or “this tool is broken” without worrying about retaliation (and with some confidence that the issue might be addressed), problems get surfaced and fixed. When they can’t, dysfunction compounds silently. Problems persist for months — maybe years — because there’s no safe, obvious way to escalate them. Individual engineers might assume an issue is their own fault, or a one-time thing, or not worth making a fuss about. Patterns only become visible when someone with enough credibility and safety takes the time to connect the dots. In organizations with lower psychological safety, they might never surface at all.

Loosely coupled architecture means teams can work independently without constant coordination. When every change requires sign-off from three other teams, when deploys are gated by manual approval chains, when the authorization system creates blocking dependencies — velocity dies.

This is partly a technical problem, but it’s also organizational. Architecture reflects org structure, and org structure is a leadership decision. Conway’s Law isn’t just an observation — it’s a design constraint. If your teams are tightly coupled and constantly waiting on each other, that’s not something engineers can fix on their own. It requires thinking about how teams are organized, what they own, and how work flows between them. It requires willingness to restructure ownership boundaries, to invest in APIs and contracts between teams, to accept that architectural decisions are organizational decisions in disguise.

Organizational stability means teams aren’t constantly being reorganized or having their priorities yanked around. This sounds obvious, but the data is striking: DORA’s 2024 report found that teams with unstable priorities experience 40% higher burnout risk and meaningful drops in productivity. “Move fast and constantly pivot” sounds agile and responsive. It actually negatively impacts performance. Teams need enough stability to finish what they start, to build expertise in their domain, to develop the working relationships that make collaboration efficient.

This doesn’t mean never reorg. Too much stability has its own costs: teams that become siloed, expertise that becomes isolated, organizational rigidity that makes necessary change harder. It’s not “don’t restructure,” but rather “are you restructuring for the right reasons, with the right care?” Organizations that reorg every eighteen months and shift priorities every quarter pay an enormous hidden tax. Every reorg resets team context. Every priority shift creates partially-completed work that may never ship. The churn is invisible on any single day but devastating in aggregate. But sometimes reorgs are necessary responses to market changes, not just leadership churn. The difference is whether you’re reorganizing because something actually changed, or because someone new showed up and wants to make their mark.

These three capabilities — psychological safety, organizational stability, loosely coupled architecture — aren’t engineering problems to solve with better tooling. They’re leadership responsibilities. And they explain why the hardest productivity problems are political. An engineer can’t give themselves psychological safety. A team can’t stop its own reorg. A squad can’t unilaterally decouple from another squad’s system. These require decisions from people with organizational authority — and often, those people don’t realize the decisions are theirs to make.

None of this fits neatly on a slide for your board. That’s part of the problem.

Understanding what predicts performance is one thing. Acting on it is another. Even the “safe” technical wins require organizational enablement or they’ll never get off the ground. A team that wants to improve build times still needs time allocated to do it. They need breathing room in the schedule. They might need budget for new tooling or infrastructure. They need permission to treat improvement work as real work, not something to squeeze in between “actual” tasks.

I’ve seen teams told to “focus on productivity” with no shared definition of what that means — just an abstract org-wide number that teams can’t really move. No clarity on what outcomes matter to the business. No budget. No margin. Just an expectation that they’ll somehow make it happen alongside their regular work. Left to their own devices, teams in this situation optimize for whatever’s measurable or visible — which probably isn’t what leadership actually wanted.

If you’re an IC, especially a senior one, your leverage is surfacing patterns, documenting costs, building alliances with people who can act. But that means actually doing it — not just complaining in Slack, not waiting for someone else to notice. If you see a problem and don’t document it, don’t escalate it, don’t build the case for fixing it, you’re contributing to the pattern.

If you’re a middle manager caught between leadership that creates drag and teams that experience it, your job is translating in both directions and fighting for what space you can. If you’re a senior IC or manager with some budget authority, ask for enablement explicitly: capacity, headcount, clarity on what success looks like, direction on what matters most. Don’t assume leadership knows what’s required — they often don’t. The gap between “we want better productivity” and “here’s what it would take” is frequently enormous.

If you are in senior leadership and your teams aren’t pursuing even routine productivity wins, ask yourself: have you actually enabled them? Have you given them slack? Budget? Training? Permission to spend time on this? Or did you just tell them to “improve productivity” and hope for the best? If enablement isn’t there, that’s the first thing to fix. If it is there and teams still aren’t delivering, that’s a different problem — one that might be about capability, culture, or teams creating their own dysfunction. But start with enablement.

Even when enablement is solid, something deeper often blocks real progress: leadership behaviors that actively hurt productivity, often invisibly to the leaders themselves.

A leader wanted a slide deck every week. The request seemed reasonable — just a way to stay aligned, to have visibility into the pulse of the company. The deck probably started easy: a few slides, an hour or two to assemble.

Then it grew. More stakeholders wanted input. The format needed to be consistent. Someone decided it should include metrics, so now someone had to gather those. Sometimes, someone else needed to make the charts. Reviews got added. Feedback cycles extended. Before long, producing the weekly deck consumed dozens of hours across the organization. Maybe more — nobody was tracking it.

The leader didn’t realize the impact they were having. That was never their intent. They just wanted visibility. But no one felt safe raising the concern. The people doing the work could see the cost, but psychological safety wasn’t high enough to surface it. So the drag continued, quarter after quarter, growing incrementally, invisible to the person who could stop it.

Leadership drag, invisible to leadership.

This pattern shows up constantly. Leaders create processes that feel necessary from their vantage point but consume enormous amounts of time downstream. Approval gates that add days to every decision. Status meetings that pull engineers out of flow. Documentation requirements that nobody reads. Each process has a justification — often a good one. Leaders are responsible for outcomes, and these processes feel like responsible risk management. The cumulative effect is death by a thousand cuts, but no single cut looks unreasonable.

The desire for control compounds the problem — and it’s an understandable desire. Leaders are accountable for results. They need to report to boards, explain to stakeholders, justify headcount. Visibility and oversight feel like responsible stewardship. But the mechanisms that create that feeling of control can actually hurt predictability. When leadership constantly shifts priorities, teams never finish anything. When leaders demand certainty, teams pad estimates and sandbagging becomes rational. When everything is urgent, nothing is.

When teams own outcomes rather than output, those outcomes improve — but only when the conditions are right. Teams need sufficient context to understand which outcomes matter and why. They need authority to make decisions that affect those outcomes. They need stable enough boundaries to actually influence results. Outcome ownership without these conditions can be worse than well-scoped output ownership: teams flail, make locally rational but globally destructive decisions, and bear accountability for things they can’t actually control.

When the conditions are right, outcome ownership means giving teams the problem to solve, not the solution to implement. It means allowing room for improvement work rather than running everyone at 100% utilization. It means tolerating some local inefficiency in pursuit of adaptability.

For leaders who built their careers on control, this feels like abdication. It’s not — but it’s also not as simple as just “empowering teams.” The hard work is creating the conditions where empowerment actually works.

What makes this particularly insidious: the leaders creating drag genuinely believe they’re helping. The weekly deck feels like alignment. The approval gates feel like risk management. The status meetings feel like staying connected. From the leader’s chair, each process serves a purpose. From the engineer’s chair, it’s all overhead. Neither perspective is wrong, exactly — but only one of them is paying the productivity tax.

I’ve created this kind of drag myself. I’ve accepted someone’s heroism to solve an urgent problem — it worked, but the solution lived in one person’s head for months afterward. I didn’t intend to create a knowledge silo. I just needed the problem fixed. Tradeoffs. Even well-intentioned decisions can create hidden costs, and the people making them often can’t see the downstream effects.

Why do leaders create this drag? Often it traces back to mental models about how work should work that simply don’t apply to software.

The manufacturing mental model is deeply ingrained. Optimize the line. Measure throughput. Command-and-control. Leaders who came up in that paradigm — or whose partners in other functions expect it — naturally apply it to software. Track output. Maximize utilization. Standardize process.

Not all manufacturing thinking is wrong. The Toyota Production System — flow, waste reduction, continuous improvement — heavily influenced Agile and still has value. The problem is when leaders import the wrong manufacturing intuitions: treating software like assembly work, maximizing utilization as if developers were machines, standardizing creative work as if it were repetitive.

Software development is fundamentally different. The work is non-repeatable — you’re not assembling the same widget over and over. The bottleneck moves — yesterday it was code review, today it’s deployment, tomorrow it’s requirements clarity. Goldratt’s Theory of Constraints and Reinertsen’s Principles of Product Development Flow both explain why utilization near 100% means no slack for improvement work, no capacity to absorb surprises, no room to learn. The intuitions that work for assembly-line manufacturing don’t transfer to software development — Titus Winters’ Develop, Deploy, Operate paper in ACM Queue explores this gap — even as the intuitions from lean manufacturing can help.

In manufacturing, predictability comes from standardization. In software, predictability comes from adaptability — from teams that can respond to new information, absorb change, and still deliver. These are opposite strategies. It’s obvious when you say it out loud, but somehow not obvious when you’re in the quarterly planning meeting. Applying the wrong one creates dysfunction that looks like a productivity problem but is actually a mental model problem.

Sometimes the tech leaders get this but their partners in other functions expect a manufacturing paradigm. Finance wants predictable output per headcount dollar. Product wants certainty on timelines. The board wants productivity metrics that look like factory metrics.

The work to be done is education: walking partners through how their desired way of working would have unintended consequences. Showing them that AI gains often get absorbed by infrastructure friction. Helping them understand that leaders looked at cycle time and thought speed was the constraint, looked at story points and thought output was the constraint — and often, they were wrong.

This is uncomfortable work. It requires pushing back on people who have power, challenging assumptions held by people senior to you, telling colleagues in other functions that their intuitions don’t apply. Many tech leaders can’t or won’t do it. The path of least resistance is to acquiesce, to pretend software works like manufacturing, to deliver reports that match expectations even when those expectations are misguided.

That path leads to productivity initiatives that disappoint.

Given all this complexity — the mental models, the leadership drag, the enablement gaps, the political nature of what actually predicts performance — it’s no surprise where most organizations end up: technical fixes. It’s also the easy answer for your board. “We’re investing in AI coding tools and improving our build pipeline.”

Build times. CI/CD improvements. Tooling upgrades. AI assistants. Technical problems with technical solutions. These are real wins, and I’m not dismissing them. But they’re safe. They don’t require organizational change. You can throw engineers at a build time problem. You can buy AI licenses. Engineers are comfortable solving these problems, and leadership is comfortable funding them.

At one organization, there was a homegrown internal authorization system that allowed super-granular permissions. So people set them. The resulting common pattern looked like this: a developer starts work, hits a permissions issue, waits for a human to resolve it. The request gets handled, usually within a few hours — which looks fine from an SLO perspective. The developer continues work, hits another permissions issue, waits again. The cycle repeated constantly, and hours could be lost across a single task.

The team that owned the authorization system had no idea this was happening. They’d built something flexible and powerful. From their perspective, it was working exactly as designed. Individual permission requests were almost always actioned within four hours. They just had no awareness of how their tool was being used in aggregate, how the accumulation of granular permissions created a pattern of constant blocking. And not to knock them — they’d never been evaluated on that before. Nobody had ever asked “how much time do developers spend waiting for permissions?” They weren’t part of the group that focused on that.

This looks like a technical problem. It feels like a technical problem. The authorization system could be redesigned, the permissions model simplified, the request flow automated. But the reason it persisted wasn’t technical. It was organizational. The team that could fix it didn’t know there was anything to fix. There was no system for a random developer to escalate “I spent three hours waiting for permissions today” into something actionable. The structural issue was invisible to the people with power to change it.

The frequent need to find another person in order to get work done is one of the biggest drags on engineering productivity. Some leaders see this clearly and consciously accept it as a trade-off for other benefits — specialization, compliance, knowledge distribution. But many don’t see it at all. And even when they do, they often don’t realize the trade-offs are theirs to reconsider.

Technical wins are real. The trap is staying there — celebrating the safe wins while the harder problems compound.

Even organizations that start strong can lose the thread.

The pattern usually starts simply enough. Someone asks for a dashboard. The dashboard needs data. Someone builds a process to gather the data. The process takes time. Now there’s a meeting to review the dashboard. The meeting needs a deck. Someone spends half a day making the charts look right. Before long, productivity becomes “yet another KPI” — another thing you can claim “impact” on in your performance review. More theater, fewer meaningful improvements.

The metrics that were supposed to drive insight become the metrics that drive behavior. Teams optimize for what gets measured rather than what matters. Leaders compare teams with different constraints, as if the numbers mean the same thing in different contexts. The measurement becomes the work.

I’ve seen this degradation pattern at organizations that once had strong productivity cultures. The commitment and investment were real. But over time — through leadership changes, through pressure for legible results, through the natural tendency to systematize what once was judgment — the signal got lost. What remained was process, dashboards, and quarterly reports that nobody trusted.

What protects against this degradation? Transparency — so the costs of decisions stay visible. Psychological safety — so people can raise concerns when measurement has become theater. And leaders who have actually studied productivity and flow, not just inherited assumptions about how software gets built.

I know this is possible — Kathryn Koehler from Netflix describes an approach where they treat developers as internal customers with a product mindset, actively fight the tendency for “utility per engineer” to decline as orgs scale, and build “paved roads” that make the right choice the easy choice. That’s the kind of sustained investment most organizations never achieve — and Netflix has unusual resources and cultural latitude that don’t transfer cleanly. But the direction is right, even if the destination looks different for you.

Even at organizations doing their best, though, the cross-org or cross-functional issues tend not to get attacked. The pattern of deferral — “push the foundational work out one more quarter” — is chronic. I’ve watched qualitative data pile up showing that developers were relying on other people to make progress far too often. Leadership’s response was lukewarm; they supported initiatives that would address it in some future quarter. Then layoffs happened, and the whole conversation got deprioritized. The problem didn’t get worse, exactly. It just stayed the same.

Real productivity improvement requires organizational commitment — not a side project but an explicit investment. It requires willingness to attack the political and structural problems, not just the technical ones. It requires leadership that can explain to partners why software isn’t manufacturing (and the patience to keep explaining when they forget). And it requires sustained commitment that doesn’t degrade into metrics theater — which, honestly, is the part most organizations fail at.

What does “organizational commitment” actually look like? Headcount dedicated to productivity work, not borrowed from product teams. Budget for tooling and experimentation that doesn’t have to justify itself quarterly. Executive air cover when productivity initiatives create friction with other priorities. Willingness to let teams say “no” to certain work so they have capacity to improve how they work.

But organizational commitment doesn’t mean leadership does all the work.

The team-level playbook for effectiveness is well established. If a line manager can’t run a fundamentally effective team in 2026 — with all of the literature that exists on what works and what doesn’t — that’s worth examining. Sometimes it’s a capability gap that training could address. Sometimes it’s a support gap where the manager was never set up to succeed. And sometimes, yes, it’s a performance issue. But unless leadership has actually provided the conditions for success — stable priorities, reasonable scope, adequate resources — it’s hard to know which one you’re looking at.

Yes, many companies fail to train their managers. That’s real, and it’s on the company in the short term. But managers who’ve been in role for years and haven’t sought out the knowledge themselves have also made a choice. The literature exists. The podcasts exist. The communities exist. At some point, “nobody trained me” stops being an explanation and starts being an excuse. If you’re a manager and you’re not actively learning how to be better at it, that’s on you.

The industry has tolerated a wide range of management practices, some effective and some not, without much accountability either way. When teams underperform, we call it a “productivity problem” — but often it’s a leadership problem, one layer up. Not always malice or ignorance. Sometimes just insufficient attention to whether the conditions for success actually exist.

This is uncomfortable. It means having conversations that nobody wants to have. It means making decisions that create short-term friction for long-term gains that are hard to measure. It means accepting that some of the biggest productivity wins will never show up on any chart.

A developer productivity team can deliver real, sustained wins on technical problems — build times, tooling, CI/CD, developer experience. That’s worth investing in. But even the best productivity team can’t fix the bottlenecks that exist before and after the dev process: the prioritization dysfunction, the coordination overhead, the structural issues that too often require leadership decisions. Those remain leadership’s job.

If you’re in leadership and your developer productivity initiatives keep disappointing, you’re probably looking in the wrong place for answers.

I know many of you are already fighting these battles — pushing back on unrealistic expectations, trying to create space for your teams, running into walls you didn’t build. The constraints are real.

The technical wins your teams can deliver on their own. Build times, tooling, CI/CD — give them slack and budget and they’ll figure it out. That’s not where engineers need leadership help. They need leadership help to actually deliver business value: to understand what outcomes matter, to have authority over the decisions that affect those outcomes, to work in an environment where they can focus on the right problems instead of fighting organizational friction.

What they need you for is creating that environment. The structural work. The cross-functional conversations. The decisions that might make someone uncomfortable. The organizational changes that only you have the authority to make.

Your teams can’t reorganize themselves to reduce coordination overhead. They can’t give themselves budget for experimentation. They can’t make it safe to raise concerns about leadership behavior. They can’t (easily) educate the CFO on why software isn’t manufacturing. They can’t push back when the board wants metrics that encourage gaming. They can’t decide to stop the weekly deck that’s consuming dozens of hours.

Those decisions sit with leadership. That’s not blame — it’s just where the authority lives. (I’m not saying you’re the problem. I’m saying you’re the one with the lever.)

You hold the keys to real productivity. Not your devs, not the managers who report to you, you. That’s a lot to carry. And I know many of you are carrying it in organizations that make it hard.

I know those keys don’t always turn. Board pressure is real. Investor expectations are real. Market conditions, capital constraints, the leader above you who won’t budge — all real. Sometimes you’re fighting for space you’ll never get. Sometimes the locks genuinely can’t be opened from where you sit.

But there’s a difference between fighting for the space and accepting that the locks can’t be opened. Between pushing back on unrealistic expectations and acquiescing because it’s easier. The question is whether you’re spending political capital on the things that matter, or conserving it for … what, exactly?

The challenge is using the keys you have — attacking the hard problems in addition to celebrating the easy wins, educating your partners instead of acquiescing to their assumptions, building an organization where people feel safe surfacing concerns instead of one where leadership drag compounds invisibly.

That’s the work. It’s not easy, and nobody’s going to hand you a roadmap. But if you’ve read this far, you probably already knew that.