LinkedIn "wisdom"

by "Stavros"

The pattern where organizations staff technical strategy with senior individual contributors who have deep system expertise but no organizational power, then wonder why recommendations die in committee

BY STAVROS · MAY 16, 2026
The pattern where organizations staff technical strategy with senior individual contributors who have deep system expertise but no organizational power, then wonder why recommendations die in committee infographic

The proof is indisputable.

THE INSIGHT

I keep seeing the same story play out.

A company has a hard technical problem that cuts across teams. Maybe their data platform, their service architecture, or how to do AI without setting money on fire. So they take their best senior engineer, the one with 20 years of scar tissue and deep system knowledge, and give them a title like Principal Architect or Director of Technical Strategy. Then they send them off to figure it out.

The person does the work. They talk to everyone, read the code, write a careful document, and the recommendations are good. Six months later, nothing has happened, or the recommendation has been quietly diluted in committee until it means whatever each team already wanted.

Two different things get called "influence" in organizations, and we pretend they're the same.

The first is influence by expertise. People listen because you know more than they do. Yukl and Tracey showed rational persuasion outperforms pressure and positional appeals in every direction. The second is influence by mandate. People do what you say because you control the budget, the headcount, or the performance review. This is the only kind that reliably converts a recommendation into a line on a roadmap.

When we staff technical strategy with a senior IC, we give them the first for free and explicitly withhold the second, then ask them to drive cross-cutting change against teams whose VPs hold all the resources.

Camille Fournier put this cleanly in The Manager's Path: a CTO without managerial authority is effectively powerless. Will Larson, describing his attempt to mediate a Ruby versus Java debate at Stripe, said the strategy failed for "the lack of any enforcement mechanism." Prosci has run change-management benchmarks since 1998 with the same finding every year. Projects with effective executive sponsors hit objectives 79% of the time. Without them, 27%. McKinsey is bleaker: among transformations that fail to engage line management, the success rate is 3%.

So when we put a brilliant person into a role with responsibility for outcomes and no control over the people or money that would produce them, we run an experiment whose result has been known for thirty years. The strategy is sound, and the organization is structurally incapable of executing it.

Strategy without resource control is consulting. Companies ignore it for the same reason they ignore most consulting decks: nobody's budget moves when the deck turns out to be right or wrong.

If you want technical strategy to land, only two configurations work. Either the person setting strategy controls real resources (budget, headcount, an enforcement mechanism on the paved road), or they are formally paired with an executive who does and who shows up when strategy collides with quarterly planning. Anything else is asking a thoughtful person to spend a year writing a document the organization will treat as one.

THE EVIDENCE

Research brief: Technical strategy without organizational authority

A factual research overview compiled for a LinkedIn post aimed at engineering leadership. All claims are sourced. This is reference material, not opinion writing.

1. Influence-by-expertise vs. influence-by-mandate

French & Raven's bases of social power (foundational framework)

  • Original citations: French, J. R. P., Jr., & Raven, B. (1959). "The Bases of Social Power." In D. Cartwright (Ed.), Studies in Social Power (pp. 150–167). Ann Arbor: Institute for Social Research. PDF: [1]. Raven (1965) later added informational power; Raven (2008), "The Bases of Power and the Power/Interaction Model of Interpersonal Influence," Analyses of Social Issues and Public Policy, 8(1), 1–22. [2]
  • The six bases: Legitimate (formal position), Reward, Coercive, Expert (perceived special knowledge), Referent (identification), Informational (control over information). Legitimate/Reward/Coercive are categorized as positional/formal; Expert, Referent, Informational are personal. ([3])
  • Bounded nature of expert power: "Expert Power… stems from perceived competence, meaning it may sometimes exist outside formalized hierarchies… However, this kind of power is limited to domains in which the expert can exercise proficiency." (Penn State Applied Social Psychology, [4]) "It is also situation-specific; you may hold significant expert power in one context but very little in another." ([5]) [4][5]

Empirical effectiveness — Yukl & Tracey influence-tactics research

  • Yukl, G., & Tracey, J. B. (1992). "Consequences of influence tactics used with subordinates, peers, and the boss." Journal of Applied Psychology, 77(4), 525–535.
  • Falbe, C. M., & Yukl, G. (1992). "Consequences for managers of using single influence tactics and combinations of tactics." Academy of Management Journal, 35(3), 638–652. ([6])
  • Key findings: The three most effective tactics across upward, lateral, and downward directions are rational persuasion, inspirational appeal, and consultation. Pressure, coalition, and legitimating (positional/legitimate power) ranked as the least effective tactics. "Pressure, legitimating, and coalition are less effective than the other tactics." ([7]) [8][6]
  • Meta-analysis: Lee, S., Han, S., Cheong, M., Kim, S. L., & Yun, S. (2017). "How do I get my way? A meta-analytic review of research on influence tactics." Leadership Quarterly, 28(1), 210–228. Meta-analysis of 49 independent samples (N=8,987): "Rational persuasion is the only tactic which held stable positive relationships with both categories of outcomes regardless of moderating factors." Negative relationship between pressure and outcomes. ([8]) [8][8]
  • Implication: Expert/rational influence is empirically more effective for compliance than raw positional power — but it works through persuasion, not enforcement, meaning implementation still depends on those holding resources.

Mintzberg — Power In and Around Organizations (1983)

  • Mintzberg, H. (1983). Power In and Around Organizations. Prentice-Hall. 700 pp. Free from author: [9]
  • Five "Systems of Influence" within the internal coalition: (1) Personal control (chief executive's authority), (2) Bureaucratic controls (rules, formal authority), (3) Ideology (culture/norms), (4) System of Expertise (knowledge-based), (5) System of Politics (informal power). [10]
  • Mintzberg's framing: experts "influence decision-making in specific areas of technical expertise, and by extension within a business that relies upon that technology" — but warns "others in the firm usually do not have the technical expertise or credibility to effectively challenge any such recommendations." ([11]) [11][11]
  • Meritocracy is Mintzberg's term for a configuration where the system of expertise dominates — bounded to technical sphere, competing with administrative/political systems.

Pfeffer — power, authority, and resources

  • Pfeffer, J. (1992). Managing With Power: Politics and Influence in Organizations. HBS Press. ([12])
  • Pfeffer, J. (2010). Power: Why Some People Have It—and Others Don't. HarperBusiness. ([13])
  • Pfeffer & Salancik (1978/2003). The External Control of Organizations: A Resource Dependence Perspective. Stanford Business Classics.
  • Core thesis of Managing With Power: "Although much has been written about how to make better decisions, a decision by itself changes nothing… Problems of implementation are really issues of how to influence behavior, change the course of events, overcome resistance, and get people to do things they would not otherwise do. In a word, power." [12][14]
  • Pfeffer's advice in Power (2010): "Choose positions that have greater direct resource control of more budget or staff. This generally means preferring line positions to staff positions, as line positions usually control more employees and budgetary authority." ([15]) [15]
  • "Headhunters often use the number of people who report to you as a proxy for power." (same source) [15]
  • Resource Dependence Theory: Organizations hold power over a focal firm "if they control resources that are vital to its ongoing operation and cannot be acquired elsewhere." ([16]) [17]

Cohen & Bradford — Influence Without Authority (1989/2005)

  • Cohen, A. R., & Bradford, D. L. (2005). Influence Without Authority (2nd ed.). Wiley. ([18])
  • Core model — "Currencies of Exchange": Five categories — inspiration-related, task-related, position-related, relationship-related, personal-related. Influence operates via reciprocal exchange. [19]
  • Decision criterion (the book's own caveat): "Centrality of the ally — How powerful is the other person? Power means more than hierarchical position: What needed resources does he or she control? How exclusive is the person's control of those resources? How dependent are you on that person for success?" (Cohen & Bradford, pp. 134–136, cited at [20]) [20]
  • Documented critique: "All of the levers, though, revolve around Exchange — which every student of leadership knows is only one of the tools of influence." (Goodreads review) The exchange model fails when you have nothing the counterparty wants. [21]

"Responsibility without authority" / NAG syndrome

  • "NAG syndrome" (No Authority Gauntlet): "You hand someone a management job, but one without commensurate management authorities… make this person accountable for the work of others, but with no accompanying clout… In some organizations, NAG is practically synonymous with project management." ([22]) [22][23]
  • Originally articulated in Victor Sang Tng (2013). [24]
  • Chronicle of Higher Education: "Responsibility without authority creates a perfect storm of frustration, inefficiency, and in many cases, burnout. The structural ambiguity of these roles has real consequences. Good ideas stall, not because of poor leadership, but because of invisible organizational bottlenecks." ([25]) [25]
  • Daniel Mezick (Inviting Leadership): "Delegation carries the risk of the 'responsibility without authority' pattern, which is a 'no win' pattern of failure. It opens the door to employee disengagement and even resentment." ([26]) [26]
  • Listed alongside other top stakeholder anti-patterns by Jasper Morgan (Snapp Mobile): [27] [27]

Beer & Eisenstat — The Silent Killers of Strategy Implementation (MIT Sloan, 2000)

  • Beer, M., & Eisenstat, R. A. (2000). "The Silent Killers of Strategy Implementation and Learning." MIT Sloan Management Review, 41(4), 29–40. [28]
  • Six "silent killers": (1) Top-down/laissez-faire senior management style; (2) Unclear strategy and conflicting priorities; (3) Ineffective senior management team; (4) Poor vertical communication; (5) Poor coordination across functions, businesses, or borders; (6) Inadequate down-the-line leadership skills and development. [29]
  • Highly applicable to cross-cutting technical strategy: items 5 and 6 directly describe horizontal initiative failure modes.
  • HBR Podcast (2021): "Building Influence Without Authority." [30]
  • Conger, J. — HBR/HBSP: "Debriefing Jay Conger: Exerting Influence Without Authority." [31]
  • Turner, A. N. (1982). "Consulting Is More Than Giving Advice." HBR, Sep–Oct. "Each year management consultants in the United States receive more than $2 billion for their services. Much of this money pays for impractical data and poorly implemented recommendations." [32] [32]

2. Cross-cutting technical initiative success/failure rates

Digital transformation failure

  • McKinsey "70% of transformations fail" — McKinsey, "Perspectives on Transformation": "Seventy percent of transformations fail. Contributing factors include insufficiently high aspirations, a lack of engagement within the organization, and insufficient investment in building capabilities…" ([33]). Origin: Kotter (1996), Leading Change. [34][33]
  • McKinsey, "Unlocking success in digital transformations" (October 2018), n=1,521:

"Only 16 percent of respondents say their organizations' digital transformations have successfully improved performance and also equipped them to sustain changes in the long term." Adding sustained-only respondents brings the total to ~23%. [35] Even in tech/media/telecom, success rates "do not exceed 26 percent." [35] In oil/gas/auto/pharma: 4–11% success rates. [35] "At organizations with fewer than 100 employees, respondents are 2.7 times more likely to report a successful digital transformation than are those from organizations with more than 50,000 employees." [35] URL: [36]

  • "Only 16 percent of respondents say their organizations' digital transformations have successfully improved performance and also equipped them to sustain changes in the long term." Adding sustained-only respondents brings the total to ~23%. [35]
  • Even in tech/media/telecom, success rates "do not exceed 26 percent." [35]
  • In oil/gas/auto/pharma: 4–11% success rates. [35]
  • "At organizations with fewer than 100 employees, respondents are 2.7 times more likely to report a successful digital transformation than are those from organizations with more than 50,000 employees." [35]
  • URL: [36]
  • McKinsey, "Losing from day one" (December 2021):

"The 30 percent success rate hasn't budged after many years of research." [37] "An average 42 percent of financial benefits are lost during the latter stages of a large-scale change effort." [38] "Among transformations that fail to engage either line managers or frontline employees, only 3 percent of respondents report success." [39] URL: [39]

  • "The 30 percent success rate hasn't budged after many years of research." [37]
  • "An average 42 percent of financial benefits are lost during the latter stages of a large-scale change effort." [38]
  • "Among transformations that fail to engage either line managers or frontline employees, only 3 percent of respondents report success." [39]
  • URL: [39]
  • BCG, "Flipping the Odds of Digital Transformation Success" (October 2020), n=825 + 70 case studies:

"Only 30% of transformations met or exceeded their target value and resulted in sustainable change." [40] "44% created some value but did not meet their targets and resulted in only limited long-term change." [40] "A final 26% created limited value (less than 50% of the target) and produced no sustainable change." [40] With six success factors in place, odds rise from 30% → 80%. [41][40] URLs: [42]; [43]

  • "Only 30% of transformations met or exceeded their target value and resulted in sustainable change." [40]
  • "44% created some value but did not meet their targets and resulted in only limited long-term change." [40]
  • "A final 26% created limited value (less than 50% of the target) and produced no sustainable change." [40]
  • With six success factors in place, odds rise from 30% → 80%. [41][40]
  • URLs: [42]; [43]
  • Bain — "Transformation & Change Survey" (April 15, 2024), n=400+ executives:

"88% of business transformations fail to achieve their original ambitions" — only 12% achieve original ambition. [44][45] "In Bain's experience, 90% of the value and results of any transformation are created by less than 5% of roles." [46] URL: [44]

  • "88% of business transformations fail to achieve their original ambitions" — only 12% achieve original ambition. [44][45]
  • "In Bain's experience, 90% of the value and results of any transformation are created by less than 5% of roles." [46]
  • URL: [44]
  • Caveat: Hughes, M. (2011). "Do 70 Per Cent of All Organizational Change Initiatives Really Fail?" Journal of Change Management, 11(4), 451–464, found no robust empirical foundation for the precise 70% figure. Treat as directional. [47]
  • PMI: "61% of respondents acknowledge their firms struggle to bridge the gap between strategy formulation and day-to-day implementation." Executives estimate strategic-initiative failure rate ~44%. ([48]) [48]

AI/ML initiative failure

  • RAND Corporation, "The Root Causes of Failure for Artificial Intelligence Projects" (August 2024), n=65 structured interviews:

"By some estimates, more than 80 percent of AI projects fail — twice the rate of failure for information technology projects that do not involve AI." [49] Five root causes: mis-set problems, insufficient/wrong data, focus on tech over problem, lack of infrastructure, applying AI where it can't solve. URL: [49]; PDF: [50]

  • "By some estimates, more than 80 percent of AI projects fail — twice the rate of failure for information technology projects that do not involve AI." [49]
  • Five root causes: mis-set problems, insufficient/wrong data, focus on tech over problem, lack of infrastructure, applying AI where it can't solve.
  • URL: [49]; PDF: [50]
  • MIT NANDA, "The GenAI Divide: State of AI in Business 2025" (July/August 2025), 52 exec interviews + surveys of 153–350 leaders/employees + analysis of 300 public AI deployments; $30–40B enterprise GenAI spend tracked:

"95% of pilots delivered no measurable P&L impact. Only 5% of integrated systems created significant value." [51] "Purchasing AI tools from specialized vendors and building partnerships succeed about 67% of the time, while internal builds succeed only one-third as often." [52] "60% of organisations evaluated [enterprise-grade systems], but only 20% reached pilot stage and just 5% reached production." [51] URLs: [53]; [51]

  • "95% of pilots delivered no measurable P&L impact. Only 5% of integrated systems created significant value." [51]
  • "Purchasing AI tools from specialized vendors and building partnerships succeed about 67% of the time, while internal builds succeed only one-third as often." [52]
  • "60% of organisations evaluated [enterprise-grade systems], but only 20% reached pilot stage and just 5% reached production." [51]
  • URLs: [53]; [51]
  • Gartner (July 29, 2024 press release, Rita Sallam): "At least 30% of generative AI (GenAI) projects will be abandoned after proof of concept by the end of 2025, due to poor data quality, inadequate risk controls, escalating costs or unclear business value." Costs cited: $5M–$20M for GenAI projects. URL: [54] [55]
  • Gartner "85% of AI projects fail" — widely cited from Gartner research circa 2018–2019; original press release URL no longer prominent; cause cited: poor data quality and lack of relevant data. [56]
  • BCG, "Where's the Value in AI?" (October 2024), n=1,000 CxOs across 20+ sectors and 59 countries: "Only 4% of companies have cutting-edge AI capabilities. Just 22% are beginning to realize substantial gains. The remaining 74% struggle to generate tangible value." [57]
  • S&P Global (2025): "42% of companies abandoned most AI initiatives this year, up from 17% in 2024. Average organization scrapped 46% of AI POCs before production." [58][59]
  • McKinsey State of AI 2025: "71% of respondents say their organizations regularly use gen AI in at least one business function." But "over 80% of respondents say their organizations are not seeing a tangible impact on enterprise-level EBIT from their use of gen AI." URL: [60] [60]

Platform engineering / Internal Developer Platforms

  • Gartner (October 2023): "By 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components and tools for application delivery — up from 45% in 2022." URL: [61] [62][61]
  • Puppet 2023 State of DevOps: Platform Engineering Edition, n=438:

93% report platform team adoption is "a step in the right direction." [63][64] 94% agree platform engineering helps realize benefits of DevOps. [65][64] Pain points: 34% said cycle time is slower than expected; 32% noticed resistance to platform team adoption; 32% cite lack of communication. [65] URL: [66]

  • 93% report platform team adoption is "a step in the right direction." [63][64]
  • 94% agree platform engineering helps realize benefits of DevOps. [65][64]
  • Pain points: 34% said cycle time is slower than expected; 32% noticed resistance to platform team adoption; 32% cite lack of communication. [65]
  • URL: [66]
  • Puppet 2024 State of DevOps, n=~500: "65% report platform team is 'essential and will receive continued investment.'" 52% of respondents think a product manager is "crucial" to platform team success. URL: [67] [68]
  • Humanitec / Gitpod, State of Platform Engineering Vol. 3 (2024), n=281:

"56% of organizations have had platform teams for less than two years; only 13% have been doing PE >5 years." [69] "Only ~9% of respondents were mature by CNCF Platform Maturity Model standards." [69] "45% of platform teams don't measure anything at all; 37% just measure DORA metrics; 43% described feedback mechanisms as 'ad-hoc' or 'inconsistent.'" [69] URL: [70]

  • "56% of organizations have had platform teams for less than two years; only 13% have been doing PE >5 years." [69]
  • "Only ~9% of respondents were mature by CNCF Platform Maturity Model standards." [69]
  • "45% of platform teams don't measure anything at all; 37% just measure DORA metrics; 43% described feedback mechanisms as 'ad-hoc' or 'inconsistent.'" [69]
  • URL: [70]
  • DORA / Accelerate State of DevOps Report 2024 (Google), n=~39,000:

Dedicated platform team → 6% gain in team-level productivity (negligible at individual level). [46] "Internal developer platforms (IDPs) see measurable benefits: 8% higher individual productivity, 10% improved team performance." [71][72] But also: "Potential decreases in throughput (8%) and change stability (14%)" with poorly-implemented platforms. [71][72] URL: [73]; PDF: [74]

  • Dedicated platform team → 6% gain in team-level productivity (negligible at individual level). [46]
  • "Internal developer platforms (IDPs) see measurable benefits: 8% higher individual productivity, 10% improved team performance." [71][72]
  • But also: "Potential decreases in throughput (8%) and change stability (14%)" with poorly-implemented platforms. [71][72]
  • URL: [73]; PDF: [74]
  • CNCF Platform Engineering Survey (2025), n=420: "28% work at orgs with dedicated platform engineering team; 41% have multi-team approach; 31% have no formal approach." URL: [75] [75]

Technical debt

  • Stripe, "The Developer Coefficient" (September 2018):

"Developers spend 17.3 hours/week on maintenance (13.5 hrs on tech debt + 3.8 hrs on bad code)." [76] "42% of developer time lost to tech debt/bad code." [77] Estimated $300B/year lost productivity globally. [78] URL: [76]

  • "Developers spend 17.3 hours/week on maintenance (13.5 hrs on tech debt + 3.8 hrs on bad code)." [76]
  • "42% of developer time lost to tech debt/bad code." [77]
  • Estimated $300B/year lost productivity globally. [78]
  • URL: [76]
  • McKinsey, "Tech debt: Reclaiming tech equity" (October 2020), n=50 CIOs:

"10–20% of technology budget dedicated to new products is diverted to resolving tech debt issues." [79][80] 30% of CIOs surveyed believe more than 20% of new-product budget is diverted to tech debt. [79][81] Tech debt = "20–40% of value of entire technology estate before depreciation." [80] 60% of CIOs said tech debt has risen perceptibly over past three years. [80] URL: [80]

  • "10–20% of technology budget dedicated to new products is diverted to resolving tech debt issues." [79][80]
  • 30% of CIOs surveyed believe more than 20% of new-product budget is diverted to tech debt. [79][81]
  • Tech debt = "20–40% of value of entire technology estate before depreciation." [80]
  • 60% of CIOs said tech debt has risen perceptibly over past three years. [80]
  • URL: [80]
  • McKinsey "Tripped up by tech debt" (June 2023): "Tech debt accounts for approximately 40% of IT balance sheets." [82][83]
  • Stack Overflow Developer Survey 2024, n=65,000+: "62%/63% of professional developers identify technical debt as their #1 frustration at work" — twice the rate of second-place issues. URL: [84] [85]

Security/quality

  • Verizon DBIR 2024 (n=30,458 incidents, 10,626 breaches): "68% of breaches involved a non-malicious human element"; exploitation of vulnerabilities tripled to 14% of all breaches; avg 55 days for orgs to patch 50% of critical vulnerabilities. URL: [86] [87]
  • Shelfware in security — CSO 2020: "50% of security leaders say they don't use all of the features included in their security technologies/services." Respondents report using "only 72% of the security products or services that are either purchased or contracted for use." URL: [88] [88][88]
  • Gartner (via XYPRO): "Nearly 30% of all security investments are underutilized or never implemented — that's over $51 billion." [89]

Why initiatives fail — cause data (this is the most directly relevant data for the LinkedIn post)

  • Prosci Best Practices in Change Management (1998–present, longitudinal benchmark):

"Projects with extremely effective sponsors are 79% likely to meet their objectives compared to just 27% with extremely ineffective sponsors." [90] "An effective executive sponsor can increase a project's chances of achieving its intended business benefits from 25% to 85%." [91] "Nearly 50% of teams rate the effectiveness of their sponsor as poor to fair." [92] "52% of respondents said their sponsors did not have an adequate understanding of their role in change." [93] "Lack of executive support and active sponsorship has been cited as the top obstacle to change management success — in every Prosci benchmark since 1998." [94] Common sponsor failures named explicitly: "sponsor at the wrong level / lacked control over impacted people/systems; sponsor was invisible; sponsor did not build a coalition." [95] URLs: [92]; [90]

  • "Projects with extremely effective sponsors are 79% likely to meet their objectives compared to just 27% with extremely ineffective sponsors." [90]
  • "An effective executive sponsor can increase a project's chances of achieving its intended business benefits from 25% to 85%." [91]
  • "Nearly 50% of teams rate the effectiveness of their sponsor as poor to fair." [92]
  • "52% of respondents said their sponsors did not have an adequate understanding of their role in change." [93]
  • "Lack of executive support and active sponsorship has been cited as the top obstacle to change management success — in every Prosci benchmark since 1998." [94]
  • Common sponsor failures named explicitly: "sponsor at the wrong level / lacked control over impacted people/systems; sponsor was invisible; sponsor did not build a coalition." [95]
  • URLs: [92]; [90]
  • Harvey Nash/KPMG CIO Survey 2017, n=4,500 CIOs: 43% cited resistance to change as the top impediment to a successful digital strategy. [96]
  • Wipro Digital Survey: 35% of executives cited lack of a clear transformation strategy as a key barrier. [96]

3. Principal/Staff Engineer role limitations

Will Larson — Staff Engineer (2021)

Tech Lead — guides approach for one team (partners with a manager). [99] Architect — direction/quality/approach in a critical area; "combines in-depth knowledge of technical constraints, user needs, and organization level leadership." [101][99] Solver — works on arbitrarily complex problems already identified as organizational priorities; "called on to do relatively little org-level chiropractics." [100] Right Hand — "a partner and an extension of an executive-level manager, borrowing their scope and authority to operate particularly complex organizations." [101][100]

  • Tech Lead — guides approach for one team (partners with a manager). [99]
  • Architect — direction/quality/approach in a critical area; "combines in-depth knowledge of technical constraints, user needs, and organization level leadership." [101][99]
  • Solver — works on arbitrarily complex problems already identified as organizational priorities; "called on to do relatively little org-level chiropractics." [100]
  • Right Hand — "a partner and an extension of an executive-level manager, borrowing their scope and authority to operate particularly complex organizations." [101][100]
  • "Stay aligned with authority" (Larson, key quote): "Stay aligned with authority to remain an effective leader over time. Technical leadership roles rely on proxied authority from another (usually, managerial) leader, and continued access to that authority depends on staying aligned, trustworthy, and predictable. To lead, you have to follow." ([102]) [102]
  • On futility of effort without organizational alignment: "Sometimes you'll find work that's worthy of attention but which an organization is incapable of paying attention to, usually because its leadership doesn't value that work… Your early wins will slowly get eroded by indifference and misalignment, and your initial impact will be reclaimed by the sands of time." (Staff Engineer, via Goodreads) [101]
  • "Who Gets to Do Strategy" ([103]): "It is true that executives have more latitude to mandate and cajole participation in the strategies that they sponsor." [103]
  • Stripe Ruby vs. Java case (IC-led strategy failing without enforcement): "the adoption of Ruby versus Java became contentious enough that I distributed a strategy attempting to mediate the disagreement, Magnitudes of exploration, although it wasn't a particularly successful effort (for reasons that are obvious in hindsight, particularly the lack of any enforcement mechanism)." ([104])

Tanya Reilly — The Staff Engineer's Path (O'Reilly, 2022) & "Being Glue"

  • "Being Glue" essay/talk ([105]):

"Every senior person in an organisation should be aware of the less glamorous — and often less-promotable — work that needs to happen to make a team successful. Managed deliberately, glue work demonstrates and builds strong technical leadership skills. Left unconscious, it can be career limiting. It can push people into less technical roles and even out of the industry." [106] "Because I have a title that says I have technical credibility, that's safe for me to do. People assume I can code if I need to… But suppose I did the exact same work, and I didn't have that badge…?" [107]

  • "Every senior person in an organisation should be aware of the less glamorous — and often less-promotable — work that needs to happen to make a team successful. Managed deliberately, glue work demonstrates and builds strong technical leadership skills. Left unconscious, it can be career limiting. It can push people into less technical roles and even out of the industry." [106]
  • "Because I have a title that says I have technical credibility, that's safe for me to do. People assume I can code if I need to… But suppose I did the exact same work, and I didn't have that badge…?" [107]
  • The Staff Engineer's Path — three pillars: The Big Picture, Execution, Leveling Up / Positive Influence. Reilly's summary: "lead through influence rather than authority." ([108]) [109]
  • Reilly on the careful weight of words at staff+: "'Don't think out loud,' my friend Carla Geisser warned me when I became a staff engineer. 'You'll find out a month later that people are talking about your half-baked idea like it's already a project.'" ([110]) [110]

Critiques of "influence without authority" advice

  • Sean Goedecke — "Why I don't like the staff engineer archetypes" ([111]): "The 'solver' and 'right hand' archetypes both rely on having an enormous amount of trust and influence. You can't aim for those archetypes directly, because trust and influence accumulate over time." [111]
  • Alex Ewerlöf — "Staff archetypes can be anti-patterns" ([112]) and "Ivory Tower Architect" ([113]): "Becoming ivory tower is one of the most common pitfalls ahead of Staff+ roles." [113]
  • Ewerlöf on the mandate gap ([114]): "Staff Engineers don't have any mandate over the product (unlike PMs) or engineers (unlike EMs); They arguably have a mandate over technology, but the tech doesn't listen or have an identity without the product. In practice Staff Engineers spend a significant part of their time and energy to collaborate with the engineers and product. The broad organizational scope and lack of formal mandate are the biggest source of confusion." [114]

Charity Majors — engineer/manager pendulum

  • "The Engineer/Manager Pendulum" (May 2017): [115]
  • QCon SF 2022 ([116]): "The best technical leaders in the world are often the ones who do both. Back and forth. Like a pendulum." [115]

Patrick Kua — Trident Model

  • [117] — Three tracks: Management, Technical Leadership, Individual Contributor. "While two tracks are great, I see great problems by calling the second track an IC track because it overemphasises the idea of individual contribution, when most organisations want and need technical leadership." [118]

Camille Fournier — The Manager's Path (2017) — the single most on-point quote for this topic

  • Goodreads excerpts: [119]
  • "You're a leader with no power over business strategy and no ability to allocate people to important tasks, you're at best at the mercy of your influence with other executives and managers, and at worst a figurehead. You can't give up the responsibility of management without giving up the power that comes with it. The CTO who doesn't also have the authority of management must be able to get things done purely by influencing the organization. If the managers won't actually give people and time to work on the areas that the CTO believes are important, he is rendered effectively powerless." [120][121]
  • "My advice for aspiring CTOs is to remember that it's a business strategy job first and foremost. It's also a management job." [120]
  • Fournier's Platform Engineering (with Ian Nowland, O'Reilly 2024) addresses the same problem at the platform level — platform teams must operate "platform-as-product" because they lack authority to mandate adoption: [122] [123][124]

Gergely Orosz — The Pragmatic Engineer

  • On Staff/Principal ambiguity: "Promotions to Staff within the company are more challenging than they are up to the Senior level. Up to the Senior level, expectations are usually clear, as are promotion paths. Beyond Senior, there is a lot more ambiguity on what output and behaviors are expected to get to the next level." ([125]) [125]
  • On title inflation: "A principal engineer having an impact radius of 100 engineers at Skyscanner might map to a staff-level at Uber, but very likely not to Uber's principal level, which can be expected to have an impact radius in the numbers of thousands of engineers across the company." ([126]) [126]

Marty Cagan — Empowered (2020)

  • "An engineer that cares just as much about what they build as how they build it." ([127]) [128]
  • "If I had to pick just one concept from this entire book… it would be the idea of an empowered engineer." (Empowered) [129]

4. Architecture Review Boards (ARBs) and their failures

Gregor Hohpe — "The Architect Elevator"

  • Book: Hohpe, G. (2020). The Software Architect Elevator. O'Reilly. [130]
  • The metaphor (Hohpe, hosted on Fowler's site, [131]): "Many large organizations see their IT engine separated by many floors from the executive penthouse, which also separates business and digital strategy from the vital work of carrying it out. The primary role of an architect is to ride the elevators between the penthouse and engine room, stopping wherever is needed to support these digital efforts." [132]
  • The canonical ivory-tower critique (same source): "A well-known architecture department anti-pattern is the 'ivory tower': architects sit in the penthouse to define how developers should design and build software, without developing any software themselves. Such a setup has one cardinal flaw: it doesn't provide feedback to the architects as to the effectiveness nor the cost of their decisions. Worse yet: some architects quite enjoy themselves not having to deal with those consequences." [131]
  • PowerPoint architecture (GOTO Berlin 2014): "In many companies and communities the title 'architect' has become associated with negative connotations: architects are the people who live in the ivory tower, are out of touch with reality, and make poor decisions driven by the quest for irrelevant technical ideals. Because these architects can't code, they bestow their thoughts upon developers with PowerPoint slides and wall-sized posters." [133] [133][133]
  • Hohpe's Law: "Excessive complexity is nature's punishment for organizations that are unable to make decisions." [134]
  • On middle-management as gatekeeper: "Sometimes people (in large organizations) perceive a divide between the 'engine room' and 'upper management', due to lack of mutual understanding… middle management occasionally benefits from the divide, becoming a gatekeeper and potential bottleneck." ([135]) [135]

Martin Fowler — "Who Needs an Architect?" (IEEE Software, 2003)

  • Source: [136]
  • Two archetypes: Architectus Reloadus (the bottleneck architect who makes all decisions because they don't think the team is capable) vs. Architectus Oryzus (collaborative, mentoring, embedded). "An architect's value is inversely proportional to the number of decisions they make." [137][138]

Why traditional ARBs fail

  • Bo Vincent Thomsen, "No more Architecture Review Boards, please?" [139]: "ARBs encourage excessive documentation… ARBs don't really work well with traditional project management as architects are routinely overruled by Project Managers. ARBs are also against both Lean (flow) and Agile (autonomy) principles." [139][139]
  • AWS Architecture Blog ("Build and operate an effective ARB"): implicitly concedes the bypass problem — "The executive sponsor helps embed the ARB function within the enterprise's project implementation process. Supported by the executive sponsor, the ARB's reviews serve as a formal gate within the project process, reducing attempts to bypass the review processes." Without executive backing, ARBs are routinely bypassed. [140] [140]
  • TOGAF (Open Group): "In many companies that fail in an architecture planning effort, there is a notable lack of executive participation and encouragement for the project." [141] [141]
  • SAP LeanIX: "Critics of enterprise architecture often call it an 'ivory tower exercise' that is too far separated from the everyday activities of your organization to be of any real, practical use." [142] [142]

Joel Spolsky — "Architecture astronauts" (April 21, 2001)

  • "Don't Let Architecture Astronauts Scare You" (Joel on Software; reprinted in Joel on Software book, Apress 2004, Chapter 14): "When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all. These are the people I call Architecture Astronauts… It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture. They're astronauts because they are above the oxygen level, I don't know how they're breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don't contribute to the bottom line." [143] [144][145]
  • John Carmack (Oculus CTO, 2021) called the metaverse "a honeypot trap for architecture astronauts." ([146]) [146]

Alternative governance: Architecture Decision Records (ADRs)

  • Coined by Michael Nygard, Release It! (2007) and his 2011 post "Documenting Architecture Decisions": "One of the hardest things to track during the life of a project is the motivation behind certain decisions." [147]
  • ThoughtWorks Technology Radar moved ADRs to "Adopt" in 2018. [148] [148]
  • Canonical ADR fields: Title, Status, Context, Decision, Consequences. [149] [150]
  • ADRs are explicitly federated/decentralised — anyone or any team can make architectural decisions — which is itself a critique of centralized ARB authority.

5. Organizational design and Conway's Law

Conway's Law — original

  • Conway, M. (1968). "How Do Committees Invent?" Datamation, April 1968. (HBR rejected it.)
  • Exact quote ([151]): "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." [151][152]
  • Brooks named it "Conway's Law" in The Mythical Man-Month (1975). [153]
  • Empirical validation: MacCormack, Rusnak & Baldwin (HBS, March 2008), "Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis."

Inverse Conway Maneuver

  • Coined by Jonny LeRoy and Matt Simons (ThoughtWorks), Cutter IT Journal, December 2010. (Confirmed by Fowler: [152]) [152]
  • ThoughtWorks Tech Radar: "The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture." [154] [155]
  • Critique on cost of reorgs: "Reorgs — and the uncertainty they provoke about the future — can cause greater stress and anxiety than layoffs, leading in about 60% of cases to noticeably reduced productivity." (HBR, [156]) [157]

Team Topologies (Skelton & Pais, 2019)

  • Source: [158]; Fowler summary: [159]
  • Four team types:

Stream-aligned team — the dominant type; aligned to a single valuable stream of work; "empowered to build and deliver value quickly, safely, and (this is key) independently." Platform team — "enables a stream-aligned team to deliver work with substantial autonomy by providing internal services to reduce their cognitive load." Quotes Evan Bottcher: a platform is "a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product." [160][160] Enabling team — temporary, coaching-only; "isn't there to write and ensure conformance to standards, but instead to educate and coach their colleagues so that the stream-aligned teams become more autonomous." Typically 5–15% of org. Note: enabling teams explicitly have no enforcement authority — this is the formalized "influence-only" model. [159] Complicated-subsystem team — deep expertise (e.g., PhD-level math).

  • Stream-aligned team — the dominant type; aligned to a single valuable stream of work; "empowered to build and deliver value quickly, safely, and (this is key) independently."
  • Platform team — "enables a stream-aligned team to deliver work with substantial autonomy by providing internal services to reduce their cognitive load." Quotes Evan Bottcher: a platform is "a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product." [160][160]
  • Enabling team — temporary, coaching-only; "isn't there to write and ensure conformance to standards, but instead to educate and coach their colleagues so that the stream-aligned teams become more autonomous." Typically 5–15% of org. Note: enabling teams explicitly have no enforcement authority — this is the formalized "influence-only" model. [159]
  • Complicated-subsystem team — deep expertise (e.g., PhD-level math).
  • Three interaction modes: Collaboration, X-as-a-Service, Facilitating.

Reporting structure determines decisions

  • Will Larson: "There are, unfortunately, few public examples of this sort of engineering vision. The closest you can get is to infer a company's vision from its organizational chart, which also implicitly reflects its technical architecture." ([161])
  • Larson on default strategy: "While I frequently hear engineers bemoan a missing strategy… there's always an engineering strategy, even if there's nothing written down." ([104]) Decisions happen — just at VP/Director level by default.

6. Consulting parallel — "decks in drawers"

Implementation rates of consulting recommendations

  • McKinsey's own framing (rationale for "McKinsey Implementation" practice): "Diagnosing the specific barriers to successful implementation and delivering targeted interventions that transform business models are critical for sustaining lasting impact." Implicitly acknowledges recommendations don't implement themselves. [162] [162]
  • Turner (1982 HBR): "Much of this money pays for impractical data and poorly implemented recommendations. To reduce this waste, clients need a better understanding of what consulting assignments can accomplish." [32] [32]
  • Baxter Neumann analysis of typical pattern: "The failure to implement and achieve any results was the division manager's problem, so the consulting firm — which was paid a very large fee for this work — was off the hook." [163] [163]
  • Quora insider (anecdotal): "It's well understood at firms that most clients don't follow advice consultants give them. The times the recommendations are adopted are infrequent enough that they're brought up as the unusual cases." [164] [164]

The Gervais Principle — Venkatesh Rao (2009–2013)

  • Rao, V. (2013). The Gervais Principle. Originally serialized at Ribbonfarm. [165]
  • Core statement: "Sociopaths, in their own best interests, knowingly promote over-performing Losers into middle-management, groom under-performing Losers into Sociopaths, and leave the average bare-minimum-effort Losers to fend for themselves." [166]
  • Four languages: Powertalk (Sociopath in-group; "with every word uttered, the power equation between the two speakers shifts just a little"); Posturetalk (Clueless to everyone); Babytalk; Gametalk. [167][167]
  • Relevance: Clueless middle managers accept consulting decks (and IC strategy decks) as substance; Sociopath executives use them as legitimation cover.

"Shelfware" / "decks in drawers"

  • Wikipedia "Shelfware": "Shelfware at one time referred to binders of unused documentation and at present refers to unused software… It also refers to security and other policies and procedures that fill an 'array of binders' collecting dust… Some of these documents were not even for implemented software, but for planning of projects that were 'shelved' (not implemented)." Earlier IBM term: "binderware." [168] [168][168]
  • Devoteam: "Ultimately, the way a data product is implemented helps determine whether it becomes a driver of growth or just another piece of shelfware." [169] [169]

Matthew Stewart — The Management Myth (2009)

  • Stewart, M. (2009). The Management Myth: Why the Experts Keep Getting It Wrong. W. W. Norton. [170]
  • "If you're working for somebody and trying to check on them, it never works. You're just saying what they want you to say at the end of the day. Whoever pays the consultant gets pretty much what they want to hear." (CBS News interview) [171]
  • "Our initial work was good and helpful… and then in the manner typical of many consulting projects, it became less functional, maybe a little dysfunctional. Our objective was, as always, to bill them at a maximum rate, so we tried to figure out ways to stay around as long as possible, rather than helping the clients get on their feet." [171]

Christopher McKenna — The World's Newest Profession (2006)

  • McKenna, C. D. (2006). The World's Newest Profession: Management Consulting in the Twentieth Century. Cambridge UP. [172]
  • Key thesis: Consultants gain influence not through credentialing (no license required) but through "institutional isomorphism" and legitimation — firms hire McKinsey not because they need answers but because using McKinsey legitimizes decisions internally and externally.

Mazzucato & Collington — The Big Con (2023)

  • Penguin Press, 2023. [173]
  • "Consultancies perform a 'confidence trick', overselling their value to potential clients in the absence of specific expertise." [174])
  • "When [a government] 'outsources its brains,' its capabilities hollow out, and it is less and less able to manage challenges." — Mazzucato. The authors call this dynamic "infantilization." [175][175]

Martin Kihn — House of Lies (2005)

  • Publishers Weekly: "Kihn argues that many consultants know little or nothing about the firms they're hired to help; furthermore, he contends, they often offer companies information that companies already have. For him, the consulting industry is a shell game, imparting an air of authority and expertise rather than actual authority and expertise." [176] [176]

7. What actually works

Amazon — Two-pizza teams + Single-Threaded Leaders/Owners (STL/STO)

  • Source: Colin Bryar & Bill Carr, Working Backwards (2021). [177]
  • "Single-threaded leadership is the most critical organizational design concept at Amazon. It has been instrumental in avoiding coupling and slow velocity while increasing the number of initiatives that Amazon can run in parallel."
  • Two variants: STO (single-threaded ownership) where leader controls all resources and reporting; STL (single-threaded leadership) where leader has prioritization authority but functional reporting remains. [178]
  • Bezos rationale (via Bill Carr): "The best way to fail at inventing something is by making it somebody's part-time job."
  • Jeff Wilke (former CEO Worldwide Consumer): the STL "does not have to get up in the morning and worry about anything other than the thing they are charged to succeed at." [179] [179]
  • Alexa was reorganized into two-pizza teams each led by an STL with "ultimate control and absolute accountability." — note this is positional authority, not influence-only. [180]

Spotify model — and the canonical critique

  • Origin: Kniberg & Ivarsson, "Scaling Agile @ Spotify" (2012 whitepaper). [181]
  • Kniberg himself: "This is not a recipe. It is a snapshot of what we are doing right now."
  • Jeremiah Lee (former Spotify PM), "Spotify's Failed Squad Goals" (2020): Autonomous squads created coordination/fragmentation problems; Chapter Lead role was structurally fragile (split between management and delivery); tribal boundaries became silos; culture was not transferable. [182]
  • Anders Ivarsson (co-author of original whitepaper): "It worries me when people look at what we do and think it's a framework they can just copy and implement."

Netflix — "Context not control"

  • Netflix culture: "We expect managers to practice context not control — giving their teams the context and clarity needed to make good decisions instead of trying to control everything themselves." [183] [183]
  • Book: Hastings & Meyer, No Rules Rules (2020) — "Lead with context, not control." [184]

"Paved roads" (Netflix) and "Golden paths" (Spotify)

  • Netflix Paved Road: Curated, supported toolchain; engineers may go off-road but lose support. "Scaling Appsec at Netflix": [185]
  • Spotify Golden Path (originally Hack Week ~2014; Spotify Engineering blog): "This is the way we support an easy and streamlined way of working. If you are an adventurer you can of course leave the Golden Path and do your own thing, but then you will not have the same support." Name borrowed from Frank Herbert's Children of Dune. [186] [186][187]
  • Before golden paths (Spotify PM Gary Nieman): Spotify suffered from "rumour-driven development" — "the only way to find out how to do something was to ask your colleague."
  • "Paved roads with teeth": Industry slang for paved roads with mandatory enforcement levers (tool defaults, build-system gates, security/compliance enforcement). Netflix's Wall-E platform: "It made following security best practices the default, not a checklist." [188]

Will Larson on engineering strategy

  • Defines engineering strategy as "honest diagnosis + practical approach" (Rumelt's Good Strategy/Bad Strategy).
  • Three artifacts: vision (2–3 yr target), strategy (tradeoff guidance), technical specifications.
  • On policy enforcement (Calm engineering strategy example): "Exceptions are granted by the CTO, and must be in writing." — Larson explicitly links strategy to authority. [189]
  • Capacity allocation example: strategy allocates 45% b2b, 35% consumer, 10% bets, 10% to developer productivity — explicit budget reservation for platform/cross-cutting work. [190]

Empowered teams and platform-as-product

  • Camille Fournier & Ian Nowland, Platform Engineering (O'Reilly 2024): Platforms must adopt "platform-as-product, developer-centric mindset" because platform teams lack authority to mandate adoption. They must earn adoption. [123][123]
  • Marty Cagan (SVPG): "Are you staffed with competent people with character… Are you assigned problems to solve, rather than given lists of features to build? Are you accountable to deliver business results (outcomes) rather than shipping features (output)?" [127] [127]

8. Named patterns and anti-patterns

Anti-patternCoiner / OriginKey reference
Ivory tower architectureHohpe (canonical articulation)[131]
Architecture astronautsJoel Spolsky, April 2001[191]
PowerPoint architecture / deck-wareHohpe (GOTO Berlin 2014); no single canonical coinage[133]
Responsibility without authority / NAG syndromeVictor Sang Tng (2013); Paton/ELG[22]
Seagull managementKen Blanchard,Leadership and the One Minute Manager(1985)"Seagull managers fly in, make a lot of noise, dump on everyone, then fly out."Definitions.netFindwords[192]
HiPPO (Highest Paid Person's Opinion)Avinash Kaushik,Web Analytics: An Hour a Day(2007);Property Weekearlier "HiPO" Dylan Lewis/Intuit; Ronny Kohavi added second P at MicrosoftLinkedIn[193]
Frozen middleAttributed to Roger Smith (GM CEO, 1980s);M100groupJonathan Byrnes (MIT, 2005)Agile Velocity[194]
Big Ball of MudFoote & Yoder, 1997[195]
Cargo Cult Spotify ModelApplying labels (squad/tribe/chapter/guild) without cultural changes[196]
Rumour-driven developmentSpotify internal[197]
Architectus Reloadus(bottleneck architect) vs Architectus OryzusMartin Fowler, IEEE Software 2003[136]
  • HBR counter-framing on the frozen middle — Behnam Tabrizi, "The Key to Change Is Middle Management" (HBR 2014): middle managers are change leaders if engaged correctly. [198] [199]

9. Specific statistics to quote (most useful for a LinkedIn post)

On who drives change:

  • Prosci: Effective sponsorship raises success from 27% → 79%; can lift project success from 25% → 85%. Lack of executive sponsorship is the #1 obstacle to change in every Prosci benchmark since 1998. "52% of respondents said their sponsors did not have an adequate understanding of their role in change." [90]
  • McKinsey: "Among transformations that fail to engage either line managers or frontline employees, only 3% report success." [39]

On initiative failure rates:

  • McKinsey: Only 16% of digital transformations succeed and sustain; in traditional industries, just 4–11%. [35]
  • BCG: 30% of transformations succeed; rises to 80% with six factors in place. [40][40]
  • Bain (2024): 88% of transformations fail original ambitions; 90% of value created by <5% of roles. [44]
  • RAND (2024): >80% of AI projects fail — 2× the failure rate of non-AI IT projects. [49]
  • MIT NANDA (2025): 95% of GenAI pilots delivered no measurable P&L impact. [51]
  • Gartner: 30% of GenAI projects abandoned after POC by end-2025. [54][59]
  • Verizon/CSO: 30% of security investments underutilized or never implemented ($51B).

On developer experience and tech debt:

  • McKinsey: Tech debt = 20–40% of tech estate value; CIOs divert 10–20% of new-product budget to tech debt. [80]
  • Stripe: 42% of developer time lost to maintenance/bad code. [77]
  • Stack Overflow 2024 (n=65,000+): 62% cite tech debt as #1 frustration. [200]

On platform engineering:

  • Gartner: 80% of large engineering orgs to have platform teams by 2026 (up from 45% in 2022). [62][61]
  • Puppet 2024: Only 65% rate platform team as "essential." [68][201]
  • DORA 2024: Platforms produce only ~6% team productivity gain, with 8% throughput and 14% stability decreases when poorly implemented. [46]
  • Humanitec: Only ~9% of platform teams are mature by CNCF Platform Maturity Model; 45% don't measure anything. [69]

On influence tactics (academic):

  • Yukl & Tracey (1992): Rational persuasion, inspirational appeal, and consultation are most effective. Pressure, coalition, and legitimating are least effective. [8][6]
  • Lee et al. (2017) meta-analysis (N=8,987): Only rational persuasion held positive relationships with outcomes across all moderating factors. [8]

10. Cross-cutting synthesis (factual, for the writer's reference)

Author / SourceOne-line position
Fournier (Manager's Path)A CTO without managerial authority is "effectively powerless"; you can't give up management responsibility without giving up the power.
Larson (Staff Engineer / staffeng.com)Staff engineer authority isproxied/borrowedfrom a manager-sponsor; "to lead, you have to follow." Stripe Ruby/Java strategy failed for "lack of any enforcement mechanism."
Reilly (Staff Engineer's Path/ "Being Glue")Lead throughinfluence, not authority— but warns this work is career-limiting without explicit recognition.
Hohpe (Architect Elevator)Architects mustride the elevatorbetween penthouse and engine room; ivory-tower architecture is the cardinal anti-pattern.
Fowler ("Who Needs an Architect?")Best architects empower teams; "an architect's value is inversely proportional to the number of decisions they make."Medium
Majors (engineer/manager pendulum)Reject the binary — oscillate between IC and management to maintain both credibility and authority.
Kua (Trident Model)Three tracks needed; calling tech leadership "IC" misrepresents — it requires leadership skills, not pure individual contribution.patkua.com
Hogan (Resilient Management)Sponsorship(not mentorship) is what actually moves careers; sponsors have authority to give career-launching work.Pat Hermens
HightowerAdoption (not mandate) defines platform success; "software is a fashion industry" — taste/influence over command.
Cagan (Empowered)Authority should be pushed down to teams viaproblem-assignment, not feature-assignment.
Pfeffer (Managing With Power)"A decision by itself changes nothing… problems of implementation are really issues of power." Chooseline over staffpositions for direct resource control.
Cohen & Bradford (Influence Without Authority)The exchange model presumes the counterparty values something the influencer can provide — fails when staff engineers lack any tradeable currency.
Beer & Eisenstat (Sloan 2000)Six "silent killers" —poor cross-functional coordinationand weak line leadership are the most cross-cutting strategy killers.
Conway (1968)Organizations produce designs that mirror theircommunication structure— so the org chart silently determines technical strategy.
Skelton & Pais (Team Topologies)Enabling teams are formalized "influence-only" — temporary coaches with no enforcement; only platform teams have persistent capacity.

Key thread for the LinkedIn post (factual frame)

Three concurrent and converging findings: (1) Empirically, expert/rational influence outperforms positional power in compliance research — supporting the case for senior IC roles — but (2) expert power is bounded to specific technical domains and depends on a counterparty motivated by the expertise; (3) implementation requires resource control, which sits at managerial/executive levels. The structural gap is well-documented across academic management literature (Mintzberg, Pfeffer, Cohen-Bradford), management practice critique (Beer-Eisenstat, Prosci), engineering thought leadership (Fournier, Larson, Reilly, Hohpe), industry survey data (McKinsey/BCG/Bain/RAND/MIT/Gartner/DORA/Puppet/Humanitec/Stack Overflow), and the consulting parallel (Stewart, McKenna, Mazzucato/Collington, Turner HBR 1982).

Source-quality caveats

  • The "70% of change initiatives fail" figure is widely cited but empirically contested (Hughes, 2011).
  • "Gartner 85% of AI projects fail" is widely repeated but the original press release URL is no longer prominent.
  • The "Failed Spotify Model" critique (Jeremiah Lee) is single-perspective but widely corroborated; no peer-reviewed evaluation of the Spotify model exists.
  • The "frozen middle" attribution to Roger Smith is not directly quotable from primary sources; Byrnes (2005) is the earliest written articulation found.
  • "PowerPoint architecture" / "deck-ware" has no single authoritative coinage but Hohpe's 2014 phrasing is the most-cited.
  • The NAG-syndrome "500 PM" study referenced by ELG could not be traced to a peer-reviewed primary source — treat as practitioner claim.
  • Mintzberg's Power In and Around Organizations (1983) is out of print but free from the author at mintzberg.org.
  1. http://www.communicationcache.com/uploads/1/0/8/8/10887248/the_bases_of_social_power_-_chapter_20_-_1959.pdf — http://www.communicationcache.com/uploads/1/0/8/8/10887248/the_bases_of_social_power_-_chapter_20_-_1959.pdf
  2. Wikipedia — https://en.wikipedia.org/wiki/French_and_Raven's_bases_of_power
  3. https://scholar.valpo.edu/cgi/viewcontent.cgi?article=1312&context=jvbl — https://scholar.valpo.edu/cgi/viewcontent.cgi?article=1312&context=jvbl
  4. https://sites.psu.edu/aspsy/2024/10/09/five-bases-of-power/ — https://sites.psu.edu/aspsy/2024/10/09/five-bases-of-power/
  5. https://www.leadingsapiens.com/types-of-power-in-leadership/ — https://www.leadingsapiens.com/types-of-power-in-leadership/
  6. https://www.studocu.com/en-gb/document/university-of-surrey/business-ethics/falbe-yukl-influencing-tactics/27176465 — https://www.studocu.com/en-gb/document/university-of-surrey/business-ethics/falbe-yukl-influencing-tactics/27176465
  7. https://ojs.tnkul.pl/index.php/rpsych/article/download/9573/15184/ — https://ojs.tnkul.pl/index.php/rpsych/article/download/9573/15184/
  8. ScienceDirect — https://www.sciencedirect.com/science/article/abs/pii/S1048984316301655
  9. https://mintzberg.org/books/power-and-around-organizations — https://mintzberg.org/books/power-and-around-organizations
  10. GRIN — https://www.grin.com/document/8550
  11. https://blogs.stthom.edu/cameron/expert-power-information-technology-specialists/ — https://blogs.stthom.edu/cameron/expert-power-information-technology-specialists/
  12. https://archive.org/details/managingwithpowe00pfef — https://archive.org/details/managingwithpowe00pfef
  13. https://jeffreypfeffer.com/books/power-why-some-people-have-it-and-others-dont/ — https://jeffreypfeffer.com/books/power-why-some-people-have-it-and-others-dont/
  14. Goodreads — https://www.goodreads.com/book/show/198363.Managing_With_Power
  15. https://www.tosummarise.com/book-summary-power-by-jeffrey-pfeffer/ — https://www.tosummarise.com/book-summary-power-by-jeffrey-pfeffer/
  16. https://en.wikipedia.org/wiki/Resource_dependence_theory — https://en.wikipedia.org/wiki/Resource_dependence_theory
  17. ResearchGate — https://www.researchgate.net/publication/355155423_Resource-Dependence_Theory
  18. https://www.amazon.com/Influence-Without-Authority-Allan-Cohen/dp/0471463302 — https://www.amazon.com/Influence-Without-Authority-Allan-Cohen/dp/0471463302
  19. Academia.edu — https://www.academia.edu/93116291/Influence_without_authority
  20. https://maa1.medium.com/book-review-influence-without-authority-b7a9a9dcca24 — https://maa1.medium.com/book-review-influence-without-authority-b7a9a9dcca24
  21. Goodreads — https://www.goodreads.com/book/show/123686.Influence_Without_Authority
  22. https://www.elg.net/2015/04/accountability-authority-drive-employees-crazy/ — https://www.elg.net/2015/04/accountability-authority-drive-employees-crazy/
  23. LinkedIn — https://www.linkedin.com/pulse/responsibility-without-authority-how-drive-employees-crazy-fialka
  24. https://victoronbusiness.com/2013/05/20/responsibility-without-authority-the-worst-thing-in-management/ — https://victoronbusiness.com/2013/05/20/responsibility-without-authority-the-worst-thing-in-management/
  25. https://www.chronicle.com/article/life-as-a-middle-manager-responsibility-without-authority — https://www.chronicle.com/article/life-as-a-middle-manager-responsibility-without-authority
  26. https://invitingleadership.com/chapters/delegation/ — https://invitingleadership.com/chapters/delegation/
  27. https://medium.com/snapp-mobile/stakeholder-anti-patterns-b8a839a39a78 — https://medium.com/snapp-mobile/stakeholder-anti-patterns-b8a839a39a78
  28. https://sloanreview.mit.edu/article/the-silent-killers-of-strategy-implementation-and-learning/ — https://sloanreview.mit.edu/article/the-silent-killers-of-strategy-implementation-and-learning/
  29. Davidsonwp — https://www.davidsonwp.com/six-silent-killers-of-strategy-implementation
  30. https://hbr.org/podcast/2021/03/building-influence-without-authority — https://hbr.org/podcast/2021/03/building-influence-without-authority
  31. https://hbsp.harvard.edu/product/U0312E-PDF-ENG — https://hbsp.harvard.edu/product/U0312E-PDF-ENG
  32. https://hbr.org/1982/09/consulting-is-more-than-giving-advice — https://hbr.org/1982/09/consulting-is-more-than-giving-advice
  33. https://www.mckinsey.com/capabilities/transformation/our-insights/perspectives-on-transformation — https://www.mckinsey.com/capabilities/transformation/our-insights/perspectives-on-transformation
  34. Brainhub — https://brainhub.eu/library/why-do-digital-transformations-fail
  35. Bytzgroup — https://bytzgroup.com/2020/05/14/unlocking-success-in-digital-transformations/
  36. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/unlocking-success-in-digital-transformations — https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/unlocking-success-in-digital-transformations
  37. Brandknewmag — https://www.brandknewmag.com/losing-from-day-one-why-even-successful-transformations-fall-short/
  38. TechTarget — https://www.techtarget.com/searchcio/tip/Top-6-reasons-why-digital-transformation-failures-happen
  39. McKinsey & Company — https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/successful-transformations
  40. PR Newswire — https://www.prnewswire.com/news-releases/companies-can-flip-the-odds-of-success-in-digital-transformations-from-30-to-80-301162310.html
  41. StrategyU — https://strategyu.co/do-70-percent-of-change-initiatives-really-fail/
  42. https://www.bcg.com/publications/2020/increasing-odds-of-success-in-digital-transformation — https://www.bcg.com/publications/2020/increasing-odds-of-success-in-digital-transformation
  43. https://web-assets.bcg.com/c7/20/907821344bbb8ade98cbe10fc2b8/bcg-flipping-the-odds-of-digital-transformation-success-oct-2020.pdf — https://web-assets.bcg.com/c7/20/907821344bbb8ade98cbe10fc2b8/bcg-flipping-the-odds-of-digital-transformation-success-oct-2020.pdf
  44. Bain & Company +2 — https://www.bain.com/about/media-center/press-releases/2024/88-of-business-transformations-fail-to-achieve-their-original-ambitions-those-that-succeed-avoid-overloading-top-talent/
  45. Bain & Company — https://www.bain.com/insights/the-three-common-transformation-talent-mistakes-and-how-to-avoid-them/
  46. Middlewarehq — https://middlewarehq.com/blog/the-2024-dora-report-summary-by-middleware
  47. https://www.researchgate.net/publication/233202794 — https://www.researchgate.net/publication/233202794
  48. https://www.projectmanagement.com/blog-post/7112/time-to-kill-the-phantom-70--failure-rate- — https://www.projectmanagement.com/blog-post/7112/time-to-kill-the-phantom-70--failure-rate-
  49. RAND — https://www.rand.org/pubs/research_reports/RRA2680-1.html
  50. https://www.rand.org/content/dam/rand/pubs/research_reports/RRA2600/RRA2680-1/RAND_RRA2680-1.pdf — https://www.rand.org/content/dam/rand/pubs/research_reports/RRA2600/RRA2680-1/RAND_RRA2680-1.pdf
  51. Legal.io — https://www.legal.io/articles/5719519/MIT-Report-Finds-95-of-AI-Pilots-Fail-to-Deliver-ROI-Exposing-GenAI-Divide
  52. Yahoo Finance — https://finance.yahoo.com/news/mit-report-95-generative-ai-105412686.html
  53. https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/ — https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/
  54. https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025 — https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025
  55. HPCwire + 2 — https://www.hpcwire.com/bigdatawire/this-just-in/gartner-predicts-30-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025/
  56. Myplanb — https://myplanb.ai/why-85-of-ai-projects-fail/
  57. Talyx AI — https://talyx.ai/insights/enterprise-ai-implementation-failure
  58. Quicklaunchanalytics — https://quicklaunchanalytics.com/bi-blog/why-80-of-ai-projects-fail-before-they-start-its-your-data-foundation/
  59. Quest Blog — https://blog.quest.com/the-hidden-ai-tax-why-theres-an-80-ai-project-failure-rate/
  60. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value — https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value
  61. https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering — https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering
  62. Salesforcedevops — https://salesforcedevops.net/index.php/2024/04/03/puppet-2024-state-of-devops-report/
  63. Perforce — https://www.perforce.com/press-releases/2023-state-devops-report
  64. Mesaonline — https://www.mesaonline.org/2023/01/19/2023-state-of-devops-report-finds-platform-engineering-unlocks-devops-success-in-the-enterprise/
  65. DevOps — https://devops.com/state-of-devops-report-finds-a-rise-in-platform-engineering/
  66. https://www.puppet.com/resources/state-of-devops-report — https://www.puppet.com/resources/state-of-devops-report
  67. https://www.puppet.com/resources/state-of-platform-engineering — https://www.puppet.com/resources/state-of-platform-engineering
  68. DevPro Journal + 2 — https://www.devprojournal.com/news/puppets-2024-state-of-devops-report-reveals-security-is-strengthened-by-platform-engineering/
  69. The New Stack — https://thenewstack.io/the-2024-state-of-platform-engineering-fledgling-at-best/
  70. https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-3 — https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-3
  71. Upsun — https://upsun.com/blog/insights-from-the-devops-dora-annual-report/
  72. Libertify — https://www.libertify.com/interactive-library/state-of-devops-2024-dora/
  73. https://dora.dev/research/2024/dora-report/ — https://dora.dev/research/2024/dora-report/
  74. https://services.google.com/fh/files/misc/2024_final_dora_report.pdf — https://services.google.com/fh/files/misc/2024_final_dora_report.pdf
  75. https://platformengineering.com/features/cncf-survey-surfaces-little-platform-engineering-consensus/ — https://platformengineering.com/features/cncf-survey-surfaces-little-platform-engineering-consensus/
  76. Stripe — https://stripe.com/files/reports/the-developer-coefficient.pdf
  77. Who is Nnamdi? — https://whoisnnamdi.com/leaving-software-on-the-table/
  78. Stripe — https://stripe.com/reports/developer-coefficient-2018
  79. Function4 — https://function-4.com/what-is-technical-debt-2026-it-budget-guide/
  80. McKinsey & Company — https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity
  81. byteiota — https://byteiota.com/technical-debt-costs-40-of-it-budgets-in-2025-the-3m-crisis/
  82. FlagShark — https://flagshark.com/learn/cost-of-stale-flags/
  83. McKinsey & Company — https://www.mckinsey.com/featured-insights/sustainable-inclusive-growth/charts/tripped-up-by-tech-debt
  84. https://survey.stackoverflow.co/2024/professional-developers — https://survey.stackoverflow.co/2024/professional-developers
  85. Onymos — https://onymos.com/blog/highlights-from-the-2024-stack-overflow-dev-survey/
  86. https://www.verizon.com/business/resources/reports/dbir.html — https://www.verizon.com/business/resources/reports/dbir.html
  87. Verizon + 2 — https://www.verizon.com/about/news/2024-data-breach-investigations-report-vulnerability-exploitation-boom
  88. https://www.csoonline.com/article/570333/inside-cybersecurity-s-shelfware-problem.html — https://www.csoonline.com/article/570333/inside-cybersecurity-s-shelfware-problem.html
  89. Xypro — https://xypro.com/secure-database-management/the-rise-of-shelfware-software-and-how-to-make-it-stop/
  90. Prosci — https://www.prosci.com/change-management-success
  91. Prosci — https://www.prosci.com/blog/how-is-effective-change-sponsorship-different-to-leadership
  92. Prosci — https://www.prosci.com/blog/3-reasons-executives-fail-at-sponsorship
  93. Prosci — https://www.prosci.com/resources/articles/sponsor-checklist-for-change-management
  94. Prosci — https://www.prosci.com/blog/how-to-prevent-the-missing-sponsor
  95. Prosci — https://blog.prosci.com/do-you-have-authority-on-your-side
  96. Cloudbursttechnologies — https://cloudbursttechnologies.com/12-reasons-why-digital-transformations-fail/
  97. https://staffeng.com — https://staffeng.com
  98. https://lethain.com — https://lethain.com
  99. https://staffeng.com/guides/staff-archetypes/ — https://staffeng.com/guides/staff-archetypes/
  100. https://lethain.com/staff-engineer-archetypes/ — https://lethain.com/staff-engineer-archetypes/
  101. Goodreads — https://www.goodreads.com/work/quotes/88125716-staff-engineer-leadership-beyond-the-management-track
  102. https://staffeng.com/guides/operating-at-staff/ — https://staffeng.com/guides/operating-at-staff/
  103. https://lethain.com/who-gets-to-do-strategy/ — https://lethain.com/who-gets-to-do-strategy/
  104. https://lethain.com/is-engineering-strategy-useful/ — https://lethain.com/is-engineering-strategy-useful/
  105. https://www.noidea.dog/glue — https://www.noidea.dog/glue
  106. My part of the web — https://blog.carno.pl/posts/being-glue/
  107. Slideshare — https://www.slideshare.net/slideshow/being-glue/108425125
  108. https://www.oreilly.com/library/view/the-staff-engineers/9781098118723/ — https://www.oreilly.com/library/view/the-staff-engineers/9781098118723/
  109. Scribd + 2 — https://www.scribd.com/document/884749446/The-Staff-Engineer-s-Path-PDF
  110. https://newsletter.pragmaticengineer.com/p/the-staff-engineers-path — https://newsletter.pragmaticengineer.com/p/the-staff-engineers-path
  111. https://www.seangoedecke.com/staff-engineer-archetypes/ — https://www.seangoedecke.com/staff-engineer-archetypes/
  112. https://blog.alexewerlof.com/p/staff-archetypes-are-anti-patterns — https://blog.alexewerlof.com/p/staff-archetypes-are-anti-patterns
  113. https://blog.alexewerlof.com/p/ivory-tower-architect — https://blog.alexewerlof.com/p/ivory-tower-architect
  114. https://artoftpm.substack.com/p/alex-ewerlof-staff-eng — https://artoftpm.substack.com/p/alex-ewerlof-staff-eng
  115. https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/ — https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/
  116. https://www.infoq.com/news/2022/11/engineer-manager-pendulum/ — https://www.infoq.com/news/2022/11/engineer-manager-pendulum/
  117. https://thekua.com/atwork/2019/02/the-trident-model-of-career-development/ — https://thekua.com/atwork/2019/02/the-trident-model-of-career-development/
  118. patkua.com — https://www.thekua.com/atwork/2019/02/the-trident-model-of-career-development/
  119. https://www.goodreads.com/work/quotes/54111007 — https://www.goodreads.com/work/quotes/54111007
  120. Goodreads — https://www.goodreads.com/work/quotes/54111007-the-manager-s-path-a-guide-for-tech-leaders-navigating-growth-and-chang
  121. Goodreads — https://www.goodreads.com/author/quotes/14801119.Camille_Fournier
  122. https://www.oreilly.com/library/view/platform-engineering/9781098153632/ — https://www.oreilly.com/library/view/platform-engineering/9781098153632/
  123. Goodreads — https://www.goodreads.com/en/book/show/217312157-platform-engineering
  124. Barnes & Noble — https://www.barnesandnoble.com/w/platform-engineering-camille-fournier/1146146086
  125. https://newsletter.pragmaticengineer.com/p/engineering-career-paths — https://newsletter.pragmaticengineer.com/p/engineering-career-paths
  126. https://blog.pragmaticengineer.com/the-seniority-roller-coaster/ — https://blog.pragmaticengineer.com/the-seniority-roller-coaster/
  127. https://www.svpg.com/empowered-product-teams/ — https://www.svpg.com/empowered-product-teams/
  128. Techleadjournal — https://techleadjournal.dev/episodes/102/
  129. Careers at AMBOSS — https://careers.amboss.com/blog/empowered-by-marty-kagan-and-chris-jones/
  130. https://architectelevator.com/about/ — https://architectelevator.com/about/
  131. https://martinfowler.com/articles/architect-elevator.html — https://martinfowler.com/articles/architect-elevator.html
  132. Substack +3 — https://emmanuelvalverderamos.substack.com/p/from-ivory-tower-architect-to-staff
  133. http://gotocon.com/berlin-2014/speaker/Gregor+Hohpe — http://gotocon.com/berlin-2014/speaker/Gregor+Hohpe
  134. Ibrahim Cesar — https://ibrahimcesar.cloud/blog/the-software-elevator-redefining-the-architect-role-in-the-digital-enterprise-gregor-hohpe/
  135. https://conferences.isaqb.org/software-architecture-gathering/the-essence-of-riding-the-architect-elevator-interview-with-gregor-hohpe/ — https://conferences.isaqb.org/software-architecture-gathering/the-essence-of-riding-the-architect-elevator-interview-with-gregor-hohpe/
  136. https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf — https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
  137. DEV Community — https://dev.to/plainprogrammer/who-does-software-architecture-51a5
  138. Medium — https://devcookies.medium.com/who-needs-an-architect-%EF%B8%8F-fcdca9fdcc7a
  139. https://www.linkedin.com/pulse/more-architecture-review-boards-please-bo-vincent-thomsen — https://www.linkedin.com/pulse/more-architecture-review-boards-please-bo-vincent-thomsen
  140. https://aws.amazon.com/blogs/architecture/build-and-operate-an-effective-architecture-review-board/ — https://aws.amazon.com/blogs/architecture/build-and-operate-an-effective-architecture-review-board/
  141. https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap23.html — https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap23.html
  142. https://www.leanix.net/en/blog/architecture-review-boards — https://www.leanix.net/en/blog/architecture-review-boards
  143. https://www.oreilly.com/library/view/joel-on-software/9781590593899/Chapter14.html — https://www.oreilly.com/library/view/joel-on-software/9781590593899/Chapter14.html
  144. Frontendatscale — https://frontendatscale.com/issues/41/
  145. Maxiferreira — https://www.maxiferreira.com/blog/architecture-astronauts/
  146. https://en.wikipedia.org/wiki/Architecture_astronaut — https://en.wikipedia.org/wiki/Architecture_astronaut
  147. Holbreich — https://alexander.holbreich.org/adr_method/
  148. https://www.redhat.com/en/blog/architecture-decision-records — https://www.redhat.com/en/blog/architecture-decision-records
  149. https://adr.github.io/ — https://adr.github.io/
  150. IcePanel — https://icepanel.io/blog/2023-03-29-architecture-decision-records-adrs
  151. https://www.melconway.com/Home/Conways_Law.html — https://www.melconway.com/Home/Conways_Law.html
  152. Martin Fowler — https://martinfowler.com/bliki/ConwaysLaw.html
  153. Think Insights — https://thinkinsights.net/strategy/conways-law/
  154. https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver — https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver
  155. Puppet — https://www.puppet.com/resources/history-of-devops-reports
  156. https://hbr.org/2016/11/getting-reorgs-right — https://hbr.org/2016/11/getting-reorgs-right
  157. Medium — https://medium.com/@Cyrdup/icm-1-say-no-to-the-inverse-conway-maneuver-6672ba2373cb
  158. https://teamtopologies.com/key-concepts — https://teamtopologies.com/key-concepts
  159. https://martinfowler.com/bliki/TeamTopologies.html — https://martinfowler.com/bliki/TeamTopologies.html
  160. IT Revolution — https://itrevolution.com/articles/four-team-types/
  161. https://lethain.com/engineering-strategy/ — https://lethain.com/engineering-strategy/
  162. https://www.mckinsey.com/capabilities/implementation/how-we-help-clients — https://www.mckinsey.com/capabilities/implementation/how-we-help-clients
  163. https://baxter-neumann.co.uk/why-consultants-should-be-accountable-for-results-not-recommendations/ — https://baxter-neumann.co.uk/why-consultants-should-be-accountable-for-results-not-recommendations/
  164. https://www.quora.com/Is-McKinsey-always-succeed-in-its-recommendations-implementation — https://www.quora.com/Is-McKinsey-always-succeed-in-its-recommendations-implementation
  165. https://www.ribbonfarm.com/the-gervais-principle/ — https://www.ribbonfarm.com/the-gervais-principle/
  166. The Rabbit Hole — https://blas.com/the-gervais-principle/
  167. Nat Eliason — https://www.nateliason.com/notes/gervais-principle-venkatesh-rao
  168. https://en.wikipedia.org/wiki/Shelfware — https://en.wikipedia.org/wiki/Shelfware
  169. https://www.devoteam.com/expert-view/the-shelfware-trap-why-good-data-products-still-fail-to-create-business-value-and-how-to-fix-it/ — https://www.devoteam.com/expert-view/the-shelfware-trap-why-good-data-products-still-fail-to-create-business-value-and-how-to-fix-it/
  170. https://mwstewart.com/books/the-management-myth/ — https://mwstewart.com/books/the-management-myth/
  171. CBS News — https://www.cbsnews.com/news/consulting-and-the-management-myth-more-conversation-with-matthew-stewart/
  172. https://www.cambridge.org/core/books/worlds-newest-profession/39988BA80D1C903879DE64B820492154 — https://www.cambridge.org/core/books/worlds-newest-profession/39988BA80D1C903879DE64B820492154
  173. https://www.penguinrandomhouse.com/books/710959/ — https://www.penguinrandomhouse.com/books/710959/
  174. Wikipedia — https://en.wikipedia.org/wiki/The_Big_Con_(Mazzucato_and_Collington_book
  175. Forum New Economy — https://newforum.org/en/short-cut-with-mariana-mazzucato-the-big-con/
  176. https://www.publishersweekly.com/9780446576567 — https://www.publishersweekly.com/9780446576567
  177. https://workingbackwards.com/concepts/amazon-single-threaded-teams/ — https://workingbackwards.com/concepts/amazon-single-threaded-teams/
  178. https://pedrodelgallego.github.io/blog/amazon/single-threaded-model/ — https://pedrodelgallego.github.io/blog/amazon/single-threaded-model/
  179. https://www.geekwire.com/2017/leadership-advice-amazon-keeps-managers-focused-competing-many-industries/ — https://www.geekwire.com/2017/leadership-advice-amazon-keeps-managers-focused-competing-many-industries/
  180. Edward Betts — https://edwardbetts.com/monograph/two-pizza_team
  181. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf — https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
  182. https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model — https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model
  183. https://jobs.netflix.com/culture — https://jobs.netflix.com/culture
  184. Goodreads — https://www.goodreads.com/work/quotes/74541588-no-rules-rules-netflix-and-the-culture-of-reinvention
  185. https://netflixtechblog.medium.com/scaling-appsec-at-netflix-6a13d7ab6043 — https://netflixtechblog.medium.com/scaling-appsec-at-netflix-6a13d7ab6043
  186. https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem — https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem
  187. Jellyfish — https://jellyfish.co/library/platform-engineering/golden-paths/
  188. Cyclops-ui — https://cyclops-ui.com/blog/2025/04/24/golden-paths/
  189. https://lethain.com/components-of-eng-strategy/ — https://lethain.com/components-of-eng-strategy/
  190. https://lethain.com/eng-strategies/ — https://lethain.com/eng-strategies/
  191. https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ — https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/
  192. https://everydayconcepts.io/seagull-management — https://everydayconcepts.io/seagull-management
  193. https://www.linkedin.com/pulse/origin-hippo-highest-paid-persons-opinion-ronny-kohavi — https://www.linkedin.com/pulse/origin-hippo-highest-paid-persons-opinion-ronny-kohavi
  194. https://agilevelocity.com/blog/frozen-middle-agile-transformations/ — https://agilevelocity.com/blog/frozen-middle-agile-transformations/
  195. http://www.laputan.org/mud/ — http://www.laputan.org/mud/
  196. https://agilepainrelief.com/blog/the-spotify-model-of-scaling-spotify-doesnt-use-it-neither-should-you/ — https://agilepainrelief.com/blog/the-spotify-model-of-scaling-spotify-doesnt-use-it-neither-should-you/
  197. https://www.infoq.com/news/2021/03/spotify-paved-paths/ — https://www.infoq.com/news/2021/03/spotify-paved-paths/
  198. https://hbr.org/2014/10/the-key-to-change-is-middle-management — https://hbr.org/2014/10/the-key-to-change-is-middle-management
  199. Fractal Systems — https://fractalsystems.co.uk/agile-management-thaw-out-the-frozen-middle/
  200. Medium — https://medium.com/@amir.alsbih/from-technical-debt-to-ai-my-highlights-from-the-2024-stack-overflow-developer-survey-71b9d8595998
  201. Perforce — https://www.perforce.com/press-releases/puppets-2024-state-devops-report

EDITORIAL BRIEF

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

The pattern where organizations staff technical strategy with senior individual contributors who have deep system expertise but no organizational power, then wonder why recommendations die in committee. Explore the difference between influence-by-expertise and influence-by-mandate, and research how many cross-cutting technical initiatives actually succeed without a direct line to budget authority. The takeaway is that strategy without resource control is just consulting your own company ignores.