Team Autonomy

Teams with real mandate, competence and decision rights inside explicit boundaries — mission-based direction with local freedom over the how.

Also known as: autonomi, autonomous teams, empowered teams, bemyndigete team (empowered teams), self-managed teams (selvledelse), selvledelse, Sirkler av autonomi, Oppdragsbasert ledelse, mission-based leadership, tight/loose ledelse (Rune Ulvnes' framework), tight/loose, structured empowerment

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (32)

• What to Do When There's Too Much Work Gretchen Gavett · 2026-09-22 Reader 🖥️
  When a team is overloaded, the leader's instinct to personally absorb the excess work is the wrong fix because it merely burns the leader out without solving anything; the real levers are diagnostic (confirm the stressor is actually workload, not role ambiguity or role conflict) and structural (redistribute decision-making capacity itself — externalizing tacit judgment criteria and pushing real authority, not just tasks, downward) rather than adding capacity or subtracting volume.
• Pim de Morree's Post Pim de Morree · 2026-09-12 Reader 🖥️
  Bayer shows that when an organization is already mid-transformation, the better path is to fold AI into that existing change effort rather than launch AI as its own parallel initiative with separate leadership, budget, and governance.
• Beyond Autonomous Teams in Software Product Development Ben Linders · 2026-09-10 source ↗ Reader 🖥️
  Because a team's contribution in a complex organization is really a share of an ever-shifting web of value dependencies rather than a discrete 'product,' organizations should replace 'autonomous product team' thinking with 'value center' thinking, in which every unit at every level (person, team, team-of-teams, org) answers the same five recursive questions and trades off autonomy against coherence according to the shape of the value it carries, not according to ideology.
• Presentation: Platform Engineering in the Age of AI Stéphane Di Cesare, Davide de Paolis, Stephen Cihak, Camila Macedo, Renato Losio · 2026-09-08 source ↗ Reader 🖥️
  AI does not change what platform engineering fundamentally is — enabling safe, fast self-service through clear service intent — but it raises the stakes and widens the scope: platform teams must now serve agents as first-class consumers alongside humans, absorb new responsibilities (distributing AI context/skills, governing AI tool licensing and MCP access, guarding against non-deterministic behavior), and answer the standardization-versus-autonomy tension with embedded, evidence-producing governance rather than manual gates — making the platform, not less relevant as AI automates toil, but more central to letting an organization move safely at machine speed.
• Leder du fra sidelinjen – eller ute på banen? Mats Kristensen · 2026-08-01 source ↗ Reader 🖥️
  Good leadership is range, not a fixed position: leaders should deliberately move between an outside, strategic vantage point ('sidelinjen') and direct, hands-on involvement ('banen'), because each position sees something real the other cannot, and staying too long in either one — never stepping back to reflect, or never staying close enough to feel what is actually happening — degrades leadership.
• Frontline Workers Know How to Solve Your Organization's Biggest Problems Constance Noonan Hadley and Deborah Lovich · 2026-07-20 source ↗ Reader 🖥️
  Organizations can surface frontline employees' accurate, granular knowledge of what's broken in their work — and rebuild the trust that generic engagement surveys erode — by replacing periodic top-down surveys with a disciplined, iterative cycle of confidential listening, quantified diagnosis, employee-cocreated and ranked solutions, and piloted, repeated experimentation.
• How Open Source Enables Collaboration in Creating a Platform Ben Linders · 2026-07-11 Reader 🖥️
  A platform succeeds as a collaboration system between mutually dependent platform and application teams rather than as a one-way product handoff, and it wins adoption only when trust -- built through predictable, consistent operation and an open-source-derived shared standard and working culture -- turns tooling into a chosen way of working instead of a management mandate.
• The Power of Strategic Centering Harvard Business Review · 2026-07-01 source ↗ Reader 🖥️
  In a 'dematerializing' economy where corporate value has shifted decisively from physical assets to intangibles, executives should replace industry-position-based strategy frameworks with a single, deliberately chosen 'strategic center' (mission, customer, technology, ecosystem, or friction erasure) that the whole organization orients its resource allocation, opportunity selection, and identity around — because a clear center bounds the opportunity set without closing it, resolves capital-allocation conflicts, and licenses fast 'permissionless' action without requiring hierarchical approval.
• Revised rules of engineering leadership. Will Larson (lethain.com) · 2026-06-15 Reader 🖥️
  In an AI-accelerated engineering organization, the scarce resource shifts from code production to judgment and decision-making: individual judgment matters more (because migrations one person can now drive alone have outsized blast radius), durable domain-owning teams matter more (because execution being cheap doesn't make deciding the right thing cheap), and the organization's capacity to make quick, durable, good decisions becomes the actual bottleneck on how much benefit it can realize from AI.
• Your AI strategy has a trust problem, not a tooling problem Elena Verna (cross-posted by Lenny Rachitsky) · 2026-06-05 Reader 🖥️
  AI tooling produces no velocity unless companies first dismantle the title-gated access, decision-bottlenecking, and middle-management telephone-game that signal distrust of employees — the real unlock is employee agency, not AI agents.
• 4) Morten Eikeland: Det finnes alltid et hierarki Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-06-01 source ↗ Reader 🖥️
  Hierarchy is not optional in any group of more than a few people — it arises structurally from division-of-labour pressure plus external groups' need for a single point of contact — and the agile/teknologi/flat-struktur ideology that pretends otherwise does not eliminate hierarchy, it only makes the actual operating hierarchy invisible, unspoken, and harder to challenge; therefore the work of leading well is not to flatten but to operate at the correct abstraction level for the role one is in, to recognise the role-vs-person distinction, and (for a developer becoming a leader) to walk a real sorgprosess of identity loss before gaining a different kind of relevance.
• How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery Ben Linders · 2026-05-21 source ↗ Reader 🖥️
  Internal platforms should be run as products that expose composable 'golden bricks' rather than prescriptive 'golden paths,' so that developer teams can self-assemble their own flow of value with low cognitive load while the platform team is held accountable to adoption, experience, and DORA-like outcome metrics.
• Reinventing team flow within AI uncertainty Avanscoperta Blog · 2026-05-14 source ↗ Reader 🖥️
  Because large language models can touch nearly every step of software delivery at once rather than one isolated area, teams should respond to AI-driven uncertainty not with individual-level incentives or isolated experiments but with continuous, team-owned experimentation — resetting rituals, replacing estimation with throughput, and shifting from fixed roles to dynamic contributions — because the alternative (local, uncoordinated optimization) can make the whole system worse even when each individual change looks like a win.
• Presentation: The Human Scalability Problem: Why Your Teams Don't Scale Like Your Code Charlotte de Jong Schouwenburg · 2026-05-09 source ↗ Reader 🖥️
  When organizations scale, technical systems scale but human cooperation breaks down due to communication overload, loss of shared context, and the non-replicability of trust — and the fix requires deliberate investment in communication architecture, engineered trust, distributed cohesion, and leadership that addresses relational dynamics rather than just content.
• How Fast-Growing Companies Can Make Better Decisions Tatiana Sandino · 2026-05-07 source ↗ Reader 🖥️
  Fast-growing companies that frame decision-making as a binary choice between centralization and decentralization fall into predictable failure modes; a third path — structured empowerment, which combines curated decision options with outcome-based accountability — lets organizations scale while preserving both consistency and local adaptability.
• New Skills to Navigate Continuous Change HBR.org (Nilofer Merchant conversation) · 2026-05-05 source ↗ Reader 🖥️
  The biggest barrier to organizational change is not resistance but inherited norms — especially the privileging of confidence over competence and control over co-creation — and leaders who replace those norms with collaborative ownership, curiosity, and tolerance for discomfort will unlock the innovation their organizations already contain.
• Forskning på digitalisering 2026 uke 19 Leif Knutsen · 2026-05-04 source ↗ Reader 🖥️
  Current software engineering research highlights a recurring tension: agile transformation, measurement, and AI-assisted code analysis all require structured, disciplined approaches that seem to contradict the flexibility they aim to enable — and these paradoxes are not yet resolved.
• Everyone wants to be AI-pilled. Most Companies Are Still Level 1 Ann Miura-Ko · 2026-05-01 source ↗ Reader 🖥️
  ‘AI-pilled’ is not a binary state but comes in six observable levels, defined by what AI can see, what it can do, who can extend it, and how the organization's structure has actually changed — and most companies, despite confident AI rhetoric, remain stuck at the lowest levels because they skip the hard, unglamorous work of making their own operations legible and structurally rewiring who does what before real autonomy becomes possible.
• 10) Una Aamodt Mathisen om å lede når du ikke har fasiten Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-02-02 source ↗ Reader 🖥️
  {'english': "Leading complex cross-functional product work means accepting that the leader does not hold the answer key (fasiten) — the leader's job is to set direction and create the conditions in which a multidisciplinary team can find the answer together, not to supply it; competence at this looks like detective-work listening on arrival, hypothesis-shaped direction-setting ('we're going to that mountain, but route and gear we figure out together'), tight/loose discipline that closes the loop on learning, and tolerance for the friction and uncertainty that comes with not pretending to know.", 'norwegian': "Å lede tverrfaglige produkt-team på tvers av forretning, teknologi og fag betyr å anerkjenne at lederen ikke sitter på fasiten — lederens oppgave er å sette retning og legge til rette for at teamet finner løsningen, ikke å levere svaret selv; god utøvelse ser ut som lytte-detektivarbeid i starten, hypotese-formet retning ('vi skal på det fjellet, men rute og bagasje finner vi ut av sammen'), tight/loose-disiplin som lukker læringssløyfen, og toleranse for friksjonen og usikkerheten det skaper å ikke late som om man kan svaret."}
• 9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-01-19 source ↗ Reader 🖥️
  The promised productivity gains from AI in software development will not materialize at the organizational level unless teams deliberately slow down — investing in psychological safety, structured reflection, and joint experimentation — because software development is fundamentally a learning process and AI threatens the learning even as it accelerates the output.
• 8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-01-04 source ↗ Reader 🖥️
  Becoming Nordic-aligned (not pan-European, not purely national) is the right level at which to consolidate digital marketplaces, and getting there requires leading at the right abstraction layer — setting direction and 'why' from the top while delegating the 'how' to distributed cross-Nordic vertical teams — because the previous failure of pan-European centralisation taught Printzell Halvorsen that scale only works when the people whose work is being reorganised are kept, respected, and reassembled around problem verticals rather than dispossessed by a new hub.
• 7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-12-15 source ↗ Reader 🖥️
  Insourcing, retning, and strategi-på-en-ølbrikke are three faces of one leadership move: pulling the locus of decision-making in-house and then compressing direction tightly enough that a distributed organisation can actually act on it — insourcing repatriates the people who must own the work, oppdragsbasert ledelse and sirkler av autonomi give those people a clear mission with explicit frihetsgrenser, and the ølbrikke forces utviklingsstrategi down to the few hovedområder a development organisation can actually carry, with OKRs underneath and an explicit business case underneath that.
• 2) Hans Christian Holte dusjer i informasjon Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-10-20 source ↗ Reader 🖥️
  What senior public-sector leadership at NAV's scale actually consists of is the disciplined acceptance that you cannot retain most of the information that washes over you — that you must filter to a few central themes, lean heavily on competent people around you, deliberately ride the elevator between strategic altitude and the work itself ('T-ledelse'), and treat technology development not as a domain you keep up with personally but as the most potent strategic lever you must integrate with legal, professional, and user-experience perspectives to bring the whole organization, not just the directorate, forward.
• 0) Velkommen til Heis Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-10-10 source ↗ Reader 🖥️
  Heis is a podcast about technology leadership across the different organizational floors of a company — riding the elevator up and down to talk with leaders at every level — built on the conviction that autonomous teams still need leadership, that traditional management does not fit the team model, and that the leaders modern technology companies need are people with hands-on experience from working in teams and with technology.
• Leading your engineers towards an AI-assisted future Pete Hodgson · 2025-06-26 source ↗ Reader 🖥️
  An engineering leader should drive AI-coding adoption the same way they'd drive any major capability shift — by setting a clear, phased goal (Experimentation, then Adoption, then Impact) measured with lightweight KPIs, giving teams real autonomy over how they get there, and backing that autonomy with concrete organizational support (training, budget, protected time, a community of practice, empathetic communication) — rather than mandating a usage percentage from day one.
• Update on Software Engineering Career Ladder jamesshore.com · 2024-08-20 source ↗ Reader 🖥️
  OpenSesame's redesigned career ladder deliberately shifts the organization's definition of engineering seniority away from individual ownership and self-promotion toward teamwork, peer leadership, and manager-verified skill fluency -- trading the old system's clarity and perceived fairness for reduced self-promotion/tenure bias, at the real cost of a heavier, judgment-intensive evaluation burden that falls unevenly on managers depending on how well they already know their people.
• Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024 SQUER Solutions · 2024-06-11 source ↗ Reader 🖥️
  Successful architecture modernization is primarily an organizational and narrative problem, not a technology-upgrade problem: it succeeds when architects treat the value stream (business domain + outcomes + team autonomy + deployability) as the real unit of design, triage the system as a portfolio rather than rebuild it wholesale, and use social tools (listening, impact mapping, event storming, enabling teams, early visible wins) to earn and sustain the organizational permission that technical skill alone cannot secure.
• Software Development As Collective Learning With Hazel Weakly John Cutler from The Beautiful Mess · 2024-04-28 Reader 🖥️
  Effective software development is produced by the emergent, collective behavior of a system of collaborating people, not by maximizing any individual's personal output as a 'force multiplier'; the real job shared by architecture and leadership is building explicit, intentional structures for how people learn, decide, and check in with each other, so that many independent local decisions add up to globally coherent outcomes, and so that structural change (migrations, reorgs) can happen continuously and safely rather than through disruptive one-off events.
• Software Teaming: A Mob Programming, Whole-Team Approach Woody Zuill and Kevin Meadows · 2022-11-04 Reader 🖥️
  A whole team working together, all day, at one computer, on one thing at a time — using a Driver-Navigator discipline and a self-chosen agreement to treat each other with Kindness, Consideration, and Respect — is more effective than the conventional practice of separating specialists, because nearly all of software development's hidden costs (queueing, context-switching, faulty communication, indecision, defects, politics) are side effects of separation that fade away once the whole team works in one continuous flow, rather than problems that must be solved individually.
• Thriving with complexity using open sociotechnical systems design Trond Hjorteland · 2022-01-05 source ↗ Reader 🖥️
  Software organizations should undergo a radical, participatively-designed structural transition from DP1 (bureaucratic, redundancy-of-parts, externally-coordinated) to DP2 (self-managing, redundancy-of-functions, internally-coordinated) sociotechnical design — the empirically-grounded Open Systems Theory tradition that agile, product, and 'team-first' movements have been independently and incompletely rediscovering — because only DP2 generates the variety needed to thrive in today's turbulent technical and social environment, and because that change must be structural and self-designed, not a culture or values campaign layered on top of unchanged structure.
• Scaling the Practice of Architecture, Conversationally Andrew Harmel-Law · 2021-11-30 source ↗ Reader 🖥️
  Architecture should be practiced as a decentralized, conversational discipline — anyone can make an architectural decision as long as they first seek out and record advice from those meaningfully affected and those with relevant expertise (the 'Advice Process') — supported by four lightweight tools (Architecture Decision Records, a recurring Architecture Advisory Forum, team-sourced architectural principles, and a technology radar) that let architecture scale with team autonomy instead of being bottlenecked on a small group of designated architects.
• Mob programming: From avant-garde experimentation to established practice Daniel Ståhl, Torvald Mårtensson · 2021-07-29 Reader 🖥️
  Mob programming is a genuinely emergent but still immature practice whose effects — on productivity, learning, exhaustion, and team social dynamics — vary so much by individual and by task type that no universal claim about its efficacy holds; what the published literature treats as settled benefits are, on direct interview evidence from committed practitioners, ambiguous, individually contingent, and in urgent need of quantitative (not just anecdotal) research.

Propositions touching this concept (15)

By publication month, oldest first (extraction month when no publication date is known).

2025-10

• explicitdevelopedAutonomous teams still need leadership — autonomy alone is insufficient.
  0) Velkommen til Heis · p2
• explicitTraditional leadership ('ledelse på gamle måten') does not work in organizations built around autonomous teams.
  0) Velkommen til Heis · p3
• explicitEffective leadership for the team model must 'play on the team' (spille på lag) with that model — i.e., be aligned with and supportive of team autonomy, not in tension with it.
  0) Velkommen til Heis · p4
• explicitdevelopedLeadership of autonomous teams has two failure modes — too much traditional control and too much berøringsangst (fear of touching) — and the task is the balance: tight enough to point direction, not intrusive in execution.
  2) Hans Christian Holte dusjer i informasjon · p7

2025-12

• explicitOppdragsbasert ledelse — give clear mål and rammer, not trinn-for-trinn — is the operating model that survives contact with reality; the Nordic military model has outperformed the old Soviet model precisely on this dimension.
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke · p8

2026-02

• descriptivecorroboratedDirection-setting (retning) and team autonomy are not opposites; they are mutually constitutive — autonomy without shared direction produces drift, direction without autonomy produces literal compliance.
  10) Una Aamodt Mathisen om å lede når du ikke har fasiten · p4
• prescriptiveTools and frameworks (tight/loose, OKR, autonomous teams) only work when 'made your own' — adapted to organizational maturity, sector, and the team's experience with prior methods.
  10) Una Aamodt Mathisen om å lede når du ikke har fasiten · p9

2026-05

• prescriptivecorroboratedStructured empowerment — curated decision options plus outcome-based accountability — resolves the centralization-decentralization trade-off by embedding organizational knowledge while preserving local adaptation.
  How Fast-Growing Companies Can Make Better Decisions · p4
• prescriptivedevelopedEmployees under structured empowerment should be assessed on key outcome results — whether they delivered customer value — not on which options they chose or process compliance.
  How Fast-Growing Companies Can Make Better Decisions · p6
• prescriptiveStructured empowerment requires two enabling conditions: formal double-loop learning systems and an empowering culture (purpose, adaptability, candor/psychological safety).
  How Fast-Growing Companies Can Make Better Decisions · p8
• speculativeAI-generated options (e.g., real-time diagnostic suggestions for customer service) can serve as curated options within a structured empowerment system.
  How Fast-Growing Companies Can Make Better Decisions · p10

2026-09

• explicitcontestedAutonomous teams are treated as an unexamined article of faith in modern software development, and this framing should be replaced by 'value center' thinking.
  Beyond Autonomous Teams in Software Product Development · p1
• explicitThe shape of an organization's value (its web of dependencies) determines and constrains what organizational structures are possible, including the achievable trade-off between team autonomy and organizational coherence.
  Beyond Autonomous Teams in Software Product Development · p4
• implicitThe piece implicitly treats 'autonomous teams' as an oversimplified industry orthodoxy that has calcified into unreflective dogma, making the article fundamentally a corrective/critique rather than a neutral report.
  Beyond Autonomous Teams in Software Product Development · p12
• explicitDeciding what to centralize on a platform versus leave to team autonomy is platform engineering's perennial, still-unanswered question, and this is true independent of AI.
  Presentation: Platform Engineering in the Age of AI · p6

Open gaps (94)

• incompleteThe piece treats individual experimentation ('individual actions remain valid and don't require any upfront agreement') and team-owned experimentation (Popcorn Flow, assessed as a team) as compatible, coexisting levels, but never works out what happens when they conflict — e.g. an individual's unilateral habit change (dictation instead of typing prompts) versus a team's committed, board-tracked experiment that assumes a different interaction pattern.
  Reinventing team flow within AI uncertainty — read next: Look for material on reconciling individual experimentation with team-level process commitments more generally — where the boundary between 'my own workflow tweak' and 'something the team needs to agree on' actually sits.
• incompleteNo account of transition mechanism or cost: the article stays entirely at the level of naming and reframing ('call it a value center, ask these five questions') without describing how an organization currently structured around autonomous product teams and stable roadmaps would actually migrate — what changes first, who has authority to redraw team boundaries, or what the migration costs in disruption and rework.
  Beyond Autonomous Teams in Software Product Development — read next: extract-structured-empowerment-decisions#p4 and #p8 (structured empowerment's enabling conditions: double-loop learning systems, empowering culture) as a model for what an implementation-level account would need to specify
• incompleteThe claim that the five questions apply unchanged 'at all levels: team, team-of-teams, department, whole organisation' is asserted but only ever demonstrated with a single team-level worked example (Scrum backlog, sprint goal); no worked example is given at the team-of-teams, department, or whole-organization level, so the universality/recursiveness claim is untested within the piece itself.
  Beyond Autonomous Teams in Software Product Development
• incompleteNo engagement with whether agile transformation frameworks actually work — the Italian study is summarized but its evidence base is not examined
  Forskning på digitalisering 2026 uke 19
• incompleteThe measurement section invokes Deming but does not specify which concrete metrics would satisfy the learning-over-control criterion in modern agile contexts
  Forskning på digitalisering 2026 uke 19
• incompleteNo discussion of how LLM-generated code interacts with the measurement problem — if LLMs generate code, what does 'developer productivity' even mean?
  Forskning på digitalisering 2026 uke 19
• incompleteThe bonus items (frontline leadership, sustainability micro-foundations, airport effects) are too thinly described to extract any propositions
  Forskning på digitalisering 2026 uke 19
• incompleteThe article asserts the Advice Process produces 'better, faster, more accountable' decisions purely from the author's own practitioner experience, with no named organization, no comparison against the traditional model it replaces, and no outcome data (defect rates, lead time, decision reversal rates).
  Scaling the Practice of Architecture, Conversationally — read next: Look for empirical studies of decentralized decision-rights models (e.g. DORA/Accelerate-style research) that measure outcomes rather than practitioner testimony.
• incompleteThe article never reports what happened to the 16 of 18 employee-ranked, cocreated ideas that leaders did not select for implementation — nor whether leaving most cocreated proposals unaddressed carries the same trust cost the article attributes to unmet expectations from ordinary engagement surveys.
  Frontline Workers Know How to Solve Your Organization's Biggest Problems — read next: Employee voice / suggestion-scheme research on what happens to ideas that are solicited, ranked, and then not acted on — e.g., literature on 'voice endorsement without implementation' and its effect on subsequent participation.
• incompleteNo comparison group, pre-existing trend baseline, or control for the concurrent organizational/leadership change the article itself mentions mid-case is offered, so the reported improvements (pulse scores, stable adherence, on-schedule coaching rollout) cannot be separated from simple attention effects (Hawthorne-type), regression to the mean from a poor starting baseline, or the coincident leadership transition.
  Frontline Workers Know How to Solve Your Organization's Biggest Problems — read next: Methodologically rigorous employee-intervention studies with control groups; critiques of single-case consulting case studies as an evidence class.
• uninformedThe article discloses no cost figures — consultant fees, roughly 100 hours of confidential frontline interviews plus survey time plus three 90-minute focus groups plus multiple town halls, and five months of engagement by two outside institutions — needed to weigh the return of this 'disciplined process' against its resource intensity before an organization adopts it as a portable method.
  Frontline Workers Know How to Solve Your Organization's Biggest Problems — read next: Cost-benefit or ROI studies of large-scale employee-listening / engagement interventions.
• incompleteThe authors are the intervention's own designers evaluating their own consulting engagement's success: Lovich is a BCG senior partner co-authoring a forthcoming book built on this exact framework, and the survey used is a named, proprietary BCG instrument. No independent verification, peer replication, or disconfirming case is offered — read against the stated skepticism of consulting-firm frameworks, the piece is more evidenced and quantified than a typical McKinsey/BCG listicle (real response rates, real before/after timing data, a named survey instrument with specific dimensions), but it is still, structurally, a case study written by the vendor about the vendor's own product, doubling as pre-publication marketing for Lovich's book.
  Frontline Workers Know How to Solve Your Organization's Biggest Problems — read next: Independent (non-consultant-authored) accounts of similar frontline-listening interventions; critiques of practitioner-authored HBR case studies as an evidence genre.
• incompleteEvery named company example is one whose centering choice is, so far, associated with a good outcome (Novartis, Fujifilm, TSMC, Samsung, Toss, DBS, Nvidia, Shopify, early Amazon). Kodak and Southwest appear only as foils establishing other companies' successes, not as tested instances of 'had a clear, deliberately chosen single center and it still failed.' No company that centered and underperformed is discussed, so the base rate of centering's success is unknowable from the article alone.
  The Power of Strategic Centering — read next: Survivorship-bias literature (Mlodinow's 'The Drunkard's Walk', Taleb) on retrospective success narratives fitted to winners; Rosenzweig's 'The Halo Effect' critique of the 'In Search of Excellence' genre of business writing, which has essentially the same evidentiary structure as this article.
• uninformedNo attempt is made to separate the causal contribution of 'centering' from contemporaneous confounds: Novartis's radioligand bet coincided with a broadly hot oncology/precision-medicine investment cycle; TSMC's and Samsung's ecosystem success is explicitly bound up with decades of targeted state industrial policy (named in the text itself), yet the article still credits 'centering' as the operative variable rather than state support; Fujifilm's successful diversification depended on pre-existing chemical/materials-science IP whose availability to Kodak is never assessed.
  The Power of Strategic Centering — read next: Regression-to-the-mean and confound-control literature in strategy research; comparative case-study methodology critiques (e.g., Geoffrey Jones or business-history methodology essays) on isolating a single explanatory variable from multi-causal corporate histories.
• incompleteEach of the five centering types is given a named risk (mission drift, goal conflict, technological narcissism, geopolitical dependency, scope creep), but no instance is given of a company whose centering failed because that risk actually materialized. Without an observed failure case per risk, the framework offers no falsification criterion — it cannot currently be distinguished from 'successful companies, described after the fact, can always be shown to have had a coherent internal logic.'
  The Power of Strategic Centering — read next: Popper on falsifiability as a demarcation criterion; compare against how the 'resource-based view' and 'core competence' literatures the article dismisses were themselves originally supported by anecdote before later empirical scrutiny — is this critique specific to strategic centering, or standard for the strategy-framework genre at its introduction?
• misinformedThe load-bearing statistic — 'roughly 83% of Fortune 500 assets were tangible in 1975 versus ~90% intangible today' — is presented as a clean, uncontested fact via a single secondary citation, without stating measurement methodology. The widely-circulated version of this figure (traceable to the Ocean Tomo 'Intangible Asset Market Value' study) proxies 'intangible value' as market-cap-minus-book-value, which is sensitive to speculative multiple expansion and stock-market bubbles, not purely to genuine changes in asset composition — a methodological caveat the article does not mention despite resting its entire historical premise on the number.
  The Power of Strategic Centering — read next: Methodological critiques of the Ocean Tomo intangible-asset study specifically; broader critiques of using market-cap-minus-book-value as an 'intangibles' proxy in accounting/finance literature.
• illogicalThe newsletter juxtaposes 'push authority down, not just tasks' against 'stress often isn't about workload but role ambiguity or role conflict' without noticing the interaction: expanding a report's decision scope (more authority, more ambiguous boundaries about what's now theirs to decide) could itself increase role ambiguity or role conflict — the very stressors the second piece names as sometimes more damaging than workload. The two lead pieces are presented as complementary but may actually be in tension for some teams.
  What to Do When There's Too Much Work — read next: The full Wilding article and the full Sawhney/McCord research paper, read against each other, to see whether either addresses how expanding decision authority interacts with role clarity.
• incompleteGavett teases 'a counterintuitive finding about employee engagement and high workloads towards the end' of the Sawhney/McCord piece but never states it. A reader of only this newsletter cannot evaluate, apply, or even remember the actual finding — the sentence functions as an ad for the linked article rather than a self-contained claim.
  What to Do When There's Too Much Work — read next: The full Sawhney/McCord HBR piece, specifically for the engagement/workload finding.
• uninformedNo diagnostic method, checklist, or set of distinguishing questions is given (in this document) for telling role overload apart from role ambiguity or role conflict in practice — the newsletter asserts the categories exist and that correct diagnosis matters, but supplies no way to actually perform that diagnosis.
  What to Do When There's Too Much Work — read next: The full Sawhney/McCord research piece for their stated diagnostic recommendations.
• incompleteThe thesis that traditional leadership doesn't work with autonomous teams is stated as observed fact ('vi så i NAV') but never specified. Which behaviors of old-style leadership failed? What were the visible symptoms? Without examples, the claim functions as a slogan rather than an argument — appropriate for a welcome episode, but the show will need to deliver the substance.
  0) Velkommen til Heis
• incompleteThe argument that this kind of leadership requires experience 'from working in teams and with technology' is asserted but not defended. It excludes by implication leaders from non-engineering backgrounds; whether and why that exclusion is justified is not addressed.
  0) Velkommen til Heis
• incompleteThe 'every company is a technology company' claim is delivered as a closer without supporting argument. It is a common premise in contemporary tech-leadership discourse but the episode does not engage with the well-known counter-readings (that 'tech company' loses meaning when applied universally; that technology intensity is a spectrum, not a binary).
  0) Velkommen til Heis
• incompleteThe elevator metaphor implies vertical movement between hierarchical levels, but the show's stated commitment is to a team-model world where hierarchical levels are deliberately flattened. There is a latent tension between 'visit leaders on every floor' (which implies floors exist as distinct strata) and 'leadership that plays on the team' (which implies the strata are less salient). The episode does not address this tension.
  0) Velkommen til Heis
• incompleteThe cost side of the information shower is not addressed. Every person who 'prepares and wants to land maximum points in their slot' is paying a cost: compressing their best case, choosing what to leave out, presumably also accepting that most of their points will be among those that 'rinse down the drain.' A senior-leader-centric view of information overload treats it as a load problem on the receiver; a system view would ask what happens to the people producing the information for the shower and what the aggregate organizational effect is when many serious efforts produce one-slot compressions that the receiver does not retain. Holte's metaphor invites this question and the conversation does not pick it up.
  2) Hans Christian Holte dusjer i informasjon
• incompleteThe criteria for which 'few central themes' Holte holds are not made explicit. He mentions specific filters: digital representation as a near-term must-solve at NAV offices; the NAV-office counsellor as a long-term focus; user experience as his current energise-zone. But how those particular bets emerged from the shower — what got filtered out, by what test — is not described. This is the operationally most interesting question and the most strategically sensitive; an answer might also be politically costly to give.
  2) Hans Christian Holte dusjer i informasjon
• unaddressedThe piece does not address what happens when Holte's filtering is wrong — when a theme that should have made it through the filter did not. The arbeidsavklaringspenger case is named as a failure of broad-enough thinking, but the role of his own information processing in that failure is not interrogated. A self-aware leader could productively unpack the failure mode of accepted forgetting: the information you accept losing may include exactly the information you should have kept.
  2) Hans Christian Holte dusjer i informasjon
• incompletePublic-sector context shapes what Holte can say. As sitting NAV director he must be careful about politically loaded territory (the stat/kommune split at NAV offices, decisions about digital identity, the politics around the user-experience unit). The conversation rides these edges and signals them ('certain politicians are squinting at us') but cannot fully unpack them. This is a structural feature of the format, not a flaw — but it limits how much of Holte's actual filtering criteria can surface.
  2) Hans Christian Holte dusjer i informasjon
• incompleteThe 'T-ledelse' reframe of the hosts' heis-fører concept is elegant, but the question of where T-ledelse fits in a 22,000-person organisation with multiple levels — and whether T-ledelse from the very top can substitute for translation roles at the middle — is not resolved. The hosts' own concept (heis-fører at middle levels) and Holte's reframe (T-ledelse from the top) may not be alternatives at all; the conversation does not address whether both are needed.
  2) Hans Christian Holte dusjer i informasjon
• irrelevantThe episode does not address the dusjer-i-informasjon dynamic outside the senior-leader context — at lower organisational levels (where 'preparation by counterparties' looks very different), or in private sector (where Holte has no recent experience). The framing is specific to Holte's altitude in Norwegian public-sector leadership, and the conversation honours that specificity rather than over-generalising — which is appropriate for the form, though a syntopical reading across episodes might generalise it.
  2) Hans Christian Holte dusjer i informasjon
• incompleteThe thesis 'det finnes alltid et hierarki' is rescued from triviality by Eikeland's broad definition (formell + uformell + kunnskaps- + framing-makt), but the same breadth makes the claim nearly unfalsifiable. Every conceivable group has some asymmetry of influence on some dimension; calling that 'hierarki' wins the argument by definition. The conversation does not engage the harder question of when the unit of analysis is wrong — when treating a temporary, context-dependent, weak asymmetry as a 'hierarchy' obscures more than it reveals.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Compare to network-and-influence literature (Cross/Parker on organisational networks, Vedres/Stark on structural folds) where the alternative unit is the network of weak ties rather than the layered hierarchy. Also Heath/Sunstein on consensus-driven decision-making to test where 'hierarchy' really is the operating frame.
• incompleteThe claim that flat-org rhetoric is selvbedrag is supported by Eikeland's clinical observation and the innvandrer vignette but not by counter-evidence from organisations that have made the rhetoric operationally real (or that have failed in distinctively non-Eikeland ways). The conversation does not engage Holacracy, Buurtzorg, sociocratic governance, or the long literature of self-managing teams. The result is a strong descriptive claim resting on a single vantage point.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Read Laloux Reinventing Organizations, Buurtzorg case studies, Robertson's Holacracy critically — both for examples of self-organisation that genuinely changes which hierarchy operates and for documented failures that Eikeland's frame would explain well. Pair with Lee/Edmondson's typology of self-managing organisations.
• incompleteThe role-vs-person distinction is presented as universal but it conflicts with a strong current of contemporary leadership literature (authentic leadership, bring-your-whole-self-to-work, vulnerability-based trust à la Lencioni/Brown) that holds that role-thick depersonalised leadership is itself the failure mode in knowledge work. The conversation does not engage these counter-positions; it treats them only implicitly via the Trump example, which is a one-sided foil.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Read Brené Brown on Dare to Lead, Goffee/Jones 'Why Should Anyone Be Led by You?', Lencioni on vulnerability-based trust against Eikeland's role-thick line. The most interesting test case is: are there role-domains where role-thickness is right (dommer, kirurg, politi) and other domains where it is wrong (product-team leadership, R&D leadership)?
• incompleteEikeland's developer-to-leader sorgprosess prescription is rich on the loss side but thin on the gain side. The transition presumably brings new sources of meaning (impact through others, system-level effect, mentoring, organisational design), but the conversation barely names them. The risk for the listener is to internalise the loss-frame and miss the path through.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Camille Fournier's Manager's Path; Will Larson's Staff Engineer/An Elegant Puzzle on the IC-vs-manager fork; Lara Hogan on growing engineering leaders. Pair with Olga Khazan or Lori Gottlieb on the psychology of mid-career identity transitions.
• incompleteThe illusion-of-explanatory-depth intervention (ask for mekanismer not meninger) is presented as reliably productive but Eikeland admits it provokes forbannelse and ejection from rooms. The conversation does not address how to make the intervention land without burning the relationship — i.e., the practice question of how to descend into mekanisme safely. This matters because the intervention has weight only if it can be sustained inside an ongoing leader relationship.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Edgar Schein on humble inquiry; Marshall Goldsmith on stakeholder-centred coaching; Patterson et al. Crucial Conversations. The Heis-internal pairing is with Brede Moe (ep 9) on psykologisk trygghet as the precondition for being usable as a diagnostic outsider.
• uninformedThe argument that teknologene have gained makt at the expense of 'litt enklere selgere' is named as a flagged trade-off but not analysed. The conversation does not engage the broader political-economy story of which professions rise and fall with each kunnskapshierarki shift, or the consequences for democratic and labour-market dynamics when one type of fag becomes dominant. Eikeland's clinical vantage is not designed for this question; the gap is honest but real.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Read Daniel Markovits The Meritocracy Trap, Michael Sandel The Tyranny of Merit on the consequences of credentialist hierarchies. For the Norwegian case specifically, NAV's own reports on labour-market polarisation.
• incompleteEikeland insists hierarchies are inevitable but does not develop how to design good hierarchies versus bad ones. Hierarchy as a design object — its arity (span of control), its time-horizons per level, its dual lines (formal/uformell), its rotation, its accountability — receives no operational attention. The descriptive claim therefore stops short of a constructive prescription beyond 'operate at the right abstraksjonslag and recognise rolle vs person.'
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Elliott Jaques on requisite organisation and time horizons per level; Stafford Beer's Viable System Model; James Mwangi on adaptive governance. Pair with Printzell Halvorsen (ep 8) on the Vend operating model as a worked example of an explicit, designed hierarchy that honours these structural pressures.
• incompleteThe claim that ledelse-as-coordination kicks in around eight people is asserted as 'avhenger litt av hvor mye interaksjon du trenger' but not defended against the broader social-science literature on group size, span of control, and self-organisation thresholds. The number is plausible but the conversation does not engage why eight rather than five or twelve, what happens in distributed/asynchronous groups, or how the threshold shifts with technology.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Robin Dunbar's hierarchies of group size (5, 15, 50, 150); Christopher Allen's optimal group sizes; Tuckman's small-group dynamics. For the distributed case, GitLab's all-remote handbook on team sizing and the post-COVID literature on async coordination.
• incompleteHaugseth's account is built on insourcing successes (Mattilsynet, NAV). There is no narrative of an insourcing that failed or backfired — no analysis of when insourcing produced worse outcomes than the status quo. The closest is the NAIS-reflection (where she would have stayed less ambitious about own platform), but that is presented as 'should have piggybacked,' not 'insourcing failed.' The asymmetry shapes what is visible: insourcing's hazards (talent risk, two-year ramp where the org loses access to specialists, capability concentration in a few key hires who then leave) are absent from the framing.
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke — read next: Susanne Justesen / John Cutler on the cost of capability concentration; the Norwegian NAV 'Optimizing for Fast Flow' article (already in the user's library) for a parallel account that emphasises the work-system rather than the ownership question; Capacity Planning literature on staffing as a long-cycle bet; failure-case writing on insourced platform teams that lost their flywheel (Stripe / Etsy public postmortems are useful counterpoints).
• incompleteThe business-case for insourcing is asserted but not specified. 'Either konsulentene get ny oppdrag andre steder, OR rådgiver-hverdagen improves enough to boost inntekt' is a frame, not an analysis. What kind of measurement? Over what horizon? Who validates the case 24 months in? The hard version of the case — that some insourcing pays for itself only in scenarios that don't materialise — is not engaged.
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke — read next: Roger Martin on the strategy-stack from where-to-play to how-to-win; cost-of-delay literature; Dan North on staffing-as-bet.
• incompleteThe ølbrikke method is presented as a virtuous compression artifact, but the failure mode — that radical compression elides important trade-offs and lets every reader project their preferred reading onto the three hovedområder — is not addressed. Olrud Moen (ep 15) discusses the strategy-as-PowerPoint failure mode explicitly; Haugseth's ølbrikke could fall into a sibling failure mode (the strategy-as-slogan trap).
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke — read next: Olrud Moen Heis ep 15 (recently extracted) — direct counterpoint on strategy compression; John Cutler's TBM on 'making the trade-off visible'; Roger Martin on integrative thinking; Donald Sull on 'simple rules.'
• incompleteThe sponsor-group mechanism is described in the abstract; what happens when the two sponsors disagree, or when a sponsor leaves konsernledelsen mid-oppdrag, or when sponsor priorities conflict with what the team's konsernledelse-wide one-pager actually says, is not analysed.
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke — read next: Marty Cagan / SVPG on product strategy governance; Cutler on accountability culture and DRIs (directly responsible individuals).
• incompleteHaugseth's epistemic update on skye is offered as an instance of changing her mind, but the underlying mental model that drove her earlier full-pro-cloud stance is not interrogated. What other current convictions might be in the same epistemic position now? The 'how does a leader earn forankring on the world' question (same as the Olrud Moen ep 15 gap) is unaddressed.
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke — read next: Annie Duke 'Thinking in Bets' (already in user's library) on calibration and the cost of being skråsikker about probabilistic claims; Philip Tetlock on superforecasting; Donella Meadows on systemic leverage points.
• incompletePower and political economy are visible at the edges (the consultant houses' motstand to Mattilsynet cancellations; the 'kjipe' work of handling underperformance) but never named as power. The political cost paid by the consultant houses, by the developers whose subkulturer were dismantled, and by the avdelingsledere who had to take on accountability for cross-team samhandling is not analysed.
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke — read next: Cutler 'Power and Space' (TBM 413, already in user's library); Pfeffer 'Power' on organisational politics; Hamel/Birkinshaw on managerial innovation and its political cost.
• incompleteThe 'privilegium ikke identitet' frame is named but not connected back to the operating-model questions earlier in the conversation. A leader who treats the role as borrowed time presumably should design the operating model so it survives their departure — i.e., the ølbrikke and the sponsor-group should ideally outlast the leader. That implication is not drawn.
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke — read next: Cutler on operating systems as artefacts that survive their author; Olrud Moen ep 15 on 'strategy as the few sharp trade-offs that nobody else has the authority to set' — and the corollary question of what the leader leaves behind.
• incompleteThe case for 'lokalt forankret, nordisk samlet' rests heavily on the three favourable conditions (small cultural distance, similar maturity, no hub story) that Printzell Halvorsen names. The conversation does not seriously interrogate what happens in cases where one or more of those conditions does not hold — e.g. a Nordic group with one dominant and three start-up markets, or a public-sector federation where national differences (legal, fiscal) are large. The model may be narrower than its rhetorical appeal suggests.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Compare to Nordic banking (Nordea), Nordic telecom (Telia/Telenor), and Nordic public-sector federations to see where the conditions hold and where they don't. Read Geert Hofstede / Erin Meyer on the actual measured cultural distances within the Nordics.
• incompletePrivileged-Schibsted-vantage shapes what's visible vs. invisible. The lessons are drawn from a Schibsted-internal lineage of marketplaces with strong brands, a developer-heavy talent pool, and a long maturation as commercial businesses. The conversation is silent on: public-sector contexts, non-media startups, B2B enterprise software, government-mandated platform consolidations, and platforms where brand-in-consumers'-heads is not the load-bearing asset. The framework is presented as broadly applicable without owning these scope conditions.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read public-sector platform consolidation case studies (NAV, Skatteetaten, NHS Digital, Estonian e-government); read B2B platform consolidation studies (Salesforce-MuleSoft, Adobe-Figma). The presence/absence of the Vend pattern in those contexts would map the model's actual reach.
• incompleteThe methodological claim that big-bang beats phased for integration projects with a known target state is grounded in three Vend cases and asserted as a general lesson. The conversation does not consider failure cases (industry has many) or the boundary conditions (rehearsal infrastructure, rollback capability, cohesion of the cut team). Listeners may over-apply.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read post-mortems on famous failed big-bang migrations (UK NHS NPfIT, TSB Bank 2018, Hertz/Accenture) to identify what made Vend's big-bangs work that those did not have.
• incompleteBob the Builder is presented as low-code AI tooling that produces useful prototypes and personal-productivity solutions but is firewalled from product production code. The conversation does not address how outputs ever cross that firewall — what happens when a marketing team's Bob the Builder solution becomes load-bearing and needs the engineering quality bar.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read low-code/citizen-developer governance literature (Gartner's 'fusion teams,' Microsoft Power Platform CoE patterns) for how organisations handle the citizen-to-production handoff.
• incompletePrintzell Halvorsen names the senior/junior asymmetry of technology fluency implicitly (his own developer past as anchor; CFO going through Bob the Builder to stay relevant) but never engages the question of how Vend develops the next generation of leaders without a developer past. The transferability of the abstraksjonslag instinct to non-technical leaders is left open.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read Beane on apprenticeship in mixed-expertise contexts; read deliberate-practice literature on developing abstraction skill without a code substrate.
• incompleteThe destination-vs.-chat scenario framing is treated as binary. The conversation does not engage the third possibility — that marketplaces become specialised APIs feeding many fronts (chat, AR shopping, voice assistants), with the consumer-facing brand decoupled from the consumer-facing surface. That would require a different bet on data infrastructure and brand strategy.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read literature on platform economics under generative AI distribution (Anu Hariharan, a16z's recent marketplaces writing); Matthew Prince's own writing at Cloudflare on the AI-content-economy collapse and 'pay-per-crawl' proposals (which Printzell Halvorsen alludes to when citing him).
• uninformedThe conversation does not engage with the consumer-welfare or competition-policy implications of Nordic consolidation. Consolidating into Vend reduces marketplace competition within each vertical at a Nordic level. The hosts do not raise this; Printzell Halvorsen does not address it.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read EU competition decisions on Adevinta/eBay Classifieds, Schibsted's spin-off rationale, and Nordic competition authorities' marketplace cases for the regulatory frame the conversation omits.
• incompleteThe autobiographical-prescriptive proposition ('do a good job where you are; opportunities follow; developer → product → business is the natural path') is presented without engaging the question of how much of Printzell Halvorsen's trajectory is reproducible vs. how much depends on McKinsey-as-accelerator, Norway's small leadership pool, and the specific historical moment of FINN. The advice may be more biographically contingent than it sounds.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read against the Cutler thread on what conditions enable senior individual-contributor-to-leader transitions inside specific organisations, and against literature on path-dependence in executive careers.
• incompleteThe MIT '95% of AI projects show no return' figure is asserted as foundational but never sourced, methodologically interrogated, or compared to base rates for non-AI IT projects (where failure rates are also famously high). The framing relies heavily on this number.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Pursue the MIT study directly (likely the MIT NANDA / Sloan AI 'GenAI Divide' report from 2025) and compare against Standish CHAOS-style baselines for IT project failure to establish whether AI is failing more than other IT initiatives, or merely the same.
• incompleteThe framing is almost entirely about knowledge-work software teams in professional services / large org settings. The argument is silent on: solo developers, small startups without team infrastructure, contracting/outsourcing relationships, non-developer roles where AI is also disrupting work, and contexts where 'team' is not the unit of production.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Read Tabarrok / Acemoglu on AI and labor markets in non-team-shaped work; and Beane's Skill Code on apprenticeship in mixed expert/AI environments outside software, to test how portable Brede Moe's prescriptions are.
• incompleteThe conversation treats AI tooling as relatively homogeneous — Copilot, ChatGPT, Cursor, Claude Code are mentioned as a cluster. But the team-level practices likely differ between chat-based assistants, autonomous agents, and in-IDE pair tools. Brede Moe gestures at this with 'augmented teams' but doesn't yet differentiate.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Empirical studies of differential effects by tool class — DORA's 2025 AI findings, Microsoft / GitHub research on Copilot effects, ongoing studies of agentic coding tools.
• incompleteThe car-factory study (cited as 15-20 years old) is the central empirical anchor for the slow-down-to-speed-up claim, but it is cited without source — the listener cannot evaluate the comparison. Similarly the 9-of-10 figure.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Source the original study; even if accurate, ask whether software development resembles auto-manufacturing learning curves enough for the lesson to transfer.
• incompleteThe argument assumes that team autonomy and team learning are the right units of analysis. It does not engage with alternative views — e.g. that AI might shift the unit back to the individual contractor or fragment work into smaller, more decomposable tasks, in which case the team-level prescription is the wrong response to the wrong question.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Read agentic-work literature (Eric Ries, Naval-style 'agency leverage' arguments, Yegge's vibe-coding manifesto) for the opposing view.
• incompleteThe article's prescription for a fully-authoritative, business-capability-owning team addresses internal team democratization in depth but says nothing about how multiple such autonomous teams coordinate with each other at organizational scale — precisely the cross-team problem (interaction modes, platform teams, Team API, fracture planes) that occupies most of the modern Team Topologies model.
  Thriving with complexity using open sociotechnical systems design — read next: Read against extract-team-topologies' interaction-modes and fracture-plane machinery (#p10, #p12) to see whether DP2's radical internal self-management and Team Topologies' designed inter-team interfaces are complementary layers or in tension over who retains coordination authority.
• incompleteThe entire piece assumes the reader has (or can act as if they have) management authority — budget sign-off, roadmap control, and a direct relationship with a CEO who asks for updates in 1:1s. It doesn't address a technical-track leader (staff/principal engineer, architect) who must drive the same adoption program through influence rather than authority — exactly the structural position many senior ICs occupy.
  Leading your engineers towards an AI-assisted future — read next: Pair with leadership material written for influence-without-authority roles, or Team Topologies-style material on how a non-manager drives cross-team change.
• illogicalThe piece argues both that AI's pace of change is unlike anything the author has seen in 20+ years, and that established change-management patterns from prior technology waves (DevOps, cloud, CD) will straightforwardly transfer — without reconciling why a genuinely unprecedented shift would be well-served by a non-unprecedented adoption playbook. The claim that 'proven methodologies' suffice is asserted, not argued against the claim of novelty made two paragraphs earlier.
  Leading your engineers towards an AI-assisted future — read next: Look for arguments specifically about what, if anything, is structurally different about AI adoption that would break a Mission Command-style rollout — e.g. the rate of tool obsolescence outpacing a Community of Practice's ability to stay current.
• practicalNo quantitative framework for when to invest in human scalability interventions. The talk says companies often come to Bravely at 100-150 people when employee surveys flag problems, but offers no guidance on investment timing, budget, or ROI metrics.
  Presentation: The Human Scalability Problem: Why Your Teams Don't Scale Like Your Code
• evidentialThe talk relies heavily on the Spotify squad model and Google Project Aristotle as examples, but these are well-known cases that may not generalize. No counter-examples are discussed — organizations that scaled human cooperation successfully without these specific interventions.
  Presentation: The Human Scalability Problem: Why Your Teams Don't Scale Like Your Code
• theoreticalDunbar's number is presented as a hard cognitive limit, but the speaker herself notes it was 'measured on neurotypical people' and is 'a guess.' The implications of neurodiversity for organizational scaling are raised but not explored.
  Presentation: The Human Scalability Problem: Why Your Teams Don't Scale Like Your Code
• practicalThe interventions (communication architecture, trust engineering, distributed cohesion) are presented as a menu of techniques without a theory of sequencing or prioritization. Which matters most at 50 people vs. 200 vs. 1000? The talk doesn't say.
  Presentation: The Human Scalability Problem: Why Your Teams Don't Scale Like Your Code
• incompleteThe panel's central, explicitly named 'never answered question' — what to centralize versus leave to team autonomy — is acknowledged but never engaged with any decision framework; the panel does not decompose it along governance, composability, or team-readiness axes.
  Presentation: Platform Engineering in the Age of AI — read next: extract-platform-engineering-golden-bricks, which proposes decomposing exactly this choice along governance/composability/team-autonomy axes (and whose own extraction flags the same decomposition as under-theorized).
• illogicalStephen argues both that platform teams must 'not tamp down innovation' and preserve developer freedom to build new infrastructure via an inner-source model, and that centralized, codified rules are 'supremely important' to prevent 'random infrastructure' chaos. The roundtable asserts both are needed but never explains how the inner-source boundary is actually drawn — who decides when a developer's local infrastructure becomes platform-owned versus stays local — leaving the same centralize-vs-autonomy tension unresolved in a different guise.
  Presentation: Platform Engineering in the Age of AI — read next: Reader's own experience with inner-source contribution models, or corpus pieces on team-topology contribution boundaries, for a concrete adjudication mechanism.
• incompleteThe four driver categories (strategic, personal, market, analyst) are presented as a taxonomy but never resolved when they conflict — the talk narrates the exact scenario of a strategic/partnership-mandated tool colliding with a team member's moral objection ('I don't support the political orientation of where this company is located') without saying how the conflict was actually adjudicated.
  Presentation: Platform Engineering for Everyone - Success Can’t Be Coded — read next: Corpus material on informal leadership and leader restraint for how leaders adjudicate genuine value conflicts within a team without either overriding the objector or letting one person veto a strategic commitment.
• incompleteTreats trust as a leadership-behavior problem (leaders should give trust, employees should accept accountability) rather than an org-design or contract/incentive problem. There is no mechanism design — no discussion of decision rights documents, RACI alternatives, equity/comp restructuring, escalation policies, or measurement systems that would make agency stick when individual managers regress to control. Pattern-matches to the HBR Managers AI Productivity Boom piece: name a structural problem, prescribe individual remedies.
  Your AI strategy has a trust problem, not a tooling problem — read next: Reinertsen, 'The Principles of Product Development Flow' (decision rights and queue economics); Hamel & Zanini, 'Humanocracy' (post-bureaucratic org design with explicit mechanisms); Laloux, 'Reinventing Organizations' (advice process as a contract for distributed decisions); Spotify's matrix history and post-mortems; works on internal markets for decision rights.
• incompleteThe accountability-and-comp argument is named but not operationalized. If ICs newly carry decision accountability, what is the manager premium for? She gestures at the tension and moves on. Without a comp/perf-review redesign, the agency upgrade is unilateral risk transfer.
  Your AI strategy has a trust problem, not a tooling problem — read next: Buurtzorg's flat-pay model; literature on profit-sharing and gainsharing; recent work on equity-as-accountability-comp in startups.
• illogicalThere is a quiet tension between 'centralize information' (named as a benefit reducing the need for middle managers to coordinate) and 'distribute decisions' (the agency thesis). Centralized information typically implies central gatekeeping; distributed decisions imply distributed access. The piece doesn't say what mechanism resolves the tension at scale — 'parented agents' is gestured at but not specified.
  Your AI strategy has a trust problem, not a tooling problem — read next: Conway's Law literature; works on platform engineering as context distribution; Team Topologies (Skelton & Pais).
• incompleteNo engagement with the failure modes of the prescription: pilot pods that become innovation theater; flat pods that recreate informal hierarchies; high-velocity decision-making that produces irreversible decisions before reflection (e.g. customer trust violations). The closing trust-based-growth move actually heightens this risk — fast public action with low oversight.
  Your AI strategy has a trust problem, not a tooling problem — read next: Failure-mode analyses of holacracy at Zappos; post-mortems on flat orgs (Valve, GitHub pre-2014); Karen Ho 'Liquidated' on what happens when decision velocity outruns institutional memory.
• incompleteLarson presents his own increasingly centralized decision-making ('I am the only person who can make binding decisions when teams disagree') as a feature of the current moment, but doesn't address the scaling risk this creates: concentrating binding authority in one person is itself a bottleneck and single point of failure, especially as headcount and surface area keep growing via the very acceleration the piece celebrates.
  Revised rules of engineering leadership. — read next: Pair with distributed decision-rights frameworks (e.g. mission-based leadership, DACI, team-autonomy models) to examine whether centralized fast decision-making can coexist with team autonomy at larger scale, or whether it's only a transitional phase.
• incompleteThe piece argues platforms (not universal upskilling) should safely contain citizen developers with tight constraints, yet also warns that forcing a unified platform process on engineers is too constraining and harms innovation; it does not reconcile how one platform can be tight enough for non-engineers and loose enough for expert engineers' identity and innovation.
  Looking back at the Future of Software Engineering unconference — read next: Read on platform-as-a-product tensions, extension points, and the golden-path-versus-team-autonomy balance.
• incompleteThe planned RQ3 controlled experiment explicitly excludes the 'proactive' loop condition (where the agent generates its own tasks), on the grounds that it makes it hard to establish a shared task set for comparison. But the discourse's most consequential value claims — Stripe's Minions, autonomous Firefox vulnerability triage — describe exactly this proactive, self-directed autonomy level. The planned study's eventual causal evidence, even once collected, will therefore not speak to the autonomy level the real-world claims of value are actually about.
  Loop Engineering: Building Blocks, Adoption, and Impact — read next: Compare against this corpus's other treatments of proactive/autonomous agent delegation (e.g., extract-own-the-outer-loop's 'agency ladder' and extract-human-oversight-is-not-a-human-in-the-loop's conditions for meaningful oversight) for how a study design might capture proactive-loop effects without a fixed shared task set.
• incompleteMerchant assumes co-decided ownership always produces better outcomes than directed change but never addresses contexts where it might fail — e.g., crisis situations requiring speed, organizations with deep expertise asymmetries, or cases where employees genuinely lack the context to contribute to strategic decisions. The ownership model may have boundary conditions she does not explore.
  New Skills to Navigate Continuous Change — read next: Gary Klein's work on naturalistic decision-making; research on when participatory vs. directive leadership outperforms.
• incompleteThe AI argument is instrumentally deployed to support her pre-existing thesis but is not seriously engaged. She uses a single data point (19% error rate) and does not consider how the argument changes as AI capabilities improve. The claim that question-formulation is uniquely human is asserted without defense.
  New Skills to Navigate Continuous Change — read next: Ethan Mollick's work on AI and organizational productivity; Karim Lakhani's full research (which Merchant cites but only partially).
• incompleteNo measurement framework for the intangible qualities she advocates (curiosity, creativity, collaboration). She identifies the measurement gap but does not close it. Leaders who want to implement her advice have no way to know if it is working.
  New Skills to Navigate Continuous Change — read next: Amy Edmondson's psychological safety measurement instruments; Teresa Amabile's research on measuring creativity in organizations.
• incompleteThe burnout question is acknowledged but not adequately addressed. In a world of continuous change where leaders must constantly tolerate discomfort, the sustainability question is critical. Merchant's answer (signal that rest matters) is necessary but clearly insufficient.
  New Skills to Navigate Continuous Change — read next: Christina Maslach's burnout research; Cal Newport on sustainable productivity.
• illogicalMerchant claims strategy arcs have shrunk to near-zero (citing Rita McGrath) while also claiming collaborative co-creation of strategy (which takes weeks) is the answer. There is a tension between 'the world moves too fast for long-term strategy' and 'we should slow down to co-decide.' She resolves this through the 'go slow to go fast' aphorism but does not seriously address the timing tension.
  New Skills to Navigate Continuous Change — read next: Rita McGrath's 'The End of Competitive Advantage' for the full argument on transient advantage and its implications for decision speed.
• incompleteThe Optimiser-vs-Learner distinction is reduced to a single axis — who owns the inbound work stream — yet the two designs also differ in team structure, risk profile (grey goo), and speed. Reducing them to one variable may oversimplify a genuinely multidimensional operating-model choice.
  Notes from FOSE Europe — read next: Read on operating models and team design (e.g. Team Topologies) to test whether the single-axis framing holds.
• incompleteThe two-sided contribution model is asserted -- users contribute, communities form, Genius Bar sessions draw teams in -- but never operationalized. How contribution is governed, who keeps quality from degrading as multiple teams contribute, how the producer (contributor) experience is designed, and how the platform team avoids becoming the bottleneck it replaced are all left open.
  How Open Source Enables Collaboration in Creating a Platform — read next: Platform-as-product producer-experience and governance (Evan Bottcher's platform-thinking work; Gregor Hohpe on platform architecture governance); Team Topologies on the enabling-team interaction mode and contribution/collaboration boundaries.
• incompleteThe org-design preconditions of 'ownership' are invisible. Trusting engineers to make real decisions and have real impact presumes decision rights, competence, and slack are already distributed to application teams -- and in a bank with support/accountability constraints, that redistribution is the hard, expensive part the article treats as already done.
  How Open Source Enables Collaboration in Creating a Platform — read next: Team autonomy / structured empowerment and mission-based leadership; Team Topologies on stream-aligned teams owning their flow; the political and capacity cost of pushing correctness, compliance, and decision rights down into teams.
• incompleteThe post withholds the one concrete example it invokes as proof of stakes ("gets into something much bigger than AI") — the actual mechanics of how Bayer folded AI into its 90-day-cycle model are entirely absent, deferred to a separate Thursday newsletter. As written, this is a teaser for an argument rather than the argument itself.
  Pim de Morree's Post — read next: Read the referenced Thursday newsletter (linked via https://lnkd.in/emN_R95n) for the actual case detail and the fixed-jobs argument.
• incompleteThe "fixed jobs" question — whether organizing people around fixed jobs still makes sense — is raised as the post's biggest idea but given zero content: no alternative structure is named, no criteria for when fixed jobs stop making sense, and no acknowledgment of what is lost (career ladders, accountability clarity, skill specialization) if jobs are replaced by rotating outcome ownership.
  Pim de Morree's Post — read next: Literature on outcome-based/results-only work design (e.g. ROWE) and on the trade-offs of dissolving fixed roles in favor of team-owned outcomes, plus this corpus's existing material on team autonomy and structured empowerment.
• incompleteThe 'golden path vs golden brick' distinction is rhetorical, not analytical. What actually changes when you move from path to brick? The article never decomposes the shift along the three axes where the shift really lives: (a) governance — who owns correctness, the platform team (path) or the consuming team (brick); (b) composability — who designs the assembly, and against what contract; (c) team autonomy — does the consuming team have the decision-rights, time, and skill to assemble well? Without this decomposition, 'bricks' is a slogan, not a model.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Skelton & Pais, Team Topologies (esp. platform team / stream-aligned team interaction modes). Camille Fournier's writing on platform teams. Gregor Hohpe on architecture decision records and IT architecture as conversation. Manuel Pais on the cognitive-load assessment.
• incompleteThe organisational shift the article requires but does not theorise. Bricks-not-paths only works in an organisation that has already pushed correctness, security review, cost ownership, and incident response down into stream-aligned teams. In an org where the platform team is also the compliance team and the on-call team, bricks-without-a-path means each stream team must reinvent guardrails. The piece treats this organisational redesign as free — but it is the actual hard part.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Cutler's TBM essays on institutional overload and accountability. Allen Holub's #NoAccountability work. Conway's Law re-readings (Skelton/Pais). Andrew Clay Shafer / DevOps adoption literature on the politics of platform ownership.
• incompleteStrawmanning of the golden path. In Spotify's original formulation and most current usage, a golden path is an opinionated default route through optional tooling — not 'the single way to do things.' Bryant collapses 'golden path' into 'golden cage' to set up the brick contrast, which makes the move feel sharper than it is. The real design choice is the ratio: which bricks ship with reference compositions (paths) attached, and which don't.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: The Spotify Backstage docs on golden paths. The 'paved road' material from Netflix engineering. Honeycomb's writing on opinionated developer platforms.
• incompleteNo treatment of the leaky-abstraction risk that the brick model amplifies. The more composable the platform, the more surface area developers can latch onto — and the harder it becomes to change the implementation later. Bryant raises leaky abstractions as a warning but never connects them to the brick model, which is precisely where they bite hardest.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Spolsky's original 'Law of Leaky Abstractions.' Ousterhout, A Philosophy of Software Design, on deep vs shallow modules — bricks must be deep modules or the abstraction tax is real.
• uninformedNo engagement with the actual maturity literature on internal developer platforms — CNCF Platforms Working Group whitepaper, Team Topologies' Thinnest Viable Platform concept, the platform-engineering maturity model from PlatformCon. The piece treats the field as if Bryant is naming things for the first time.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: CNCF Platforms WG whitepaper (2023+). Team Topologies' TVP material. McKinsey/ThoughtWorks platform engineering reports for the practitioner-economics view.
• uninformedThe book devotes a dedicated chapter to Remote Software Teaming, which this extraction did not analyze in depth — it is the one place the book directly engages with distribution, the default condition for many of the AI-era, geographically dispersed teams this corpus otherwise tracks.
  Software Teaming: A Mob Programming, Whole-Team Approach — read next: Re-read the 'Remote Software Teaming' chapter directly against current distributed/async-first team norms and tooling.
• illogicalThe paper treats 'evening out' individual performance as a possibly controversial but basically technical question (does the team lose value from suppressing star performers?) without considering that this is also an ethical/motivational question — whether star performers themselves experience mobbing as a demotion of their contribution, which could predict attrition independent of raw output effects.
  Mob programming: From avant-garde experimentation to established practice — read next: Read against retention/motivation literature on high performers in flattened, collectivized work structures.
• evidentiaryAll supporting evidence comes from retail, service, hospitality, and franchise contexts; the author acknowledges seeing 'similar principles' in other sectors but provides no cases outside these domains, leaving the framework's generalizability to knowledge-work, tech, or manufacturing undemonstrated.
  How Fast-Growing Companies Can Make Better Decisions
• methodologicalThe case studies are observational and retrospective; no controlled comparison or counterfactual analysis is presented. OXXO's tripling of stores and doubling of profitability is attributed to structured empowerment, but confounding factors (market growth, competitor dynamics, macroeconomic conditions) are not addressed.
  How Fast-Growing Companies Can Make Better Decisions
• conceptualThe boundary between 'structured empowerment' and well-designed delegation with guardrails is under-theorized. Many mature organizations already provide decision playbooks and measure outcomes; the article does not clearly distinguish where existing management practice ends and structured empowerment begins.
  How Fast-Growing Companies Can Make Better Decisions