Sociotechnical Architecture

Designing organization and technical architecture together — using Conway's law deliberately so team structure and system structure reinforce each other.

Also known as: sosioteknisk arkitektur (sociotechnical architecture), sosioteknisk arkitektur, sociotechnical architecture, sociotechnical system, socio-technical systems, reverse Conway, Reverse Conway maneuver, reverse Conway maneuver, Conway's law, agent topologies, symmathesy, open sociotechnical systems design, sociotechnical systems design, STSD, Tavistock, DP1 / DP2 design principles

How authors use it

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

Documents (34)

• DevOps Topologies Matthew Skelton (devopstopologies.com) · 2026-10-08 source ↗ Reader 🖥️
  There is no single universally correct Dev/Ops team structure for achieving DevOps's actual goal — improved delivery of customer and business value — because the right topology is contingent on an organization's product count (via Conway's Law) and on whether its Operations function has the capability and appetite to move from infrastructure-racking toward genuine value-stream alignment; a reference catalog of named anti-patterns and working patterns lets an organization diagnose and choose among structures rather than assume one conformation fits all.
• Collective problem solving in music, art, science, and software Jessitron · 2026-09-12 Reader 🖥️
  Great teams and great individuals are produced (not assembled from pre-existing talent) by group processes — camerata-like communities across music, art, science, and software — because such groups form a 'symmathesy': a living system of mutually learning people, tools, and (in software's unique case) the running software itself, and therefore growing individual and collective capability requires cultivating and sharing mental models within that system rather than optimizing individual output or hoarding recognition.
• 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.
• Coherence, Connections, and… Spacetime Crystals Art Anthony · 2026-09-09 source ↗ Reader 🖥️
  A technically well-performing API is close to worthless if it isn't coherent with the organization's goals, ownership, and structure — and because organizations and their APIs change constantly, that coherence has to be continuously mapped and re-established rather than achieved once and assumed to hold.
• From AI Code to Trusted Software: Harness Engineering in Practice Travis Frisinger · 2026-09-04 Reader 🖥️
  The bottleneck in AI-assisted software delivery has shifted from code generation to verification, so engineering effort should go into 'harness engineering': wiring an organization's standards into the repository itself (fail-closed gates, evidence attached to every change, cross-run observability) so the repository — not the model, and not a document nobody enforces — becomes the mechanism of trust, up to and including the repository taking on the shape of a governed mini-organization.
• TBM 434: How Maps Can Hide Problems John Cutler (The Beautiful Mess, Substack) · 2026-08-01 Reader 🖥️
  Organizational coherence — how cleanly an organization's separate 'maps' (goals, teaming, funding, ownership, technology) line up with one another — determines how much context can be left implicit; when the maps stop lining up, organizations tend to build sophisticated coping mechanisms (translators, fixers, tools, and now AI) that relieve enough of the resulting pain to let the underlying misalignment go unaddressed, so a map's proper use is not to be trusted or loved but to be read for where the gaps are and which of them are worth closing.
• AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action Ben Linders · 2026-07-30 source ↗ Reader 🖥️
  DORA's 2025 research reframes AI adoption in software development as an organizational-system problem rather than a tooling problem: AI amplifies whatever team dynamics already exist, and the return on AI investment comes from developing identifiable, data-derived capabilities (from a clear AI stance to quality internal platforms) matched to your team's actual profile, not from adopting the technology itself.
• The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices Prashanth Pasham · 2026-07-28 source ↗ Reader 🖥️
  By imposing an absolute rule -- never modify the legacy HCM monoliths again, only add new domain microservices -- and pairing it with three platform investments (self-service provisioning, an API-gateway routing seam, and a cached feature-flag rollback layer) that keep the resulting per-story cost tax affordable, a team can fund and execute a full monolith-to-microservices migration as a side effect of ordinary roadmap work, with no dedicated migration budget or program.
• TBM 432: Bundling & Unbundling Capabilities (and AI) John Cutler · 2026-07-26 Reader 🖥️
  A role is only a temporary bundle of capabilities that are themselves distributed across people, teams, tools, and institutions, and those capabilities are always moving -- specializing, diffusing, centralizing, integrating, embedding, rebundling, externalizing, or being eliminated or lost -- in overlapping loops rather than a single linear stage; AI does not change the underlying physics of these motions, only the magnitude, speed, and feasibility of each one, so the honest response to 'what does AI change' is a set of open, motion-by-motion questions rather than a single verdict.
• Presentation: Platform Engineering for Everyone - Success Can’t Be Coded Max Körbächer · 2026-07-20 Reader 🖥️
  Platform engineering succeeds or fails on product-mindset discipline — an explicit, negotiated purpose; principles that substitute for ad hoc decisions; continuous multi-layered measurement (SPACE/DevEx over DORA); disciplined technical-debt retirement; and a self-sustaining community — rather than on technology choices, because infrastructure-first thinking (a disposition most platform engineers carry from their DevOps/infrastructure backgrounds) causes teams to build for the tech instead of the people who must voluntarily choose to adopt it.
• Notes from FOSE Europe Giles Edwards-Alexander · 2026-07-07 source ↗ Reader 🖥️
  Five months into the agentic era the value of agentic engineering is now settled ('the evidence is in'), so the live frontier of the debate has moved from the tools themselves to the socio-organisational questions they raise — how to design your organisation (Optimiser vs Learner), where engineering rigour and human judgement now live, and how to coordinate agentic work across teams and enterprises — none of which is yet resolved.
• Trust Factory Kent Beck (Software Design: Tidy First?) · 2026-06-02 Reader 🖥️
  Extreme Programming was a 'trust factory' — its practices, principles, and values all produced trust as a byproduct of producing software — and AI-augmented ('genie') development is breaking this because it accumulates code far faster than it accumulates trust; the remedy is to deliberately slow augmented development so it manufactures trust the way XP did.
• 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.
• TBM 423: Why Defining Teams Is So Hard John Cutler · 2026-05-21 source ↗ Reader 🖥️
  Defining teams in product/tech orgs is hard not because the analytic skill is rare, but because honestly naming the gap between the aspirational org chart and how work actually flows threatens existing power, incentives, and narratives — so the work is political and emotional, not technical, and the goal should be to hold both views at once and act on the gap rather than collapse it.
• TBM 423: Why Defining Teams Is So Hard John Cutler from The Beautiful Mess · 2026-05-21 Reader 🖥️
  Honestly describing how teams actually work in product-and-technology organizations is cognitively easy but politically expensive, because the gap between the legible aspirational org chart and the lived collaboration reality is sustained by asymmetric incentives (cheap for product to redefine, costly for engineering to absorb, invisible to design) rather than by any lack of skill or insight — so the real organizational competence is the willingness to hold both views at once and work with the gap.
• 17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-05-18 source ↗ Reader 🖥️
  Large sociotechnical transformations — whether NAV's digital transformation a decade ago or the current AI shift — work by accumulating slow flywheel momentum that then snaps into a sudden S-curve climb through a high-friction liminal phase, and the leaders who guide organizations through such transitions are those who can 'take the elevator' across organizational floors and disciplines, translating between domain, technology and executive language while staying close enough to the craft that their advice is grounded in something real.
• The keyboard was never the bottleneck Mike Amundsen · 2026-04-16 source ↗ Reader 🖥️
  Generative AI commoditizes the lowest levels of programming work — producing code for known problems under fixed assumptions — but the harder, higher-level challenges of designing systems that survive change remain untouched and are now more visibly important.
• Technology Radar, Volume 34 Thoughtworks (Technology Advisory Board) · 2026-04-14 source ↗ Reader 🖥️
  AI-assisted, agentic software development is moving faster than the industry's ability to evaluate it, which means teams must simultaneously retain long-held craftsmanship principles (testability, deliberate design, feedback loops) and rethink team/agent topologies, trust boundaries and metrics that were built for a pre-agent world.
• 14) Øystein Ulseth pendler mellom å lede og levere Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-04-07 source ↗ Reader 🖥️
  The best technology leaders pendle (commute) deliberately between leading and delivering — driven not by career ambition but by the joy of building at the right level of abstraction — because crossing that boundary in both directions is what makes you precise: a hands-on background gives leaders pragmatism about complexity and trade-offs, while a leadership background gives builders the holistic, risk-aware perspective that lets them choose what to build.
• The Future Of Software Engineering Thoughtworks · 2026-02 Reader 🖥️
  As AI takes over code production, engineering rigor does not disappear but migrates to specifications, tests, constraints, risk management, and a new 'middle loop' of supervisory work — and organizations that fail to deliberately rebuild their practices, roles, and governance around these new destinations will suffer compounding losses in quality, comprehension, and stability.
• TBM 390: Governance by Principle, Not by Template John Cutler · 2025-11-23 source ↗ Reader 🖥️
  Governance should be built from first principles — context-specific risk management, accountability, evidence, and decision rights — rather than inherited from project/program templates and accounting-flavored false precision, because software investment is durable and dynamic rather than static and project-shaped; most organizations' governance is procedurally legitimate (defensible on paper) while failing the substantive test of actually serving investors, employees, and customers, and nothing in major governance frameworks (OECD, NIST, ISO 38500, etc.) actually requires projects or programs as the unit of governance.
• 1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-10-13 source ↗ Reader 🖥️
  What warrants the Steve Jobs analogy in Larsen's case is not product taste in a consumer sense but the disciplined construction of a 'strategic narrative' so concrete and personally believed that it can pull a large bureaucracy through a paradigm shift — and this only works when paired with a complementary engineering apparatus (reverse Conway architecture, cross-functional value streams, common components discovered rather than designed, a 'golden-path' platform that makes the right thing the easy thing) operated by a leader who keeps an 'inngangsbillett' to the technical conversation so that the narrative remains connected to what is actually happening on the floor.
• Agents don't know what good looks like. And that's exactly the problem. Luca Mezzalira · 2025-01-01 source ↗ Reader 🖥️
  Agentic AI systems lack the judgment to distinguish correct behavior from merely passing checks, which means that deterministic architectural guardrails — fitness functions, capability verification, explicit boundary definitions — are not optional but imperative; and the sociotechnical readiness of the humans and organizations that must own the generated systems is the overlooked bottleneck.
• Optimizing teams: A dual perspective on Team Topologies Elias Lieberich · 2024-09-26 source ↗ Reader 🖥️
  Team Topologies' four-type model is a useful starting vocabulary, but both authors argue that applying it well requires practical, product-aware judgment calls it doesn't itself supply — Lieberich's engineering-facing checklist (well-defined scope, disambiguated boundaries, minimal dependencies) and Wille's product-facing one (small teams, end-to-end ownership of a user journey, splitting by product/user-group/value-moment/funnel-stage rather than by technology) — because the book's own categories never fully resonated with a product-management, rather than engineering, view of where team boundaries should fall.
• 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.
• Generative AI Is Not Going To Build Your Engineering Team For You Charity Majors · 2024-06-10 source ↗ Reader 🖥️
  Generative AI accelerates the easy, narrow, disposable part of software engineering (writing code) but does nothing for the hard part (building and operating the sociotechnical systems code lives in), so it cannot substitute for hiring and apprenticing junior engineers — teams, not individuals, are the real unit of software ownership, and starving the junior pipeline is cannibalizing the industry's own future senior engineers.
• 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.
• 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.
• Sociotechnical Architecture as Enabler of Product Thinking Eduardo da Silva · 2021-04-30 source ↗ Reader 🖥️
  An organization can only achieve Product Thinking's goal — maximizing continuous, high-velocity value exchange with the customer — by holistically co-designing three interrelated systems together (the customer/market, the teams/organization, and the software architecture), a discipline the author names Sociotechnical Architecture, building on Conway's Law, Team Topologies, and Ackoff's Systems Thinking.
• Team Topologies: Organizing Business and Technology Teams for Fast Flow Matthew Skelton & Manuel Pais · 2019-09-16 Reader 🖥️
  Sustainable, fast software delivery requires organizations to treat team boundaries, responsibilities, and interactions as a deliberately designed, continuously evolving system — using each team's cognitive load as the limiting constraint on what it can own, and Conway's law (via the reverse/inverse Conway maneuver) as the lever for aligning architecture to the team structure an organization actually wants — rather than treating team shape as an accident of historical org charts and project-based reorganizations.
• Software Engineering at Google Fergus Henderson · 2019-02-19 source ↗ Reader 🖥️
  Google sustains software velocity and quality at extreme scale (2+ billion lines, one repository, thousands of engineers) not through any single tool or policy but through a mutually reinforcing system of technical infrastructure (a single trunk-based monorepo, hermetic reproducible builds, and mandatory same-day code review) and organizational design (separated engineer/manager career tracks, OKRs deliberately decoupled from pay, 20% time, and periodic full rewrites) that together manufacture trust, ownership, and continuous renewal.
• What good software looks like at REA Alison Rosewarne · 2018-06-12 Reader 🖥️
  What makes software 'good' at REA is not a single abstract ideal but three concrete, criteria-based lenses — dev (changeability), ops (operability), and arch (bounded responsibility) — that the teams who own each system rate themselves against on a recurring basis, so architectural quality becomes an organizationally-supported habit rather than a one-time design decision.
• Software Design X-Rays Adam Tornhill · 2018-03 source ↗ Reader 🖥️
  The real cost and risk in a large codebase is invisible in the code's current structure and can only be recovered by mining version-control history as a behavioral record of how people actually work on it — and once recovered (as hotspots, change coupling, code age, developer fragmentation, and knowledge maps), that record should drive both technical refactoring priorities and the alignment of team structure with system structure (Conway's Law), because most expensive software problems are organizational problems wearing a technical disguise.

Propositions touching this concept (18)

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

2018-03

• explicitModular boundaries aligned with problem-domain concepts, rather than solution-domain/technical layers, give each team natural end-to-end ownership and let architecture scale with the organization; technically oriented architectures instead force either universal cross-team coordination or single-team ownership bottlenecks — this is the operational content the book draws out of Conway's Law.
  Software Design X-Rays · p16

2019-09

• explicitcorroboratedConway's law holds: the architecture of a system mirrors the communication structure of the organization that produces it.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p1

2021-04

• explicitConway's Law holds — a system's architecture mirrors the communication structure of the organization that designs it — so a product's team setup must be deliberately aligned with the architecture ambitions for the product.
  Sociotechnical Architecture as Enabler of Product Thinking · p1
• explicitAchieving Product Thinking's goal requires holistically co-designing three interrelated systems together — the Customers/market ('What'), the Teams/organization ('Who'), and the Software Architecture ('How') — rather than optimizing any one in isolation; this co-design practice is what the author calls Sociotechnical Architecture.
  Sociotechnical Architecture as Enabler of Product Thinking · p5
• explicitSociotechnical Architecture does not require full upfront design of all systems together; it requires feedback loops ('sensors') on the structural elements, visible properties, and relations of the What/Who/How systems sufficient to ground decisions, preserving each part's execution autonomy.
  Sociotechnical Architecture as Enabler of Product Thinking · p6

2022-01

• explicitOptimizing the technical side of a sociotechnical system in isolation produces a dehumanizing work environment, while optimizing the social side in isolation prevents the technology from reaching its potential.
  Thriving with complexity using open sociotechnical systems design · p2

2025-10

• explicitdevelopedReverse Conway — design the architecture first, then place the organisation on top of the architecture you want — is the right sequencing because the exercise's purpose is to remove coordination need.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs · p16

2026-02

• explicitdevelopedConway's Law applies to agents — organizational design must now account for agent mobility, specialization, and drift
  The Future Of Software Engineering · p9

2026-04

• explicitOrganisation and architecture cannot be designed independently of each other — Conway's law makes the org-shape the architecture-shape, so the sociotechnical view is the only honest one at scale.
  14) Øystein Ulseth pendler mellom å lede og levere · p12
• explicitdevelopedTeams must rethink how they collaborate and structure themselves for agentic systems — considering agent topologies alongside existing team topologies and rethinking feedback cycles accordingly.
  Technology Radar, Volume 34 · p4

2026-05

• explicit⚡ disputed & corroboratedArchitecture is a hard constraint on how fast teams can be realigned; the reverse Conway maneuver underestimates this.
  TBM 423: Why Defining Teams Is So Hard · p3

2026-06

• explicitcorroboratedSoftware is a symmathesy — a human-technical system you can only influence, not control — so 'the program is the truth' was an overclaim.
  Trust Factory · p8

2026-07

• explicitDeliberately using Conway's Law — building the ideal platform workflow and then changing the organization's processes to follow it, rather than accepting existing process as fixed — is one of the most effective, though slow, levers for platform adoption.
  Presentation: Platform Engineering for Everyone - Success Can’t Be Coded · p18

2026-09

• explicitA software system together with its developers forms a symmathesy: a learning system of learning parts, in which the software learns from developers (because they change it) and developers learn from the software (via its error messages, logs, and behavior).
  Collective problem solving in music, art, science, and software · p4
• explicitSoftware is categorically different from craft (competence-based, guild-like trades) and from art (a completed, individually-authored work): it is a new category — an always-unfinished, larger-than-one-person, world-affecting, continuously-changing sociotechnical system whose practice is symmathesy itself.
  Collective problem solving in music, art, science, and software · p11
• implicitBringing one's 'whole self' to work is instrumentally important because a symmathesy requires its members to be genuinely alive/present in the system in order for the system to learn and grow.
  Collective problem solving in music, art, science, and software · p13
• explicitA sufficiently harnessed repository starts to take on the structure of an organization — an instance of Conway's Law running in reverse, where the software's enforced rules and evidence trails shape organizational structure rather than the other way around.
  From AI Code to Trusted Software: Harness Engineering in Practice · p16

2026-10

• explicitcorroboratedThe number of products an organization maintains affects which topology fits: fewer products make Dev/Ops collaboration easier because there are fewer natural organizational silos, as Conway's Law predicts.
  DevOps Topologies · p3

Tensions

Open gaps (89)

• unasked questionThe essay uses the Dreyfus model to characterize agents as novice/advanced-beginner but never asks whether the Dreyfus model, developed for human skill acquisition, is even the right frame for AI systems that learn in fundamentally different ways. Agent capabilities may not map onto a linear human progression scale at all.
  Agents don't know what good looks like. And that's exactly the problem. — read next: Literature on AI capability evaluation frameworks that are not anthropomorphic (e.g., benchmarks, formal verification, capability elicitation research).
• implicit premiseThe argument that 'more context degrades output' treats current LLM context-handling limitations as a stable architectural constraint rather than a temporary engineering limitation. If context handling improves significantly, the 'deterministic guardrails' prescription may need rebalancing.
  Agents don't know what good looks like. And that's exactly the problem. — read next: Research on long-context model performance, retrieval-augmented generation, and structured context management.
• incomplete'Value designs organization' is presented as a one-way causal claim (the shape of value determines organizational structure), but the piece never addresses the converse feedback loop — that existing organizational structure and political incentives shape which value flows are even recognized, funded, or pursued in the first place. This is exactly the two-way causality the reverse-Conway-maneuver literature grapples with (deliberately using Conway's Law in either direction).
  Beyond Autonomous Teams in Software Product Development — read next: extract-heis-01-torbjorn-larsen-naermeste-vi-kommer-steve-jobs#p16 (reverse Conway: design architecture first, then place org on top) and extract-korbacher-platform-engineering-product-mindset#p18 (deliberately using Conway's Law to reshape org)
• 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
• illogicalThe closing claim that networking lets teams 'deliver value without needing to traverse the hierarchy' risks conflating informal lateral coordination with actual decision rights, budget authority, and accountability, which typically remain hierarchical even when day-to-day coordination becomes networked. The piece treats bypassing hierarchy as an unqualified good without engaging the possibility that hierarchy persists for reasons (accountability, resource allocation) that a purely networked value-delivery model doesn't replace.
  Beyond Autonomous Teams in Software Product Development — read next: the corpus's hierarchy concept, esp. framing of hierarchy as structurally inevitable in groups rather than an artifact that networking simply dissolves
• uninformedThe piece covers almost identical territory to Team Topologies (stream-aligned teams, team-level cognitive load, dependency-driven team design) without engaging that vocabulary at all — a well-known adjacent framework whose terms (e.g., 'stream-aligned team' vs. 'value center') could sharpen or challenge Rohrer's coinage, or reveal it as a rebranding of existing ideas.
  Beyond Autonomous Teams in Software Product Development — read next: extract-tbm-423-defining-teams and extract-tbm-434-how-maps-can-hide-problems (Team Topologies material already in the corpus)
• uninformedThe essay treats the Camerata's ignorance of actual ancient Greek musical practice as a harmless, even useful, legitimizing fiction ('like citing computer science papers from the 70s'), without engaging with the epistemic risk that such founding myths pose when a group's shared 'ground truth' is simply wrong — a risk directly relevant to software teams whose shared mental models can be confidently wrong in the same way.
  Collective problem solving in music, art, science, and software — read next: Work on how groups sustain false shared beliefs / groupthink despite (or because of) shared practice and mutual reinforcement — e.g., organizational research on 'espoused theory vs. theory-in-use' (Argyris), or on collective illusions.
• incompleteThe claim that software is categorically neither craft nor art but something wholly new ('the next thing after the Renaissance') is asserted through rhetorical contrast rather than argued: the essay does not consider that software might instead be a hybrid or a special case of pre-existing categories (e.g., infrastructure/engineering systems like power grids or air-traffic-control systems, which are also continuously-running, larger-than-one-person, world-affecting sociotechnical systems) rather than something genuinely unprecedented.
  Collective problem solving in music, art, science, and software — read next: Comparative work on other continuously-operated, never-finished sociotechnical infrastructures (aviation, power grids, financial-market systems) and resilience-engineering literature (Woods, Hollnagel) that already treats these as symmathesy-like joint cognitive systems, which would question the 'software is the first' framing.
• incompleteHazel never explains the actual mechanism by which an architect builds 'coherent autonomy' structures beyond restating the goal itself (give people decisions they don't need to check in on, while also building the mechanisms by which they check in 'naturally'); no concrete practice, cadence, or structure is named for how check-ins stay both 'natural' and 'intentional' at any real scale (a 10-person team vs. a 500-person org).
  Software Development As Collective Learning With Hazel Weakly — read next: Team Topologies / sociotechnical-architecture material elsewhere in the corpus with concrete reverse-Conway and team-interaction-mode mechanisms, to see what specific structures operationalize the coherent-autonomy goal Hazel names but doesn't detail.
• incompleteThe article explicitly defers 'how to implement these ideas' and 'who should do this' to other articles in the author's broader Sociotechnical Architecture series, some of which were still unwritten at publication — so the holistic framework is argued for conceptually but not demonstrated through an implementation case study beyond the illustrative Restaurant Product analogy.
  Sociotechnical Architecture as Enabler of Product Thinking — read next: The author's later Sociotechnical Architecture and Systems series, if subsequent installments addressing implementation exist.
• incompleteWritten in 2021, the article's 'Who' system implicitly assumes all team participants are human — team setup, cognitive load, and Conway's-Law communication structures are all framed in human terms — and does not anticipate AI coding agents as 'Who' system participants, a gap this corpus's AI-era material (Team Topologies' own later acknowledgment, DORA's AI capabilities model) has since had to address directly.
  Sociotechnical Architecture as Enabler of Product Thinking — read next: extract-team-topologies#p21 (the book's own acknowledgment that its four-topology taxonomy assumes human team members) and extract-dora-ai-team-profiles-and-capabilities.
• illogicalThe claim that siloed/local optimization 'almost never' maximizes overall customer value is asserted via Ackoff's systems-thinking authority and the restaurant analogy, not demonstrated through a comparative case (siloed optimization tried and found wanting versus holistic co-design succeeding under otherwise comparable conditions).
  Sociotechnical Architecture as Enabler of Product Thinking — read next: extract-dora-2024-accelerate-state-of-devops for metrics-based evidence on this trade-off.
• incompleteThe page's visual taxonomy of seven named anti-types (A-G) and the numbered team topologies is represented in this capture almost entirely through bare image filenames without the descriptive text that normally accompanies each pattern on the live site. Only Anti-Type B, Type 1, and Type 3 receive even a one-line gloss here (via the Sweeney attribution); the remaining anti-types and types (including the three the author claims as original additions — Shared Ops, DevOps-as-a-Service, Temp DevOps Team) are named but not defined in the extractable text.
  DevOps Topologies — read next: The live site (web.devopstopologies.com) or Skelton & Pais's book-length successor (already in this corpus as extract-team-topologies) for the full definitions.
• incompleteThe catalog names roughly a dozen patterns as the apparently sufficient reference set, but doesn't address why this particular granularity (rather than fewer or more categories) is the right level of abstraction — a question the author's own later work (Team Topologies) answers by collapsing the field down to exactly four fundamental topologies plus three interaction modes.
  DevOps Topologies — read next: extract-team-topologies#5 (the 'exactly four fundamental team topologies' claim) directly revisits and resolves this.
• incompleteThe report's 'team performance' and 'organizational performance' factor scores are coarse composites; it does not examine whether specific team structures (team size, dedicated platform teams vs. embedded, degree of autonomy) moderate how AI adoption affects delivery stability — a gap directly relevant to a team/org durability lens.
  2024_final_dora_report — read next: Team-topology- or team-structure-specific empirical work on how AI adoption's delivery-stability cost varies by team design, rather than by adoption percentage alone.
• incompleteThe central 'repo becomes a mini-organization / Conway's Law in reverse' claim rests on exactly two examples, both author-affiliated: his own single-operator software factory and HydraFlow, 'our research system.' There is no independent replication, no failure case, and no discussion of whether or how the pattern holds at multi-repo, multi-team, or cross-organization scale.
  From AI Code to Trusted Software: Harness Engineering in Practice — read next: Third-party case studies or post-mortems of harness-governed repositories at genuine multi-team/enterprise scale, not single-operator 'factories,' to test whether the organizational-emergence claim generalizes.
• uninformedThe retail case study and the distributed-ownership argument assume each skill maps cleanly to one owning domain team, but does not address what happens when two teams' skills legitimately compete for the same trigger (overlapping description keywords) in a large, many-team organization — a scaling failure mode distinct from the four it names (trigger, execution, token budget, regression), closer to a governance/arbitration problem than a technical one.
  Agent Skills — read next: Read against software-architecture literature on team-boundary design (e.g. Conway's Law, bounded contexts) applied to skill ownership rather than service ownership.
• incompleteThe binary 'migrated' metric requires 100% of traffic for 30+ days, but the article never addresses what happens when a fraction of traffic must legitimately stay on the monolith forever (e.g. an old partner integration that will never be upgraded) -- is that endpoint simply never declared migrated, indefinitely, with no path to closing it out?
  The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Look for practitioner writing on managing the migration 'long tail' of clients who cannot upgrade -- API deprecation and sunset strategy literature -- to see how others resolve the tension between a strict binary completion metric and an unmigratable minority of traffic.
• illogicalThe article's own claimed most important factor for success -- the organizational moves (code-review gate, seam-map review, upfront-tax tracking) -- receives a small fraction of the article's length and appears only in the closing section, while the great majority of the space is spent on technical platform mechanics (APIM, feature flags, ingestion architecture, autoscaling). This leaves the 'org moves mattered more' claim as an unsupported assertion rather than a demonstrated argument, in tension with what the article actually spends its evidence on.
  The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Cross-read against extract-the-organization-is-the-bottleneck and extract-agents-dont-know-what-good-looks-like, which argue more directly and at length that organizational/cultural discipline -- not technology choice -- is the actual bottleneck in microservices adoption; that reading may supply the argument this article asserts but does not build.
• incompleteBoth headline numbers -- the ~70% peak-cost savings and the ~50% (4-to-6-hour) upfront tax -- are presented as stable constants across five years, but cloud pricing, wages, and story complexity plausibly shifted substantially between 2021 and 2026; the article gives no methodology or time series, only single-point averages, so a reader cannot tell whether either ratio actually held steady or drifted.
  The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Look for any published time-series cost or velocity data from Paycor/Paychex, or for other companies' cost-optimization case studies with longitudinal tracking, to see whether single anecdotal ratios of this kind are durable enough to reuse as planning assumptions.
• incompleteThe 90-day plan and the 'what to standardize before service #2' prescriptions assume the reader already has, or can obtain, enough organizational authority to impose a company-wide 'stop changing the monolith' rule and sustain it against delivery pressure for years; the article never addresses how to acquire that mandate in an organization skeptical of an architecture edict with a visible short-term tax and a multi-year payoff horizon.
  The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Pair with organizational-change and stakeholder-buy-in literature on selling a long-payoff technical investment against quarterly incentives, to fill the gap between 'here is the plan' and 'here is how you get permission to run it.'
• incompleteThe coherence-risk mitigation (consultation + AAF + principles) is never stress-tested against a scenario where the number of autonomous teams is very large, or where teams are geographically/organizationally siloed enough that the 'everyone meaningfully affected' consultee list becomes unknowable rather than just long.
  Scaling the Practice of Architecture, Conversationally — read next: See Team Topologies for how team-shape and interaction-mode choices interact with this kind of decentralized governance at larger scale.
• uninformedNo engagement with the Resilience Engineering academic tradition (Hollnagel, Woods, Dekker), which has spent 20+ years arguing resilience is the adaptive capacity of a sociotechnical system — not something that can be 'owned' by a single accountable executive. The article reads as if this body of thought does not exist.
  The Case for Hiring a Chief Resilience Officer — read next: Hollnagel, Woods & Leveson, 'Resilience Engineering: Concepts and Precepts'; David Woods' lectures on graceful extensibility.
• incompleteThe piece gives no treatment of incentives or political economy: why would senior partners, rainmakers, or otherwise entrenched leaders willingly submit to peer-enforced standards and give up autonomy? No discussion of resistance, power, or what happens to leaders who refuse to comply appears anywhere, including in the case study, where the two-day forum and board-governance reset are described as succeeding without any account of who resisted or what it cost them.
  How to Turn Individual Talent into Organizational Excellence — read next: extract-cutler-ai-wont-save-kingdoms directly engages the political-economy angle this piece elides — fiefdoms persisted 'despite visible pain' because leaders were unwilling to prioritize across them and fief-leaders had self-interest in preservation; the 'real' fiefdom problem is political-economic, not informational.
• incompleteThe article closely resembles a McKinsey/BCG/Bain-style three-bucket framework (Talent/Team/Routine) complete with named leadership roles (CEO/BU leader/CHRO) and a single glossy, anonymized case study — offering little that couldn't be reframed via existing organizational-design or sociotechnical-systems literature, none of which it cites.
  How to Turn Individual Talent into Organizational Excellence — read next: Compare against John Cutler's more skeptical, coordination-cost-and-incentive-grounded treatment of essentially the same 'systems, not individuals' claim (extract-cutler-ai-wont-save-kingdoms) for a version of the argument that engages the frictions this piece elides.
• incompleteThe Jobs analogy is named but not fully cashed out against its disanalogies. Jobs's reality distortion field was famously paired with cruelty, factional purges and product taste applied to consumer aesthetics. Larsen's framing is the opposite — toppdivisjon-ledelse runs on indre motivasjon, not fear; authenticity / easy-to-read-ness is the asset; the product is a public-sector welfare system. The conversation does not name these disanalogies, so the analogy carries more rhetorical work than it earns.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Read Walter Isaacson's Jobs alongside Tracy Kidder's Soul of a New Machine and Marc Andreessen-tradition writing on charismatic founder leadership to surface the disanalogies; for the NAV case specifically, read Cutler on 'institutionalized overload' to see what indre-motivasjon-based mobilisation can hide. Connects to the gap in the Skjærpe ep 17 extract on transformations that fail in the liminal phase.
• incompleteThe NAV transformation is described entirely from the inside by one of its architects. There is no counterfactual: comparable Norwegian agencies that did not transform similarly, post-Larsen reversion at NAV, what failed within NAV and why. The 'hagiography risk' the hosts flagged is real and unexamined.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Compare Skatteetaten, Statens Pensjonskasse, Helsedirektoratet trajectories during the same period; read the NAV-flow article in the user's library (Optimizing for Fast Flow in NAV) for the inside-but-different-author view; read the Skjærpe ep 17 extract for the immediate-successor's view from inside the system. Look for what the NAV transformation displaced or made impossible (e.g. casualties among legacy fagsystemer staff).
• incompleteThe 'common components are discovered, not designed' thesis is asserted with the NAV fakturering case as the load-bearing example, but the inverse failure mode (premature divergence — many verticals each solving the same problem badly because no one promoted the pattern to the platform) is acknowledged in passing ('we have capabilities in the platforms that strictly speaking are only needed one or two places ... it is a little behagelig that it got fixed over there') without being theorised. The position is one-sided.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Read the Wardley Mapping / pioneers-settlers-town-planners tradition for an explicit account of when components should be designed up front (the 'industrialised' part of the map). Read Cutler on 'horizontal team accountability' for how teams refuse to own platform-like problems they should own. The Vipps ep 18 extract may have a relevant view from the perspective of an organisation that did design infrastructure up front.
• incompleteThe 'easy to read' / authentic-leadership claim collides with the strategic-narrative claim. Strong strategic narrative is itself a construction; sustained reality-distortion presupposes some performance discipline. The conversation treats easy-to-read-ness and disciplined narrative as compatible without examining the tension. When does the constructed narrative cross into managed-impression territory, and what is the leader's check on that?
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Erving Goffman's Presentation of Self; Edgar Schein on the discrepancy between espoused theory and theory-in-use; Bent Flyvbjerg on narrative in megaprojects (where the same person both believes and constructs the future). The Cutler 'signals that look like decisions' thread is also relevant — for an easy-to-read leader, even contemplative musings can be read as commitments.
• incompleteThe inngangsbillett method is a personal description, not a teachable account. Larsen says he spends 'many hours a day' on craft and uses the hermeneutic-circle approach, but does not name which key terms, which structural maps, which sources, or how to know when the inngangsbillett is sufficient for a given fagdomene. The 'Fred George reads no books, he talks to authors' punchline gestures at one upper-bound technique but leaves the floor undefined.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Hubert Dreyfus's five-stage skill model (novice → expert) for a more precise grammar of 'how much do I need to know'; Cal Newport's deep work / deliberate practice tradition; the recent harness-engineering and AI-coding research extracted in this repo on what 'understanding a system' actually requires before AI can help you scale that understanding.
• uninformedThe conversation invokes Peter Senge's learning organisation as one of the three common denominators of Larsen's narrativer but does not interrogate how durably the organism-organisation framing has held up under real conditions over the 30 years since Fifth Discipline. There is a tradition of critique (e.g. Mintzberg on the messiness of organisational learning; recent operations-research literature on actual learning loops in software organisations) that the conversation does not engage with.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Mintzberg's Rise and Fall of Strategic Planning; Argyris on double-loop learning vs Senge's framing; the more recent DORA / Accelerate research on what kinds of learning actually correlate with performance — and what kinds (e.g. 'just keep adapting') do not.
• incompleteThe episode ends on Larsen's most quotable problem — moving from project mindset to outcome-driven verdistrøm-mindset — but does not specify what makes this so hard at Telenor specifically. Is it inherited governance? Board reporting cadence? Career incentives for people who have always shipped to scope? The hosts move on. This is the single most actionable place the conversation could have gone deeper.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Cutler on outcome-orientation and operating-system design; Marty Cagan's 'product team vs feature team' distinction; the Una Aamodt-Mathisen ep 10 extract (lede uten fasit) likely has direct material on the same problem at a different scale. The Vidar Moe ep 5 ('det eneste Vidar vil er å ha det lett') may have a relevant view on operating-model simplification.
• incompleteThe hagiography risk is structural: Truls worked for Larsen, Audun met him at a formative moment, both are visibly inspired. The format does not include any adversarial pressure. The episode is therefore best read as Larsen's self-presentation lightly facilitated by admirers — strong as primary source, weak as evaluation.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: For an evaluation lens, read external accounts of NAV's transformation (audit reports, Riksrevisjonen, Aftenposten / NRK coverage of NAV IT projects during the Larsen era), and look for counter-narratives in the Norwegian public-sector tech community. Compare to Holte ep 2 (the senior public-sector counterpart) for a different view of the same period.
• incompleteScale dependence of pendling. The whole career story plays out inside two large Norwegian financial-services organisations (Storebrand, Fremtind) that recognise technical depth as legitimate seniority. The conversation never tests whether pendling is feasible — or how it changes shape — in small startups (no role to come back to), pure consultancies (the IC vs. leader frame may not apply), public-sector hierarchies (rigid grade structures), or US-style stock-comp tracks where stepping back is also stepping out financially.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Pair with Charity Majors' 'Engineer-Manager Pendulum' original essay to see her conditions for it working; pair with Will Larson on staff-engineer archetypes for the IC-track question; pair with Norwegian-public-sector accounts (NAV optimising for fast flow) for the bureaucracy edge case.
• incompleteThe people who can't pendle. Ulseth's account is sympathetic to both directions but assumes the listener has the option of swinging both ways. It does not address those who are only-leaders (lost technical currency) or only-deliverers (no taste for organisational complexity) — and whether they should be coached, paired, or left in their lane. There is a real possibility that pendling is a personality privilege as much as an organisational one.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Camille Fournier on technical-leadership transitions; Cutler on the costs of forcing technical contributors into managerial roles; Allen Holub on accountability and the limits of role-fluidity.
• incompleteThe architect's function is never defined. The talk asserts that architecture has not changed in its core function, only in practice — but it does not say what the function is. The closest thing to a definition is 'enabling speed and flow via loose coupling and high cohesion', which is more a goal than a function and which collapses architecture into platform engineering in some readings.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Vlad Khononov on coupling in distributed systems; Ruth Malan on architecture as 'the design decisions that are hardest to change'; Team Topologies for the sociotechnical framing Ulseth invokes.
• incompleteBredde/dybde sounds clean but is operationally underspecified. How does a sjefsarkitekt choose which initiatives to take as 'mine'? Ulseth nods that they should be 'both important and interesting' and that the two usually overlap — but the harder cases (important-but-boring, interesting-but-marginal) are not discussed. This is the place where pendling-by-design either works or quietly collapses into one side.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Cutler on how leaders allocate attention; deep-dive into 'staff-plus' patterns where senior ICs balance technical and political work.
• incompleteThe claim that AI raises the incentive to live good engineering culture is asserted but not mechanised. Continuous delivery has been well-described for 20 years and only patchily adopted. Why will AI succeed in changing this where the prior decade's tooling, DORA reports, and platform engineering did not? A causal story is missing.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: DORA 2025/2026 specifically on AI's interaction with delivery practices; Birgitta Böckeler and Martin Fowler on AI-coding feedback loops; Kent Beck's TCR work as the practice end of the same idea.
• incompleteNo data on whether pendling actually produces better outcomes. The argument is largely 'I felt better and have heard I do better.' The episode lacks any reference to organisational research on whether engineer-manager pendulum careers correlate with better team or product outcomes — and whether the benefits go to the individual, the team, or the organisation.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Pragmatic Engineer / Newcomer on staff-plus role outcomes; LeadDev surveys on engineer-manager transitions; academic work on bidirectional career mobility in knowledge work.
• uninformedUlseth notes he has not yet seen conversational architecture practiced and that sociotechnical architecture is a new acquaintance — yet these are the frameworks he is now bringing into Fremtind's IT strategy. The talk does not engage seriously with the published critiques of these models (e.g. that Team Topologies under-specifies platform-team funding, or that Harmel-Law's model assumes a maturity teams may not have).
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Andrew Harmel-Law's own book and the Architecture Decision Records literature; critical reviews of Team Topologies (Manuel Pais et al.).
• incompleteThe flywheel/S-curve/liminal frame is used to describe both the NAV transformation (which succeeded) and the AI shift (in progress). The conversation never names a transformation that failed at the liminal phase and asks why — so the framework is at risk of being unfalsifiable on its own terms.
  17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis — read next: Read failed transformations through the same frame — e.g., government-IT projects that died in their liminal phase, large agile adoptions that reverted. Cutler's overload work and the 'people who tried Spotify model' literature would expose where the frame breaks. The Geoffrey Moore 'Crossing the Chasm' tradition has more developed accounts of curves that stall.
• incompleteThe 'learning vs production' rule is stated as a personal heuristic but not connected to any educational theory or empirical evidence. For a leader of consultants asked to scale this practice, there is no model for how the two modes should be partitioned, whether across days, projects, or moods.
  17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis — read next: Donald Schön's reflection-in-action; deliberate-practice literature (Ericsson); Beck's 'tidy first?' framing of preparatory vs delivery work — the tidy/messy split echoes the learning/production split structurally. Worth syntopical pass against Beck's recent 'Starving Genies' work on AI-assisted craft.
• incompleteThe elevator metaphor is generalised from Jonas's own career and from the show's animating premise. The conversation does not seriously consider organisations where vertical traversal is structurally suppressed (military, regulated finance with information walls, classified environments). The implicit premise that elevators are always available may not hold.
  17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis — read next: Read about organisations with designed information barriers — security classifications, MAR-walled investment banking, healthcare compartmentalisation. James C Scott's 'Seeing Like a State' on legibility. Where the elevator is locked, what substitutes?
• incompleteThe introvert-leader claim rests on one practitioner's experience and one rhetorical contrast (scale removes small-talk tax). Jonas notes that some colleagues found it hard to distinguish his opinions from his decisions — a cost that may be specifically introvert-shaped (lower social-cue density) but is not investigated.
  17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis — read next: Susan Cain on introvert leadership; the Cutler thread on 'signals that look like decisions' in leadership communication. The implicit problem of 'low-cue leadership at scale' is worth its own extraction.
• incompleteThe tractor and car analogies argue for slow structural change, but neither is examined for disanalogies. AI compresses learning loops in a way physical machinery cannot. The argument relies on the assumption that adoption is gated by humans, not by capability — which is plausible but not defended.
  17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis — read next: The general-purpose-technology economics literature (Bresnahan & Trajtenberg); David Autor on labour-market restructuring time. Counter-cases: dial-up to broadband transitions, mobile phones — both moved faster than tractors. What predicts speed?
• uninformedThe Gukesh anecdote is reported confidently ('the only one of the young players not allowed a computer before age 12') but is not actually verified in the conversation. Whether true or apocryphal, it is doing argumentative work it has not earned.
  17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis — read next: Quick fact-check; more importantly, treat the underlying claim about protected early craft as a hypothesis and look at the actual evidence on AI use in early-career learning — programming pedagogy research will move on this in 2026-2028.
• incompleteThe claim that NAV's success was driven by capability investments is asserted from inside the case by the very people who made those investments. There is no counterfactual — no comparable agency that did not invest similarly and failed similarly. Some of the 'flywheel' may be storytelling.
  17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis — read next: Compare cross-country COVID welfare-IT responses (Germany, Denmark, UK), and Norwegian agencies of similar size that did not transform similarly. The Skatteetaten and Helsedirektoratet experiences would be a natural comparison.
• illogicalJonas argues both that we are early on the AI S-curve (so 10% gains are not the story) and that complexity will push back on productivity gains as they accumulate. These are compatible but in tension: if the curve climbs steeply because of intent-level abstraction, the complexity ceiling should appear later; if complexity bites soon, the curve is shallower than claimed. The argument is not adjudicated.
  17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis — read next: The Brooks / Mythical Man Month tradition on accidental vs essential complexity; Ousterhout on system design; recent measurements on long-running agent harnesses (Anthropic harness design work) which directly test the complexity-ceiling claim.
• uninformedHenderson himself flags that he doesn't understand how project approval/cancellation decisions get made despite a decade at the company and now being a manager — an explicit admission that the formal account of 'how work gets decided' (which he otherwise writes confidently about) has a real gap where politics/discretion actually governs.
  Software Engineering at Google — read next: Connects to the broader corpus theme of formal org charts vs. how work actually flows through informal, political channels.
• uninformedThe claim that industrialized/scaled Agile frameworks make things 'worse for both the DP1 style organisation and the DP2 style agile teams' is explicitly hedged ('it can be argued') and supported by no specific case, study, or citation, unlike the rest of the article's claims which are each backed by named research or documented cases (Tavistock, Emery & Trist, Spotify).
  Thriving with complexity using open sociotechnical systems design — read next: Look for documented case studies of scaled-agile (e.g. SAFe) adoption outcomes to test this specific claim rather than accepting it on the strength of the article's otherwise well-sourced argument.
• 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).
• incompleteThe 'first job is murder' bottleneck is framed almost entirely through a US, Big-Tech-adjacent lens (top colleges, feeder systems, connections) without addressing how the dynamic plays out in different labor markets, education systems, or company sizes outside that frame — e.g. apprenticeship or vocational-training traditions in other countries that structure entry-level hiring differently.
  Generative AI Is Not Going To Build Your Engineering Team For You — read next: Look for comparative accounts of entry-level engineering hiring outside the US Big-Tech pipeline, or vocational/apprenticeship-model traditions (e.g. German Ausbildung, or Norwegian fagbrev-style models) applied to software.
• 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.
• incompleteAn unreconciled internal tension: the article claims both that 'changing only the tools, not how people think, will hit a wall' and that 'the culture shifted because tools demanded a certain way of working.' The necessary-but-not-sufficient reconciliation (tools create the pull; people must still internalize the practices) is left implicit, and what determines whether a tool's community norms actually transfer versus stall is never examined.
  How Open Source Enables Collaboration in Creating a Platform — read next: Conway's-law re-readings and sociotechnical systems theory (Skelton & Pais; the original Conway paper); diffusion-of-practices and communities-of-practice literature on when norms embedded in tooling actually take hold in an adopting organization.
• incompleteThe post never distinguishes this 'bad' resilience (workaround-masking) from legitimate resilience — a system's genuine, healthy capacity to absorb shocks without needing structural change. As written, 'resilience' is used almost entirely pejoratively, which risks reading as an argument against slack/buffer capacity generally rather than against dysfunction specifically.
  Pascal BORNET's Post — read next: Resilience-engineering tradition (Hollnagel, Woods, Dekker) treats resilience as the adaptive capacity of a sociotechnical system — a largely positive framing this post never engages with or reconciles its own usage against.
• 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.
• incompleteThe 'human infrastructure' closing claim is large but underspecified. Each prescription is a single-company anecdote; there is no theory of which mitigation pattern applies to which combination of debts, no sequencing guidance, and no analysis of how the patterns interact (e.g., does cognitive friction reduce or increase autonomy debt?). The article ends as a framework prospectus rather than as a developed framework.
  The Psychological Costs of Adopting AI — read next: Work on socio-technical systems design (Trist, Pasmore); change-management research on layered intervention design
• incompleteCutler's prescription is essentially individual ('surf the tension', 'find pockets'). He gestures at — but does not develop — what institutional design would look like for an organization that natively holds two views. The flattening tendency of org systems is named but not redesigned.
  TBM 423: Why Defining Teams Is So Hard — read next: Stafford Beer's Viable System Model and Espejo on organizational cybernetics (which explicitly model multiple recursive views of the same system); Wardley mapping for multi-frame strategy; Niels Pflaeging's beta-codex / 'org physics' (cells vs. functions). Also Cutler's own earlier writing on 'operating systems' for product orgs.
• incompleteDesign is positioned as the 'truth-telling' frame because designers see the seams, but design's own blind spots and the cost of giving design more structural power are not examined. The essay grants design moral authority without scrutinizing it.
  TBM 423: Why Defining Teams Is So Hard — read next: Jared Spool and Don Norman critiques of design's overreach; service design literature on the limits of journey-mapping; Tony Ulwick / jobs-to-be-done as a competitor frame that disputes design's own narrative.
• incompleteThe essay focuses on the product/design/tech axis inside a single org. It does not address how this dynamic changes in regulated, public-sector, or critical-infrastructure orgs where 'teams' are also legal/audit/governance entities — a context particularly relevant to Norwegian public-sector tech (NAV, Entur, public services).
  TBM 423: Why Defining Teams Is So Hard — read next: Pia Andrews / GovTech writing on public-sector team design; Mark Schwartz ('A Seat at the Table', 'War and Peace and IT') on bureaucracy and IT leadership; Mariana Mazzucato on mission-led public organizations. For the Nordic context: Skatteetaten/NAV/Entur case studies on team topologies in regulated environments.
• incompleteThe 'pendulum' framing is descriptively useful but normatively underspecified. Cutler observes the swing between 'everything is a product' and 'three products only' but doesn't propose what the stable middle looks like — what's the unit of organization that resists both inflation and deflation of the product label?
  TBM 423: Why Defining Teams Is So Hard — read next: Team Topologies (Skelton & Pais) explicitly types teams (stream-aligned, platform, enabling, complicated-subsystem) as a possible answer; Sriram Narayan on agile organization design; Marty Cagan's 'empowered product teams' framing as a competitor.
• incompleteAI/agent-assisted development is conspicuously absent from an essay published in 2025/2026 about how teams are defined. If a meaningful share of engineering work is mediated by agents, the definition of 'team', headcount-as-cost, and the engineering manager's role all shift. Cutler doesn't touch this, though it is plausibly the next pendulum swing.
  TBM 423: Why Defining Teams Is So Hard — read next: DORA AI capabilities report; Kent Beck on AI-assisted design ('Tidy First?' series); Addy Osmani / Steve Yegge on agentic engineering; Cutler's own TBM pieces on institutional overload and AI (TBM 412).
• incompleteCutler's prescription ('surf the tension', 'find pockets') leaves the change agent without a diagnostic for distinguishing a real pocket of opportunity from a temporary opening that will close, or from a trap that consumes effort without producing change. The post advises a posture but not a method.
  TBM 423: Why Defining Teams Is So Hard — read next: Donella Meadows' 'Places to Intervene in a System' (leverage points hierarchy) supplies the missing taxonomy of where intervention has high leverage. Fearless Change (Manns & Rising) — which Kjetil's persona shows he highlights heavily — supplies pattern-level guidance for what to do once a pocket is identified.
• incompleteThe post diagnoses the asymmetric cost geometry but never asks whether the asymmetry could itself be redesigned. Could product be held accountable for operational consequences? Could design have budget authority? Cutler treats the geometry as a given and prescribes only how to live within it.
  TBM 423: Why Defining Teams Is So Hard — read next: Allen Holub's #NoAccountability work and the broader DRI (Directly Responsible Individual) literature — which Kjetil already engages with — would supply the missing accountability-redesign frame. Henrik Kniberg's writing on Spotify-era squad accountability is another natural extension.
• incompleteThe post is silent on AI tooling, despite Cutler's recent series on AI and organizational design. This is a striking absence — if AI is changing how work is coordinated (skills, agents, asynchronous artifacts), does it also change the cost asymmetry that this post identifies as the root cause?
  TBM 423: Why Defining Teams Is So Hard — read next: Re-read TBM 412 (institutionalized overload + AI) and TBM 418 (campfires, trails, quests) against this post. Test whether AI-mediated artifacts could shift the cost asymmetry — does cheap AI-generated documentation make tech's 'I have to live with it' position cheaper or more expensive?
• incompleteThe post barely engages with what 'aspirational' actually looks like — there is no example of a North-Star map that is being incrementally closed versus one that is permanent theater. Without exemplars, the distinction is rhetorical rather than operational.
  TBM 423: Why Defining Teams Is So Hard — read next: Team Topologies (Skelton & Pais) — their stream-aligned/platform/enabling/complicated-subsystem taxonomy is the closest thing to an operational aspirational map; useful to read it through Cutler's lens to see whether it survives the 'permanent theater' test.
• illogicalCutler argues both (a) describing reality is cognitively easy and (b) organizational history is load-bearing and rarely documented. If the historical context is missing, then describing reality is not actually easy — it is partial in ways the workshop participants cannot fully see. The post does not reconcile these two claims.
  TBM 423: Why Defining Teams Is So Hard — read next: Engage with Edgar Schein on organizational culture as historically embedded — the surface-level description that workshops surface may be necessary but not sufficient, and the post understates how much remains invisible even after the political cost has been paid.
• incompleteThe C-suite is named (via Dame's quote — 'cross-functional with complete oversight') but never analyzed as itself a structural location with its own incentive geometry. If the fractal breaks at middle management, what is the corresponding pathology at the top?
  TBM 423: Why Defining Teams Is So Hard — read next: Henry Mintzberg on structure in fives; Russ Ackoff on idealized design — both supply tools for analyzing the C-suite as an organizational location rather than a moral category. Camille Fournier on engineering leadership ladders is closer to home.
• incompleteThe essay treats 'capability' as if it moves largely independent of formal organizational structure (reporting lines, budget ownership, team boundaries) -- but Cutler's own other writing (on defining teams, on the reverse Conway maneuver) argues architecture and org structure are hard constraints on how fast capability can actually be reallocated. This piece never reconciles the two: can a capability really 'rebundle' into a role if the team/reporting/architecture boundaries around it haven't moved, or does rebundling silently stall at the structural layer?
  TBM 432: Bundling & Unbundling Capabilities (and AI) — read next: extract-tbm-423-defining-teams (same author) directly argues architecture is a hard constraint underestimated by reorg efforts -- read the two Cutler pieces together for the missing synthesis.
• incompletePublished in 2019, the book's entire model treats team members as human and cognitive load as a property of human cognition; it has no account of AI coding agents as team participants, no revised sizing logic for teams that delegate execution to agents, and no treatment of how the four fundamental team types or three interaction modes might need an agent-topology analogue.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow — read next: Thoughtworks Technology Radar Vol. 34 names exactly this gap — it calls for considering 'agent topologies alongside team topologies' but offers no concrete model (extract-thoughtworks-technology-radar#g1); no dedicated treatment yet closes it.
• incompleteThe reverse Conway maneuver is prescribed as a design lever with little discussion of the transition cost or time required to actually re-form teams and re-architect systems around a target topology, or of how much existing architecture constrains realignment speed.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow — read next: extract-tbm-423-defining-teams#p3 argues directly that architecture is a hard constraint on how fast teams can be realigned and that the reverse Conway maneuver underestimates this — a direct critique worth reading against this book's Ch. 2.
• uninformedThe evidence base is a set of hand-picked industry case studies presented as successes; there is no longitudinal or comparative data on organizations that adopted the four-topology model and did not see improved flow, or that abandoned it.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow — read next: Look for independent post-adoption research (e.g., DORA/Accelerate-style empirical studies) measuring flow metrics before/after Team Topologies adoption specifically, rather than case narratives selected by the authors.
• incompleteThe document identifies the productivity/experience paradox but offers no framework for resolving it beyond the 'agent experience' reframe. How should organizations actually measure and invest in developer satisfaction when it is decoupled from output?
  The Future Of Software Engineering — read next: DORA team's ongoing research on developer experience metrics; Nicole Forsgren's work on SPACE framework
• incompleteThe batch-size regression is flagged as an 'active regression needing industry attention' but no countermeasures are proposed beyond general governance reform.
  The Future Of Software Engineering — read next: DORA State of DevOps reports; continuous delivery literature on changeset sizing with AI tools
• incompleteThe four-level taxonomy is presented as self-evident without empirical grounding, prior art references (beyond Engelbart), or criteria for distinguishing the levels in practice. It is unclear whether the levels are discrete, overlapping, or a continuum, and what determines when a system transitions from one level to another.
  The keyboard was never the bottleneck — read next: Compare with established taxonomies: Lehman's laws of software evolution, the Cynefin framework, or Conway's law literature for more rigorous level-distinction criteria.
• incompleteThe claim that AI-generated code characteristically fails at higher levels is asserted as an observed pattern but supported only by a brief characterization ('works in isolation, fails when inputs vary'). No specific examples, studies, or failure cases are cited.
  The keyboard was never the bottleneck — read next: Look for empirical studies on AI-generated code in production systems, e.g., GitHub Copilot studies, or case analyses of AI-generated code failures in integration contexts.
• incompleteThe article does not address the possibility that AI capabilities at higher levels could improve significantly. The boundary between levels 2 and 3 is treated as if it were a stable, inherent limitation rather than a current snapshot of AI capability.
  The keyboard was never the bottleneck — read next: Follow research on AI agents for multi-component system design, autonomous software engineering agents, and LLM-based architecture reasoning.
• incompleteAmundsen argues the opportunity to 'get better at getting better' exists but immediately hedges that it may not be realized. No mechanisms, incentives, or conditions for realizing it are discussed.
  The keyboard was never the bottleneck — read next: Engelbart's original 'Augmenting Human Intellect' framework, and organizational learning literature (Argyris, Senge) for conditions under which meta-improvement actually occurs.
• incompleteThe Radar explicitly flags that 'how we collaborate and structure teams will need to evolve' and that 'agent topologies' should be considered 'alongside team topologies,' but offers no concrete model, pattern, or case study for what a reconciled human-team + agent-topology structure actually looks like — it names the gap without filling it.
  Technology Radar, Volume 34 — read next: Look for a dedicated treatment of team/agent topology mapping — e.g. an update to Team Topologies itself, or practitioner case studies of teams that have explicitly redesigned their org structure (not just tooling) around agent orchestration roles.
• uninformedThe document is an industry-wide, cross-client synthesis produced by a 22-person advisory board; it does not — and structurally cannot — speak to how any of these recommendations play out inside a specific team's existing culture, legacy codebase, or organizational politics. Every blip is stated as a general recommendation, not a contingent one.
  Technology Radar, Volume 34 — read next: Pair with team-level case studies or first-person practitioner accounts (e.g. this corpus's own harness-engineering and agent-config-decay extractions) to ground the Radar's generalizations in a specific team's experience.
• incompleteTrust is treated as one undifferentiated resource. Trust between paired programmers, trust from the rest of the team, trust from the customer, trust in the system (observability) — Beck collapses these. But they have different production functions, different decay rates, and may not be substitutable. A skeptic might point out that customer trust is far more about delivered value than pairing rituals, while pair-trust is largely independent of customer outcomes.
  Trust Factory — read next: Janson + Wester on pair-trust (Heis ep 6 — 'if something feels off, say it once'); Printzell Halvorsen on Nordic societal trust enabling distributed teams (Heis ep 8); Onora O'Neill on the trust-trustworthiness distinction and on different kinds of trust requiring different verification structures.
• incompleteThe 'trust factory' metaphor is endorsed without examining what it concedes. 'Factory' implies trust is manufactured by repeating standardized processes — but a major tradition (cultural, philosophical, theological) treats trust as precisely the kind of thing that cannot be manufactured. Beck does not engage this objection. The metaphor's industrial framing also obscures that XP practices may have worked because they instantiated values the practitioners already held — not because the practices produced the values.
  Trust Factory — read next: Cutler on operating-system design vs cultural pre-conditions (TBM series); Diego Gambetta on trust as a non-manufacturable resource; the 'culture eats process for breakfast' literature.
• incompleteThe four 'slow development' prescriptions are stated but not operationalized for the augmented case. How exactly do you 'slow development to encourage frequent person-to-person interaction' when the genie is so seductive? What are the equivalent of XP practices for the augmented era? Beck explicitly defers this ('not yet settled') but a reader looking for action is left with a principle, not a practice.
  Trust Factory — read next: Beck's own subsequent essays (the 'XPAI' thread he's hinting at); Birgitta Böckeler on harness engineering; Garg on reducing friction in AI development (both already in the user's extracted corpus); Bockeler/Anthropic harness writing.
• incompleteThe cultural specificity of trust is not addressed. XP emerged in a high-trust professional subculture (Chrysler C3, early agilists). Whether the trust factory works in low-trust organizational contexts — or only metabolizes pre-existing trust — is left untested. Same question applies to whether trust factories scale across cultural and national boundaries.
  Trust Factory — read next: Printzell Halvorsen on Nordic high-trust societies enabling distributed teams (Heis ep 8); Fukuyama on high-trust vs low-trust societies; cross-cultural management literature.
• uninformedRecorded in June 2024, before agentic coding tools were mainstream, the talk has nothing to say about AI-assisted migration or system-comprehension tooling — even though its own code-visualization example (CodeScene) and its central discovery techniques (event storming, listening tours) are exactly the kind of system-sensemaking work coding agents now also attempt. It leaves open whether the social/workshop-based discovery Tune describes remains necessary once an agent can read and summarize the codebase itself.
  Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024 — read next: Corpus pieces on agentic migration and brownfield modernization (e.g. extract-bun-zig-to-rust-rewrite, extract-osmani-brownfield-agentic-engineering) for whether agent-era migrations still require the human sensemaking and trust-building Tune describes, or substitute a different kind of discovery entirely.