The Enforcement Trap: Why Pressuring Developers Guarantees Failure Link to heading
A few weeks ago, a CEO told me their dev team was the problem. Developers wouldn’t meet deadlines, they’d just work on what they wanted, and they never finished features.
This created a huge backlog with important customer projects, resulting in unsatisfied customers. The company wanted to scale, but the CEO feared adding more projects and people would ruin them in their current state.
The solution? Establish a performance culture by enforcing developers to finish and deliver features. Bad Glassdoor reviews only confirmed his belief that developers were ruining the company.
My first reaction: It’s 2025, and we’re still discussing dev team “performance” from a sales perspective? I thought the “us vs. them” era was over. But then I reconsidered.
Maybe the real issue is that we’re treating symptoms while the disease spreads unchecked. Research from 2024/2025 actually suports this hypothesis.
Generated with AI ∙ 9 October 2025 at 06:03 pm
The Business Reality Link to heading
Before diving into the data, let me be clear: I understand the CEO’s situation. Revenue must grow and margins must improve. Customers must be satisfied, while investors or boards expect results. A CEO can never ignore financial performance.
But investing in developer experience isn’t about creating comfort zones or protecting developers from pressure. It’s about removing obstacles that prevent your engineering organization from delivering business value efficiently.
When developers have the right tools, clear priorities, and realistic timelines, they deliver more value faster. When technical debt is managed proactively, the cost of new features decreases over time instead of increasing. When there’s psychological safety, problems surface early when they’re cheap to fix, not late when they’re expensive disasters. When sales and engineering align on what’s feasible, customer promises get kept and satisfaction increases.
Developer experience is a business investment with measurable returns. Companies with high developer velocity show significantly better business performance. They’re more innovative, more profitable, and better positioned for growth. This isn’t about being nice to developers. It’s about building an organization capable of executing on business goals.
What Research Shows About Developer Productivity Link to heading
McKinsey’s research on Developer Velocity identifies four capabilities with the greatest impact on business performance: tools, culture, product management, and talent management.
Notice what’s missing? Enforcement. Pressure. Demanding developers “finish features.”
The data shows the opposite: Organizations with strong developer tools are 65% more innovative than bottom-quartile companies and have 47% higher developer satisfaction and retention rates. That’s not about cracking the whip. It’s about removing obstacles.
When velocity metrics become performance indicators, they don’t improve performance. They destroy collaboration. Developers start gaming the system, optimizing for looking productive rather than being productive. Teams avoid necessary refactoring that might slow velocity numbers but would improve long-term quality.
Research across 17 leading tech companies shows they don’t use wholesale adoption of frameworks like DORA or SPACE. They develop context-specific metrics that illuminate problems rather than create new ones. Not a single one measures “enforcement of feature completion.”
The Developer Experience Dimension Link to heading
Let’s revisit the CEO’s complaints through a different lens. Developers “just work on what they want” and “never finish features.” That’s not laziness. It’s a rational response to an irrational environment.
The DevEx framework, developed by the people behind DORA and SPACE, focuses on three critical dimensions: feedback loops, cognitive load, and flow state. When developers constantly switch between unfinished features or work on technical debt instead of new features, they might be trying to manage impossible cognitive load or fix broken feedback loops that leadership can’t see.
Technical debt is a perfect example. To non-technical leadership, it looks like developers wasting time on invisible work when they should build features customers are asking for. But organizations with dedicated technical debt management achieve 27% higher velocity over time compared to those who address debt reactively. These developers are trying to prevent the entire system from collapsing.
The “never finishing features” pattern is equally telling. When developers consistently fail to complete work, it’s rarely incompetence or lack of motivation. It’s usually because:
- The scope was unrealistic from the beginning
- Requirements changed mid-development (often based on sales promises)
- Technical dependencies weren’t understood or communicated
- The definition of “done” differs between sales, product, and engineering
None of these are solved by enforcement.
What Actually Causes This Scenario Link to heading
The 2024 DORA report emphasizes something critical: Organizations that prioritize user-centric approaches and work under transformational leadership with clear strategic direction consistently outperform others. Not organizations that enforce. Not organizations that pressure. Organizations that lead.
And those Glassdoor reviews the CEO cited? They’re evidence of the real problem. When employee reviews are consistently negative, it’s not validation that employees are the problem. It’s a screaming alarm that leadership has created an environment where people can’t do their best work.
Poor leadership communication alone leads to a 25% reduction in team productivity. When leaders fail to articulate goals clearly, when they create environments where developers are blamed for systemic failures, they multiply problems rather than solve them.
This scenario has all the hallmarks of dysfunctional leadership:
Misaligned Incentives: Sales is rewarded for signing contracts, regardless of feasibility. Engineering is blamed when they can’t deliver what was promised. There’s no shared accountability for realistic commitments.
Communication Breakdown: Developers don’t set their own deadlines. Someone else sets them without technical context to understand what’s realistic. Then everyone is surprised when reality doesn’t match the arbitrary timeline.
Blame Culture: The entire framing is about what developers are doing wrong. Not what the organization is doing wrong. Not what sales is doing wrong. Just developers.
Missing Psychological Safety: In healthy organizations, developers can say “this timeline is unrealistic” without fear. They can say “we need to address technical debt” without being accused of working on what they want.
Lack of Clear Priorities: A huge backlog of unfinished features suggests everything is a priority, which means nothing is a priority. That’s a leadership failure, not a developer failure.
The Scaling Paradox Link to heading
The CEO was right about one thing: They can’t scale in their current state. But enforcing developers to finish features would make scaling harder.
Scaling requires systems that can handle increased load (requires addressing technical debt), processes that work with more people (requires realistic planning and clear priorities), culture that attracts and retains talent (requires psychological safety and good tooling), and alignment across functions (requires communication and shared understanding).
Enforcement provides none of these. It undermines all of them.
Organizations that successfully scale invest in developer experience. They reduce cognitive load. They fix broken feedback loops. They create environments where flow state is possible. They align business and engineering goals rather than pitting them against each other.
Companies that try to scale by pressuring developers to work faster hit a wall. Technical debt accumulates faster. Good developers leave. The ones who stay have learned to game whatever metrics leadership uses. Quality plummets. Customer satisfaction drops. And leadership blames developers for not working hard enough.
What Actually Helps Link to heading
During our discussion, I suggestes the following things::
Start with joint planning sessions between sales, product, and engineering. Before any commitment is made to a customer, engineering needs to weigh in on feasibility, scope, and timeline. Sales needs to understand technical constraints. This isn’t bureaucracy. It’s basic risk management.
Let developers set their own commitments. They’re the ones doing the work. They understand the complexity. When people commit to their own goals, they’re far more likely to achieve them than when goals are imposed. But hold them to it - the teams need to understnad that once they gave a commitment, it’s their responsibility to keep it.
Invest in tools and reducing cognitive load. Ask developers what’s slowing them down. Is it a painful deployment process? Inadequate test environments? Constant interruptions? Poor documentation? Fix those things.
Measure outcomes, not activity. Stop tracking whether developers are “finishing features” and start tracking whether customers are getting value. Those aren’t always the same thing. Sometimes the most valuable thing a developer can do is prevent a disaster by addressing technical debt.
Create psychological safety. Developers need to be able to say “this won’t work” or “we need more time” or “this approach has technical problems” without being labeled as difficult or uncommitted. If you punish honesty, you’ll get silence instead. Keeping communication alive is key to success.
Listen before enforcing. Talk to the developers. Not to tell them what they’re doing wrong, but to understand what they’re experiencing. What obstacles are they facing? What would help them be more effective?
The Real Choice Link to heading
In 2025, we know what works. The evidence is overwhelming. High-performing organizations don’t enforce, they enable. They don’t pressure, they prioritize. They don’t blame, they build.
The choice isn’t between developer happiness and business results. The choice is between short-term pressure that undermines long-term capability, and building the organizational foundation that makes sustained growth possible.
One approach might feel like action. The other actually works.
The responsibility doesn’t belong to developers failing to finish features. It belongs to the leadership that created conditions where finishing features became impossible.
And until that changes, scaling will remain a distant dream, no matter how much enforcement is applied.