Book a Free Call
No commitment required
TL;DR: Engineering teams are not lazy. They are interrupted. A recent Microsoft study of 484 developers found that the typical workweek dedicates only about 11% of time to writing code, while communication and meetings take roughly 12%.[1] The fix is not hiring more people. It is protecting the attention of the people already in the room.
A Series B CTO told us his team had hired six engineers in the last year and shipped fewer features than the year before. Sprint velocities looked healthy. Deployment frequency was fine. But the roadmap kept slipping.
The problem was fragmentation. Every developer was splitting their day across three active projects, two code reviews, a production alert channel, and a calendar full of “quick syncs.” The team looked busy because they were busy. They were just busy switching contexts instead of finishing work.
This is the context-switching tax, and it is one of the most undermeasured drains on engineering capacity.
Most engineering leaders know headcount. Fewer know how those hours are spent. The data is sobering.
In a 2025 Microsoft Research study, 484 developers reported their actual versus ideal workweeks. The largest single activity was “Communication & Meetings” at roughly 12% of time, followed by “Coding” at about 11%, “Debugging” at about 9%, “Architecting & designing new systems” at about 6%, and pull requests and code reviews at about 5%.[1] Writing code is not even the biggest category. Communication is.
A Tidelift and The New Stack survey found similar patterns: developers spend about 32% of their time writing new code or improving existing code, 35% managing code, and 23% in meetings and operational tasks.[2] In organizations with more than 500 developers, code maintenance alone rose to 32% of the workweek.[2]
If your senior engineers only have about 11% of their week for coding, and much of that is interrupted, your roadmap throughput is capped by attention, not headcount.
The raw meeting time is only half the problem. The other half is what happens between meetings.
Gloria Mark, a UC Irvine researcher who has studied attention for decades, found that after an interruption it takes people an average of 23 minutes and 15 seconds to return to their original task.[3] That is not the time to answer the Slack message. That is the time to get back to the same level of focus.
A RescueTime analysis found that it is rare for knowledge workers to get more than 20 minutes of uninterrupted focus, and that most people average only three minutes on a task before switching.[4] Gerald Weinberg, as cited by RescueTime, estimated that each additional context a person switches between consumes 20% to 80% of productive time.[4]
Engineering work pays an especially high price because it cannot be paused and resumed cleanly. A developer deep in a distributed-system bug loses not just the five minutes spent answering a question, but the mental model they were holding, which might take 20 minutes or until the next morning to rebuild.
Mid-stage SaaS companies are particularly vulnerable because they combine startup chaos with real operational load. The same team building the next integration is on call for the current one and answering customer-success questions about edge cases.
Slack’s 2023 State of Work report quantifies the drag: desk workers spend 32% of their time on “performative work” that looks productive but does not advance outcomes, 43% of meetings could be eliminated with no adverse consequences, and 29% reported difficulty keeping their focus.[5]
For a 20-person engineering team, that means the equivalent of six or seven people are spending much of their week on work that does not move the product forward. Not because they are uncommitted, but because the system fragments their attention.
The business cost shows up in slower lead times. Stripe’s 2018 Developer Coefficient report found developers spend approximately four hours a week on “bad code,” which Stripe calculated as nearly $85 billion in worldwide opportunity cost lost annually.[6] Bad code is partly a technical-debt problem, but it is also a focus problem.
There is a human cost too. Mark’s CHI 2008 study found that after only 20 minutes of interrupted performance, people reported significantly higher stress, frustration, workload, effort, and time pressure.[7] Those conditions drive senior engineers toward the door.
The answer is not to eliminate meetings or ban Slack. The answer is to make deep work the default.
1. Protect contiguous blocks. The Microsoft study found developers’ ideal week allocates about 20% of time to coding and 15% to architecting and designing — roughly double the actual time spent.[1] Block two to four hours of uninterrupted time on the calendar and defend it like a customer call.
2. Cut the meeting load with data. Slack found 43% of meetings could be eliminated without harm.[5] Audit recurring meetings older than six months. If a meeting has no owner, no agenda, and no decision, delete it.
3. Limit work in progress. Every additional active project multiplies switching cost. Teams that finish one feature before starting the next ship more total output than teams juggling five features at 20% completion.
4. Make senior judgment scarce on purpose. Senior engineers are the most expensive context-switchers. Do not waste their time on meetings that could be emails or reviews a mid-level engineer could handle.
Most dashboards track throughput: commits, PRs, deployments. They do not show context switching. Track flow metrics instead.
These metrics are about understanding where capacity is actually going, not surveillance.
Context switching is not a personal productivity problem. It is an organizational design problem. When developers spend only about 11% of their week coding and nearly as much time in meetings, the constraint on your roadmap is not headcount. It is attention.[1]
The SaaS companies that win will protect deep work as a strategic asset. They will run fewer meetings, limit work in progress, and treat senior focus as the scarce resource it is. Their teams will not work more hours. They will spend more of those hours on the work that ships.
At Wawandco, we build embedded engineering teams that slot into a SaaS company’s workflow and start shipping production code in days. The teams that get the most from an embedded partnership are usually the ones that have already decided to protect their engineers’ attention. Once you stop paying the context-switching tax, you discover the capacity you were looking for was already in the building.