LinkedIn "wisdom"

by "Stavros"

The underappreciated strategic risk of having your best engineers in the wrong room

BY STAVROS · MARCH 24, 2026
The underappreciated strategic risk of having your best engineers in the wrong room infographic

The proof is indisputable.

THE INSIGHT

Most companies have a strategy document somewhere. It talks about the next-generation platform, the big migration, the bold new architecture. Inspiring stuff.

Then you look at where the senior engineers actually sit. They're buried in incident rotations, manual deployments, and keeping legacy systems from falling over. The team building that ambitious new platform? Mostly junior developers figuring it out as they go.

Resource allocation is strategy. Clayton Christensen said real strategy is created through hundreds of everyday decisions about where we spend resources. Andy Grove said to ignore what companies say and watch what they do. You can reverse-engineer anyone's real strategy by looking at where the people are.

DORA's research found elite engineering teams spend 50% of their time on new work, while low performers spend just 30%. That gap compounds dramatically. Elite performers deploy 182x more frequently with 127x faster lead times. Organizations with high DORA maturity are twice as likely to exceed profitability targets.

Google formalized this with their SRE 50% rule. Every SRE must spend at least half their time on engineering project work, not toil. They warn about what happens when you break it: a "vicious downward spiral" where there's no time to build solutions that would reduce toil, so toil grows, so there's even less time. The best engineers leave first.

Then there's context switching. Gerald Weinberg showed that splitting an engineer across two projects costs 20% to switching overhead. At five projects, 75% is gone. Csikszentmihalyi's flow research showed a 500% productivity increase in deep focus, but flow requires 15 to 25 minutes of uninterrupted time just to begin. Every operational interruption costs the flow state they never reached.

So your best architect on call for a legacy service is context switching in and out of incidents, never reaching flow, their deep knowledge consumed by work that is manual, repetitive, and automatable. Meanwhile, your platform is being shaped by people who don't yet have the pattern recognition for architectural decisions that will define it for years. BCG found more than 70% of large scale tech programs fail to deliver. The top reason? Lack of resources and expertise.

Conway's Law ties this together. Michael Nygard put it simply: "Team assignments are the first draft of the architecture." Your staffing spreadsheet is an architecture diagram, whether you intended it to be or not.

The 2024 DORA report found AI actually reduced time spent on valuable work by 2.6% while doing nothing to reduce toil. No tool substitutes for putting the right people on the right problem.

Look at your team assignments this week. Where are your most experienced engineers actually spending their hours? That's your real strategy.

THE EVIDENCE

Your best engineers are in the wrong room — and the data proves it costs everything

Putting your most experienced engineers on maintenance while juniors build your next platform isn't a staffing decision — it's an unintentional architectural one. DORA research shows elite engineering teams spend 50% of their time on new work versus just 30% for low performers, a gap that compounds into 182x differences in deployment frequency. Google's SRE framework, McKinsey's developer velocity research, and decades of strategy literature from Clayton Christensen all converge on the same conclusion: how you allocate engineering talent is your real strategy, whether you acknowledge it or not. The data below arms you with specific, citable numbers to make this case.

Elite teams spend 20 percentage points more time on value-creating work

The most granular data on engineering time allocation comes from the 2018 Accelerate State of DevOps report, which surveyed thousands of practitioners and broke down how different performance tiers spend their days:

Time spent on…EliteHighMediumLow
New work (features, platforms)50%50%40%30%
Unplanned work and rework19.5%20%20%20%
Defects identified by end users10%10%10%20%
Customer support work5%10%10%15%
Remediating security issues5%5%5%10%

Low-performing teams spend twice as much time fixing end-user defects (20% vs. 10%) and three times more on customer support (15% vs. 5%) compared to elite teams. [1] This isn't just a time problem — it's a talent trap. The DORA team's conclusion: "Elite performers are getting the most value-add time out of their days and are spending the least amount of time doing non-value-add work of all groups." [1]

The performance gap these time differences produce is staggering. The 2024 DORA report found elite performers achieve 127x faster change lead time, 182x more deployments per year, an 8x lower change failure rate, and 2,293x faster recovery from failed deployments compared to low performers. [2] Organizations with high DORA maturity are 2x more likely to exceed profitability targets, [3] and companies excelling at DevOps metrics show 50% higher market cap growth over three years (from the Accelerate book research). [4] The 2023 DORA report added that teams with shifting priorities experience a 40% higher risk of burnout, [5] and 90% of teams with frequently changing priorities see measurable productivity drops. [6]

A striking equity finding from the 2023 report: women do 40% more repetitive work than men in engineering organizations, and underrepresented respondents carry 29% more repetitive work and report 24% more burnout. [7]

Google caps toil at 50% — and warns of a "vicious downward spiral" beyond it

Google's SRE book defines toil precisely: "work that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows." [8] The six characteristics — manual, repetitive, automatable, tactical, no enduring value, linearly scaling — distinguish genuine toil from hard-but-meaningful engineering. Incident response requiring human judgment is explicitly not toil.

The 50% rule is Google's hard line: every SRE must spend at least 50% of their time on engineering project work, averaged over a few quarters. [9] Google promises this ratio to new SRE hires to distinguish the role from traditional operations. [9] Internal quarterly surveys show Google's average sits at ~33% toil, well within the cap, though outliers range from 0% to 80%. [9]

What happens when the cap is exceeded? The SRE Workbook describes the consequences bluntly:

  • A "vicious downward spiral": "When toil exceeds 50%, there's not enough time to implement the solutions that would reduce toil, creating a vicious downward spiral of pain and ineffectiveness." [10]
  • Attrition of top talent: "If you don't begin to tackle toil before it begins to impact your engineers, you motivate the team's best engineers to start looking elsewhere for a more rewarding job." [11]
  • Career stagnation: "Over the longer term, toil causes career stagnation while promoting burnout-induced turnover." [12]
  • Reduced feature velocity: "A product's feature velocity will slow if the SRE team is too busy with manual work and firefighting to roll out new features promptly." [9]

The Accelerate book adds a queue theory insight: "Once utilization gets above a certain level, there is no spare capacity ('slack') to absorb unplanned work, changes to the plan, or improvement work. Queue theory in math tells us that as utilization approaches 100%, lead times approach infinity." [4] This means toil doesn't just steal time — it creates a mathematical inevitability of slowdown.

Context switching destroys 20–75% of engineering capacity

Gerald Weinberg's famous table from Quality Software Management (1992) quantifies what every engineer feels intuitively: [13]

Simultaneous projectsTime available per projectLoss to context switching
1100%0%
240%20%
320%40%
55%75%

Even adding one additional project costs 20% of productive time. [14][13] At three concurrent workstreams, nearly half of all effort evaporates. [14] Carnegie Mellon's Software Engineering Institute confirmed this: "Once a team member is assigned five projects, his or her ability to contribute to any given project drops below 10%, with 80% of effort lost to switching between project contexts." [15]

Gloria Mark's UC Irvine research found it takes 23 minutes and 15 seconds to return to an original task after interruption, [16] and knowledge workers switch activities every 3 minutes and 5 seconds on average. [17][18] Sophie Leroy at the University of Washington coined the term "attention residue" — when you switch tasks, part of your attention stays stuck on the previous one, [14][18] and for developers working with complex code abstractions, this residue persists for 30–60 minutes. [19]

Paul Graham's "Maker's Schedule, Manager's Schedule" essay captures the downstream consequence: "A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in." [20][21] A 2022 Harvard Business Review study found workers switch between apps and websites ~1,200 times per day, costing roughly 5 working weeks per year (9% of annual work time). [22] Software.com's study of 250,000+ developers found a median of just 52 minutes of actual coding per day. [23] A separate experiment with 50 developers found only 2.3 hours of deep work out of an 8-hour day — just 28.75% of the workday. [24]

Mihaly Csikszentmihalyi's decade-long research on flow states found people achieve a 500% productivity increase when in flow — but flow requires 15–25 minutes of uninterrupted time just to begin. [25] Every operational interruption for a senior engineer doesn't just cost the interruption time; it costs the flow state they might have achieved.

70% of large-scale tech programs fail, and expertise is the top cited factor

BCG's 2024 study of 1,000+ companies across 59 countries found that more than two-thirds (70%) of large-scale tech programs are not delivered on time, within budget, or within scope. The Standish Group's CHAOS Report 2020 shows only 31% of IT projects succeed, [26] with large projects succeeding less than 10% of the time. Projects exceeding $10 million are more than ten times more likely to be canceled than those under $1 million. [27] Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to meet their original business case goals, with as many as 25% failing catastrophically.

Critically, expertise and staffing are consistently cited as the primary failure driver. 78% of organizations identify lack of resources and expertise as the top reason cloud migrations fail. [28] Successful enterprise migrations show a clear pattern: 78% of successful migrations involved at least one certified cloud architect. Forrester data shows partner-led migrations (with experienced teams) finish on time 71% of the time vs. just 49% for self-managed efforts. [29] The Standish Group has listed "skilled personnel" as one of its top project success factors since its original 1994 CHAOS report. [30]

McKinsey's research on "linking talent to value" found that high-performing employees are up to 8x more productive than average performers, [31] and that the top 25–50 roles (roughly 2% of an organization) can create the bulk of a company's potential value. [32][33] Their 2018 global survey of 1,820 participants showed companies that rapidly allocate talent to opportunities have more than twice the likelihood of strong performance, [34] while 99% of respondents with "very effective" talent management said they outperform competitors. [31]

McKinsey's developer productivity research (2023) found that top tech companies aim for developers to spend up to 70% of time on inner-loop activities (building product), not outer-loop work (admin, compliance, provisioning). [35] Separately, engineering teams spend 20–40% of development effort maintaining or working around technical debt, [36] and companies that actively reduce it free up nearly 50% more developer time. [37]

"Resource allocation IS strategy" — what Christensen, Grove, and Conway all agree on

Clayton Christensen's central insight in How Will You Measure Your Life? applies directly to engineering organizations: "Real strategy — in companies and in our lives — is created through hundreds of everyday decisions about where we spend our resources." [38][38] He warned: "The trap many people fall into is to allocate their time to whoever screams loudest, and their talent to whatever offers them the fastest reward. That's a dangerous way to build a strategy." [39] In The Innovator's Dilemma, he showed how resource allocation filters in successful companies become so attuned to existing strategy that they automatically reject disruptive innovations [40][41] — the very thing your best engineers should be building.

Andy Grove put it even more directly: "To understand a company's strategy, look at what they actually do rather than what they say they will do." [38][38] His own Intel was the canonical case: while the stated strategy was memory chips, middle managers were quietly allocating factory resources to microprocessors [42] — the actual strategy playing out through resource decisions, not boardroom declarations. [43]

Roger Martin, ranked the world's #1 management thinker in 2017, [44] quantified the disconnect: "The R-squared for the correlation between strategy and strategic plans is implicitly presumed to be close to 1.0. My observation is that it isn't higher than 0.2–0.3." [45] He added: "Without ever reading its strategic plan, I can easily reverse-engineer any company's strategy by simply watching what it does." [45]

Conway's Law completes the picture for engineering organizations. Melvin Conway's 1968 observation — "organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations" [46] — has been validated by 142 empirical studies reviewed by Harvard Business School researchers (Colfer & Baldwin, 2016). [47][48] Michael Nygard distilled it to a single sentence: "Team assignments are the first draft of the architecture." [49] Ruth Malan sharpened the warning: "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins." [49][50]

Matthew Skelton and Manuel Pais argued in Team Topologies (2019) [51] that it is "very ineffective (perhaps irresponsible) for organizations that build software systems to decide on the shape, responsibilities, and boundaries of teams without input from technical leaders." [49] The ThoughtWorks Technology Radar endorsed the "Inverse Conway Maneuver" — deliberately reshaping team structure to achieve desired architecture [52][50] — as a practice worth pursuing. [53]

Conclusion: the staffing spreadsheet is an architecture diagram in disguise

The convergence across these domains is unusually tight. DORA's data proves the 20-percentage-point gap in time spent on new work between elite and low-performing teams. [1] Google's SRE framework demonstrates the vicious spiral when toil exceeds its cap. [10] Weinberg and Mark quantify the 20–75% productivity tax from context switching. [54] BCG and Standish document the 70%+ failure rate of large-scale tech programs, [55] with expertise as the top cited driver. And Christensen, Grove, Martin, and Conway all converge on the same principle: resource allocation doesn't implement strategy — it IS strategy. [38]

The novel insight for engineering leaders: every time you assign a senior engineer to keep-the-lights-on work instead of your next platform, you haven't just made a staffing decision. You've made an architectural decision, a strategic bet, and a cultural signal — all at once. The 2024 DORA report's most provocative finding may be that even AI adoption doesn't fix this: AI reduces time on valuable work by 2.6% while doing nothing to reduce toil. [56][57] There is no tool-based shortcut around the fundamental question of where your best people spend their hours.

  1. dora — https://dora.dev/capabilities/well-being/
  2. Libertify — https://www.libertify.com/interactive-library/state-of-devops-2024-dora/
  3. Multitudes — https://www.multitudes.com/blog/dora-metrics
  4. Tech Blog — https://blog.shanelee.name/2022/05/15/book-review-accelerate-and-my-experience-in-high-performing-organisations/
  5. Opslevel — https://www.opslevel.com/resources/tl-dr-key-takeaways-from-the-2024-google-cloud-dora-report
  6. DevOps Launchpad — https://devopslaunchpad.com/blog/dora-report-2024/
  7. Google Cloud — https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-state-of-devops-report
  8. Google Cloud — https://cloud.google.com/blog/products/management-tools/identifying-and-tracking-toil-using-sre-principles
  9. Google — https://sre.google/sre-book/eliminating-toil/
  10. Sapience Consulting — https://www.sapience-consulting.com/sre-toil-war-on-manual-work/
  11. Cloudsoft — https://cloudsoft.io/blog/toil-burnout
  12. Google — https://sre.google/workbook/eliminating-toil/
  13. Coding Horror — https://blog.codinghorror.com/the-multi-tasking-myth/
  14. RescueTime — https://blog.rescuetime.com/context-switching/
  15. SEI Insights — https://insights.sei.cmu.edu/devops/2015/03/addressing-the-detrimental-effects-of-context-switching-with-devops.html
  16. I DONE THIS — https://blog.idonethis.com/distractions-at-work/
  17. Fast Company — https://www.fastcompany.com/944128/worker-interrupted-cost-task-switching
  18. Super Productivity — https://super-productivity.com/blog/context-switching-costs-for-developers/
  19. Jellyfish — https://jellyfish.co/library/developer-productivity/context-switching/
  20. GitHub — https://github.com/joelparkerhenderson/ways-of-working/blob/main/doc/makers-schedule-managers-schedule-by-paul-graham/index.md
  21. paulgraham — https://paulgraham.com/makersschedule.html
  22. Workjoy — https://workjoy.co/blog/scientific-research-notifications-and-interruptions-negatively-affect-work
  23. Software.com — https://www.software.com/reports/code-time-report
  24. Medium — https://medium.com/@codewithmunyao/the-hidden-cost-of-context-switching-why-your-most-productive-hours-are-disappearing-43c5b501de19
  25. TechWorld with Milan — https://newsletter.techworld-with-milan.com/p/you-can-code-only-4-hours-per-day
  26. ACM Queue — https://queue.acm.org/detail.cfm?id=3687999
  27. Medium — https://medium.com/@marc.bara.iniesta/the-missing-data-why-we-dont-really-know-if-big-companies-fail-more-at-tech-projects-311349cadbb9
  28. Epiuse — https://www.epiuse.com/aws-services/blogs/why-over-75-of-cloud-migrations-fail
  29. Medhacloud — https://medhacloud.com/blog/cloud-migration-statistics-2026
  30. University of Texas at Dallas — https://personal.utdallas.edu/~chung/SYSM6309/chaos_report.pdf
  31. McKinsey — https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-talent-management
  32. McKinsey & Company — https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-organization-blog/building-a-talent-first-organization-begins-with-addressing-these-3-biases
  33. McKinsey & Company — https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/hr-rewired-an-end-to-end-approach-to-attracting-and-retaining-top-tech-talent
  34. McKinsey & Company — https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/winning-with-your-talent-management-strategy
  35. McKinsey & Company — https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity
  36. Code Climate — https://codeclimate.com/blog/what-is-technical-debt
  37. Codeant — https://www.codeant.ai/blogs/track-technical-debt
  38. fs — https://fs.blog/2012/07/your-strategy-is-not-what-you-say-it-is-clayton-christensen/
  39. Goodreads — https://www.goodreads.com/author/quotes/1792.Clayton_M_Christensen
  40. Medium — https://medium.com/version-1/the-innovators-dilemma-6de68da8fabc
  41. Goodreads — https://www.goodreads.com/work/quotes/138639-the-innovator-s-solution-creating-and-sustaining-successful-growth
  42. Smoak Signals — https://anthonysmoak.com/2016/03/27/andy-grove-and-intels-move-from-memory-to-microprocessors/
  43. Hypeinnovation — https://www.hypeinnovation.com/blog/8-principles-of-the-innovators-solution
  44. Consulting Success® — https://www.consultingsuccess.com/how-to-create-winning-consulting-strategies-with-roger-martin
  45. Medium — https://rogermartin.medium.com/finishing-strategy-fdc1409a0640
  46. Harvard University +2 — https://dash.harvard.edu/bitstreams/7312037e-28a6-6bd4-e053-0100007fdf3b/download
  47. Harvard University — https://dash.harvard.edu/handle/1/33785675
  48. Wikipedia — https://en.wikipedia.org/wiki/Conway's_law
  49. IT Revolution — https://itrevolution.com/articles/conways-law-critical-for-efficient-team-design-in-tech/
  50. Medium — https://medium.com/@fwynyk/conways-law-in-team-topolgies-did-you-really-get-it-69c1a4d702af
  51. Amazon — https://www.amazon.com/Team-Topologies-Organizing-Business-Technology/dp/1942788819
  52. Cathalgreaney — https://cathalgreaney.com/organizing-teams/003-conways-law/
  53. Thoughtworks — https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver
  54. Hubstaff — https://hubstaff.com/blog/context-switching/
  55. Mindera — https://mindera.com/blog/why-do-so-many-tech-projects-fail
  56. RedMonk — https://redmonk.com/rstephens/2024/11/26/dora2024/
  57. Google Cloud — https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report

EDITORIAL BRIEF

Commissioned from our research desk. Subject to final editorial discretion.

The underappreciated strategic risk of having your best engineers in the wrong room. Discuss how technical strategy fails not at the whiteboard but in staffing decisions—when senior engineers are locked into keep-the-lights-on work while junior developers are tasked with building the next-generation platform. Research data on how engineering time allocation (toil vs. strategic work) correlates with delivery outcomes from DORA or State of DevOps reports. The takeaway is that resource allocation is architecture, whether you acknowledge it or not.