
M365.FM - Modern work, security, and productivity with Microsoft 365
The Productivity Illusion: Why AI is Breaking Your Engineering KPIs
July 25 · 1 hr 15 min · Season 2 · 108.2 MB
0:00-1:15:09
Streams straight from the publisher. podnod never proxies or re-hosts episode audio.
At first glance, the numbers look incredible. Deployment frequency is increasing, pull requests are being merged faster than ever, AI is generating more code, and engineering teams appear dramatically more productive. Executive dashboards are filled with green indicators suggesting software delivery has entered a new golden age. But beneath those impressive metrics lies a very different reality. AI has accelerated code generation, but it hasn't eliminated engineering work. Instead, it has shifted the bottlenecks from writing code to reviewing, validating, governing, and understanding it. Organizations are producing significantly more code while simultaneously experiencing more incidents, higher cognitive load, greater technical debt, and increased developer burnout.
THE PRODUCTIVITY ILLUSION
The central message of this session is simple: More code does not automatically mean more productivity. AI has dramatically increased engineering output, but many organizations are confusing output with value. According to the presentation:
WHY TRADITIONAL KPIs ARE FAILING
Many engineering organizations still rely heavily on classic DevOps metrics such as:
WHEN MORE CODE CREATES MORE PROBLEMS
One of the strongest themes throughout the presentation is the unintended consequence of AI-generated software. Developers can now create thousands of lines of code within minutes. Human reviewers, however, still need to verify every important architectural, security, and business decision. As pull requests become larger and more complex:
THE COGNITIVE LOAD CRISIS
Perhaps the most important concept discussed is cognitive load. AI reduces the effort required to write code. It dramatically increases the effort required to understand that code. Developers now spend increasing amounts of time:
THE TOXIC KPI TRAP
Organizations naturally optimize whatever they measure. The problem arises when the metrics themselves no longer represent organizational health. Examples include:
FROM ACTIVITY TO FLOW
A major recommendation is replacing activity-based thinking with flow-based measurement. Instead of asking: "How much did we ship?" Organizations should ask: "How efficiently does work move through the system?" Important flow metrics include:
DORA 5 AND REWORK RATE
One of the most practical recommendations is expanding traditional DORA metrics with a fifth dimension: Rework Rate. Rather than simply measuring deployment speed, organizations should track how much recently written code must be rewritten shortly afterward. High rework indicates:
BURNOUT IS A SYSTEM METRIC
Another major insight is that burnout should be viewed as an engineering metric—not merely an HR concern. The presentation connects rising cognitive load with:
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
THE PRODUCTIVITY ILLUSION
The central message of this session is simple: More code does not automatically mean more productivity. AI has dramatically increased engineering output, but many organizations are confusing output with value. According to the presentation:
- AI now generates a significant portion of production code.
- Pull request throughput has nearly doubled.
- Developers save substantial time on repetitive coding tasks.
- Yet production incidents, code churn, review times, and cognitive load have all increased.
WHY TRADITIONAL KPIs ARE FAILING
Many engineering organizations still rely heavily on classic DevOps metrics such as:
- Deployment Frequency
- Lead Time
- Change Failure Rate
- Mean Time To Recovery (MTTR)
WHEN MORE CODE CREATES MORE PROBLEMS
One of the strongest themes throughout the presentation is the unintended consequence of AI-generated software. Developers can now create thousands of lines of code within minutes. Human reviewers, however, still need to verify every important architectural, security, and business decision. As pull requests become larger and more complex:
- Review times increase dramatically.
- Senior engineers become bottlenecks.
- Production incidents rise.
- Technical debt accumulates faster.
- More code requires future maintenance.
THE COGNITIVE LOAD CRISIS
Perhaps the most important concept discussed is cognitive load. AI reduces the effort required to write code. It dramatically increases the effort required to understand that code. Developers now spend increasing amounts of time:
- Reviewing AI-generated implementations.
- Understanding unfamiliar logic.
- Switching between contexts.
- Verifying correctness.
- Explaining code the AI never documented.
THE TOXIC KPI TRAP
Organizations naturally optimize whatever they measure. The problem arises when the metrics themselves no longer represent organizational health. Examples include:
- Maximizing AI-generated code percentage.
- Increasing deployment frequency.
- Optimizing story points.
- Reducing review duration.
- Maximizing pull requests per developer.
- Rework increases.
- Stability declines.
- Technical debt grows.
- Review quality drops.
- Engineers burn out.
FROM ACTIVITY TO FLOW
A major recommendation is replacing activity-based thinking with flow-based measurement. Instead of asking: "How much did we ship?" Organizations should ask: "How efficiently does work move through the system?" Important flow metrics include:
- Flow efficiency
- Queue age
- Review cycle time
- Work in Progress (WIP)
- Bottleneck identification
- Rework rate
DORA 5 AND REWORK RATE
One of the most practical recommendations is expanding traditional DORA metrics with a fifth dimension: Rework Rate. Rather than simply measuring deployment speed, organizations should track how much recently written code must be rewritten shortly afterward. High rework indicates:
- Weak verification
- Poor code durability
- Fragile architectures
- Inadequate reviews
- Incorrect AI usage
BURNOUT IS A SYSTEM METRIC
Another major insight is that burnout should be viewed as an engineering metric—not merely an HR concern. The presentation connects rising cognitive load with:
- Developer dissatisfaction
- Increased context switching
- Longer review cycles
- Night and weekend work
- Higher attrition
- Lower software quality
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.