Engineering leaders face relentless pressure to ship faster. The tempting response is to push harder, add hours, and demand more. But this approach fails. The 2025 DORA State of AI-Assisted Software Development report, surveying nearly 5,000 technology professionals, reveals that 90% now use AI tools at work, spending a median of two hours daily with them. Yet only 24% trust the output. More telling: extended crunch periods create an almost perfect correlation between overtime and defect rates.
The path to sustainable velocity isn't raw effort. It's removing friction, protecting focus, and building systems that let your engineers do their best work. Here are ten strategies backed by recent research that actually move the needle.
1. Protect focus time by clustering interruptions
The cost of context switching is staggering. Dr. Gloria Mark's research at UC Irvine established that workers need an average of 23 minutes and 15 seconds to fully refocus after an interruption. Her 2023 book Attention Span updated this to roughly 25 minutes and revealed something worse: the average time spent on any screen before switching has dropped to just 47 seconds.
For developers, the damage compounds. GitHub's Good Day Project found that developers have an 82% chance of having a good day with minimal interruptions, but only a 7% chance when interrupted frequently. Paul Graham captured this perfectly in his 2009 essay on the maker's schedule: "A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in."
Action: Implement no-meeting days or cluster all meetings into specific blocks. A 2022 MIT Sloan study of 76 companies found that one meeting-free day per week increased productivity by 35%. Two meeting-free days pushed that to 71%. The optimal balance was three no-meeting days per week, protecting 60% of the work week for focused work.
2. Cut CI/CD wait times to eliminate forced context switches
When a build takes 20 minutes, developers switch to something else. Then they need another 25 minutes to regain context when the build completes. That single build just cost 45 minutes of cognitive overhead.
The 2025 DORA report shows that AI adoption increased throughput but also instability, with teams shipping faster but experiencing higher change failure rates when they lack robust control systems. The difference isn't just speed, it's that fast feedback loops let developers stay in flow.
Action: Invest in incremental builds, parallelized test suites, and intelligent test impact analysis. AI-driven test selection can reduce CI run times by 40-80% by running only tests affected by recent changes. Kent Beck's original 10-minute rule from Extreme Programming Explained: "Automatically build the whole system and run all of the tests in ten minutes. A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback." Every minute beyond that threshold increases the likelihood of costly context switches.
3. Treat internal documentation as a product
The 2024 Stack Overflow Developer Survey found that 61% of developers spend more than 30 minutes daily searching for answers, with 26% spending over an hour. That's one entire workday per week burned on hunting for answers that should be documented.
The impact on teams is severe. New hires take two to three months longer to become productive when documentation is poor. The 2024 Stack Overflow survey also found that while 70% of developers know where to find answers, only 56% can find them quickly, and 53% report that waiting on answers disrupts their workflow.
Action: Allocate dedicated time for documentation maintenance. Treat your internal wikis like a product with owners, roadmaps, and quality standards. Organizations with poor documentation waste hundreds of hours weekly for mid-sized engineering teams, equivalent to losing multiple full-time engineers to information hunting.
4. Deploy AI coding tools, but measure what matters
GitHub Copilot has crossed 20 million users, with 90% of Fortune 100 companies now using it. GitHub's controlled study showed developers completed tasks 55% faster with Copilot, and Duolingo's engineering team estimated 25% speed increases for engineers new to a codebase.
But the data isn't universally positive. A December 2025 CodeRabbit analysis of 470 open-source PRs found AI-generated code produces 1.7x more issues than human-written code, including 1.4x more critical bugs. The 2024 DORA report noted that while AI adoption increased documentation quality by 7.5% and code review speed by 3.1%, it was also associated with higher instability. Meanwhile, only about 33% of developers trust AI code accuracy according to the 2025 Stack Overflow survey, with 46% actively distrusting AI-generated code.
The real risk is "AI sprawl," where teams adopt multiple tools without understanding impact.
Action: Roll out AI assistants to reduce boilerplate and repetitive tasks, where they excel. But measure outcomes, not just adoption. Platforms like Span help leaders see if AI is reducing coding time or just increasing review time, allowing you to optimize the toolchain without guessing. Span's AI code detector can identify AI-generated code with 95% accuracy, giving you ground truth on adoption and impact. The goal is reduced toil, not just more code.
5. Standardize the inner development loop
"It works on my machine" remains one of the most expensive phrases in engineering. Each developer maintaining their own unique environment creates configuration drift, onboarding delays, and debugging nightmares.
Cloud development environments (CDEs) and dev containers eliminate this friction. Teams using mature internal developer platforms report significant reductions in cognitive load and faster onboarding. Spotify's platform engineering team found a 55% improvement in time-to-tenth-pull-request for new developers using standardized environments.
Action: Standardize development environments using containers, devcontainers, or cloud-based development tools. Define the inner loop (edit, build, test, debug) as a first-class product. When any developer can clone a repo and start contributing within hours instead of days, you've removed one of the most persistent friction points in engineering.
6. Set explicit code review SLAs
Code sitting in review is inventory on a shelf. It's not delivering value, it's accumulating merge conflicts, and the author has already context-switched away. Meta's engineering research found a correlation between time-in-review and engineer dissatisfaction.
High-performing teams treat review latency as a key metric. Google's engineering practices mandate responding to code reviews within one business day maximum.
Action: Establish team SLAs for review turnaround. A reasonable target: first review within four hours for internal team PRs, full cycle time under 24 hours. Keep PRs small (under 400 lines) for higher defect discovery rates. Research shows that reducing the time between acceptance and merge can improve code velocity by up to 63%.
7. Create on-call rotations to protect maker time
The "tap on the shoulder" through Slack is insidious. It feels harmless, but it fragments focus and distributes interruptions unpredictably across the team. Shadow work, the unplanned requests and ad-hoc support that never appears on a sprint board, silently drains capacity. When everyone is "available," no one is protected.
Action: Implement explicit on-call rotations where designated engineers handle interruptions while others focus. During on-call workdays, engineers do only on-call work with no feature development expected. If your on-call engineers regularly handle more than 2 incidents per 12-hour shift, Google SRE data suggests your system has reliability problems that need addressing - either through better automation, improved monitoring, or expanding the rotation. This protects the rest of the team's time while ensuring responsive support.
8. Build self-service infrastructure through platform engineering
Filing tickets for AWS access, waiting for DevOps to configure a database, or requesting permission to deploy are all symptoms of underdeveloped platform capabilities. Each handoff adds days of latency and forces developers into waiting mode.
Gartner predicts that by 2026, 80% of large software engineering organizations will have platform engineering teams, up from 45% in 2022. A 2024 survey of Kubernetes experts found 96% of organizations already have a platform engineering function, and the 2024 DORA report showed teams using internal developer platforms saw 10% increases in team performance.
Action: Build "golden paths" for common workflows: deploying a new service, provisioning a database, setting up monitoring. Spotify pioneered this approach, creating opinionated, well-documented pathways that reduce cognitive load while still allowing teams to deviate when needed.
9. Measure systems and processes, not individual output
Stack-ranking developers by commits or lines of code pushes them to game the numbers instead of doing good work, and it destroys psychological safety. The 2024 Stack Overflow survey found that only 20% of developers report being happy at work, with 62% citing technical debt as their top frustration. The DORA research team explicitly warns against using their metrics for individual evaluation—these metrics exist to identify systemic bottlenecks, not to rank people.
Action: Use metrics to debug your engineering system, not your engineers. Look for process flaws: calendar fragmentation, review bottlenecks, deployment friction, documentation gaps. Span's platform is valuable here because it highlights systemic issues, like calendars full of fragmented time, rather than simply counting lines of code. This preserves psychological safety while surfacing real obstacles.
10. Regularly survey developers and act on feedback
Happy developers write better code. The DORA Accelerate research found that high-performing teams are 2x as likely to exceed organizational performance goals. Google's 2022 research established that perceived code quality causally increases productivity. Yet most organizations never systematically ask their engineers what's getting in the way.
Productivity cannot be reduced to a single metric. You need satisfaction data alongside performance data. And you need to actually fix what developers say is broken.
Action: Run quarterly developer experience surveys. Ask what sucks. Then visibly address the top pain points. The investment pays compound returns.
Start with two changes this quarter
You don't need to implement all ten strategies at once. Pick two that address your team's biggest friction points. If your calendar is a disaster, start with meeting-free days. If code rots in review, set explicit SLAs. If developers waste hours searching for answers, invest in documentation.
The goal isn't maximum velocity for one sprint. It's sustainable pace that your team can maintain indefinitely. The 2025 DORA data is clear: AI functions as an amplifier, magnifying the strengths of high-performing teams and the dysfunctions of struggling ones. Teams that prioritize stability and developer well-being outperform those that sacrifice them for short-term speed. Build the system that lets your engineers do their best work, and the velocity will follow.
Top comments (0)