Coordination Cost

The combinatorial cost of humans deciding together as organizations grow — the force that produced fiefdoms and layers, and that AI reshapes but does not abolish.

Also known as: coordination burden / coordination tax, coordination tax, collaboration tax / coordination tax, collaboration tax, communication overhead, Geometric problem, coordination theater, Async abundance, Fiefdom, ZIRP wave / ZIRP era, behavioral scalability, GM mindset / GM-fiefdom model, translation tax, communication architecture

How authors use it

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

Documents (27)

• AI + Teams = ? Marcus Castenfors · 2026-09-26 source ↗ Reader 🖥️
  The default way people use generative AI on a team — everyone working alone in their own chat window — quietly damages team alignment and accrues a 'collective debt'; teams do better when they deliberately decide where to prompt together (especially to define the problem, which is a human act AI cannot do well) versus where to delegate to AI individually or collectively, and when they widen the room to outside domain experts now that AI has removed the technical barrier to those experts contributing directly.
• Experience Mapping Matters More the Faster You Move Jim Kalbach · 2026-09-08 Reader 🖥️
  Because AI now lets every team execute fast and independently, the real risk facing organizations is uncoordinated speed, not slow speed — so experience maps matter more, not less, because they are one of the few tools that reliably turn scattered, siloed knowledge into a shared, in-the-room conversation that AI cannot produce on its own.
• 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.
• Managers Are Not Overhead: They Are Infrastructure David Michelson · 2026-07-22 source ↗ Reader 🖥️
  Organizations flattening management layers on the assumption that AI has absorbed most of what managers used to do are making an unsupported productivity bet, because converging survey evidence shows managers have become the critical infrastructure layer that translates AI investment into realized team-level value, not a layer of overhead AI is now positioned to eliminate.
• Adam Mosseri: AI is a tailwind for authenticity Adam Mosseri (guest); Lenny Rachitsky (host) · 2026-07-11 Reader 🖥️
  Because AI makes creation nearly free and floods the world with synthetic content, the scarce and durable human advantages become taste, judgment and authenticity — which Mosseri argues is a tailwind rather than a headwind for Instagram (audiences will seek out real people and creators, not less), and which in turn reshapes how work is organized: teams compress into small generalist 'pods' led by a new 'product staff' role, while hiring rewards curiosity, grit and a willingness to try over deep specialization.
• The Office Amenity That Actually Improves Teamwork Harvard Business Review · 2026-07-09 source ↗ Reader 🖥️
  The strongest driver of team effectiveness is not perks, office design, or where people work, but whether the team protects uninterrupted focused work, because effective collaboration depends first on enabling deep, independent thinking.
• Why AI Coding Agents Still Need Clear Specs Markus Eisele · 2026-07-08 source ↗ Reader 🖥️
  AI coding agents don't eliminate the cost of specification, they relocate it into downstream correction loops and human review, so the real discipline is locating — and validating — a task-dependent sweet spot on a U-shaped completeness-vs-cost curve, one that shifts toward much stronger contracts as more agents are chained together.
• 🧠 Community Wisdom: How AI is changing product operating models, tracking work stress with Whoop, whether you nee… Lenny's Newsletter · 2026-07-07 Reader 🖥️
  A weekly subscriber-community digest surveying current practitioner consensus across four threads of product work — tracking work stress with wearables, status-reporting as a manager of managers, go-to-market for tiny AI-augmented teams, and re-organizing the product operating model around AI — where the advice threads share a recurring move: redirecting the question from tools, tactics, and headcount back to the underlying outcome or system.
• 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.
• What is the harder human-capital problem beneath token capital? Turing Post · 2026-06-15 Reader 🖥️
  Beneath Nadella's visible 'token capital vs. human capital' story lies a harder problem — the human capital big firms manufacture best (senior, politically-fluent ladder-climbers) is exactly the kind that wastes token capital, while the frontier-moving talent that would use it well is what corporate structure selects against — so the scarcest capital in the AI age is neither human nor machine but an organizational structure porous enough to hold uncorporate talent and corporate-scale compute together without flattening either.
• We don't write code anymore Vincent Quigley · 2026-06-12 source ↗ Reader 🖥️
  Software engineering has entered a fourth generation of abstraction in which implementation is cheap and the hardest, most valuable work has moved up a level to framing, specifying, steering, and reviewing — which requires engineers, teams, and engineering management itself to reorganize around judgment and review capacity rather than code production.
• The engineering manager role is splitting in two Stephane Moreau · 2026-06-09 source ↗ Reader 🖥️
  The engineering-manager role is fracturing into two divergent futures — the code-adjacent tech lead manager and the non-technical multi-team EM — and because AI-shrunk teams are driving the split as an unplanned byproduct of flattening, engineers on the management path must diagnose which future their company is building and prepare accordingly rather than aiming at a single 'EM' destination.
• AI Won't Save the Kingdoms We Built John Cutler · 2026-05-25 source ↗ Reader 🖥️
  AI will only dissolve the organizational fiefdoms of the ZIRP era if leaders are honest that those fiefdoms were structural responses to coordination, autonomy, and accountability problems — otherwise AI will simply reproduce the same coordination burden in a new, async, agent-mediated shape.
• 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.
• TBM 421: Minimally Viable Consistency (Part 3) John Cutler · 2026-05-09 Reader 🖥️
  Organizational consistency is not a single lever but a portfolio of three distinct strategies — sharp consistency (opinionated uniformity), flexible consistency (shared intent with local adaptation), and legible variety (named, visible differences) — and choosing the right mix at each point is the central design problem, one that AI can help with by translating between frames and scaling coaching, but only if the sensemaking friction it removes was overhead and not a learning mechanism.
• Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge Emad Mokhtar · 2026-05-07 source ↗ Reader 🖥️
  The Staff Engineer skillset of defining outcomes, reducing ambiguity, creating guardrails, and reviewing work — originally built for leading human teams — transfers directly to leading AI coding agents, and is becoming more valuable, not less, as agents take over more implementation.
• John Cutler's Post John Cutler · 2026-04-19 source ↗ Reader 🖥️
  Team AI use sorts into three qualitatively distinct patterns — pure single-player, shared-context solo, and true multiplayer — and most of today's impressive team-AI demos are only the middle tier (shared conventions and templates that each person still works alone against), which is a genuine, valuable win over pre-AI friction but is not multiplayer collaboration, and teams that mistake this foundation for the destination will stall there.
• Hard truths about building in the AI era | Keith Rabois (Khosla Ventures) Lenny Rachitsky, Keith Rabois · 2026-04-12 source ↗ Reader 🖥️
  Building a world-class company requires ruthless talent identification and density above all else, and in the AI era this means fewer but more capable people operating at extreme speed with business acumen replacing traditional role specialization.
• The founder of Postman says you have to kill your existing org chart Ivan Burazin · 2026-04-10 Reader 🖥️
  Traditional organizational hierarchies must be dismantled in favor of flat, builder-centric structures where everyone — including PMs and designers — ships directly, and management exists to cultivate judgment rather than coordinate through layers.
• Bliki: Mythical Man Month Martin Fowler · 2026-01-01 source ↗ Reader 🖥️
  Fred Brooks's 'The Mythical Man-Month' remains essential reading because its core lessons — that communication overhead defeats brute-force staffing and that conceptual integrity is the highest design priority — are as true in 2026 as in 1975.
• What happens when the coding becomes the least interesting part of the work Obie Fernandez · 2025-12-12 source ↗ Reader 🖥️
  Senior engineering value has always lived in mostly-tacit, pre-code judgment (pattern-recognition, abstraction level, blast radius, reversibility) rather than typing, which is why coding agents cannot yet substitute for it — but once senior engineers and their employers realize this, the organizational result will be a drastic contraction toward small teams of highly accountable, AI-empowered seniors who absorb roles that used to belong to juniors, PMs, business analysts, and designers.
• Disposable Code Is Here to Stay, but Durable Code Is What Runs the World Charity Majors · 2025-07-29 source ↗ Reader 🖥️
  Software development is splitting into two durably separate domains -- cheap, AI-generated disposable code and expensive, trust-earning durable code -- and because the cost of software is defined by its maintenance rather than its authorship, generative AI changes who can write code but does not eliminate the need for the fast-feedback-loop engineering discipline (tests, CI/CD, observability) that durable code has always required.
• 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.
• 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.
• 5 Things High-Performing Teams Do Differently Harvard Business Review · 2021-10-21 source ↗ Reader 🖥️
  Close social connection among colleagues, deliberately engineered through everyday relational behaviors, is the primary driver of team performance — fulfilling the basic psychological need for relatedness — and can be fostered even in remote or hybrid settings, so high performance takes more than hiring the right people and giving them the right tools.
• The impact of the 'open' workspace on human collaboration Ethan S. Bernstein; Stephen Turban · 2018-07-02 Reader 🖥️
  Removing spatial boundaries to make offices 'open' and transparent does not increase collaboration; across two corporate field studies it cut face-to-face interaction by roughly 70% and prompted a partial, compensating rise in email/IM, because heightened observability triggers a natural human response to restore privacy by withdrawing from co-present peers and re-routing interaction to electronic channels.
• 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 (8)

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

2025-07

• explicitcontestedFor durable codebases, AI's most valuable contribution is not code generation but help with the genuinely expensive parts -- large rewrites that would previously have taken years, instrumentation, incident analysis, and anomaly detection -- which reduces the coordination tax on large groups by letting fewer engineers own more surface area with confidence.
  Disposable Code Is Here to Stay, but Durable Code Is What Runs the World · p9

2026-01

• implicitcorroboratedCommunication overhead, not individual productivity, is the primary bottleneck when scaling software teams.
  Bliki: Mythical Man Month · p7

2026-05

• explicitcorroboratedThe people who built and benefited from the ZIRP-era fiefdom model are now the loudest voices calling for AI-enabled flattening.
  AI Won't Save the Kingdoms We Built · p1
• explicitThe GM-fiefdom model was a rational response to real problems (autonomy/speed, accountability/focus, and the geometric coordination problem), not an arbitrary mistake.
  AI Won't Save the Kingdoms We Built · p2
• explicitcorroboratedAI will recreate the old coordination problem in a new shape — async abundance — where the burden again lands on the front lines.
  AI Won't Save the Kingdoms We Built · p9
• implicitcorroboratedThe 'real' fiefdom problem is political-economic (incentives, ownership, decision rights), not informational.
  AI Won't Save the Kingdoms We Built · p11

2026-09

• implicitNetworked, hierarchy-bypassing coordination is implicitly assumed to have lower or comparable coordination cost than hierarchical coordination, since the piece presents 'not needing to traverse the hierarchy' as an unqualified benefit.
  Beyond Autonomous Teams in Software Product Development · p13
• implicitColocating independently deployable feature workers in one monorepo, with each worker's external facade as the only surface the gateway may import, is necessary to keep the shared contract from drifting once every feature worker is independently owned, tested, and deployed — otherwise the split reintroduces coordination cost at the integration layer instead of removing it.
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers · p16

Tensions

Open gaps (53)

• incompleteRemote/hybrid applicability is under-evidenced relative to the headline promise. The article opens by promising the findings help 'even within a remote or hybrid work setting,' yet most differentiators are inherently in-person or proximity-based: 'time at the office discussing non-work matters,' meeting for coffee/tea/an alcoholic beverage. Only the phone-call behavior clearly transfers to distributed teams; the mechanism by which the rest survive full remoteness is not shown.
  5 Things High-Performing Teams Do Differently — read next: Investigate which specific connection behaviors actually transfer to fully-remote teams versus which depend on physical co-location, and whether deliberately engineered remote rituals reproduce the in-person effect.
• incompleteThe piece recommends bringing more outside experts into the room to add diversity of thought, but never addresses the coordination/alignment cost of doing so — the same 'parallel work creates problems' dynamic it diagnosed for individual AI chats could plausibly recur with a wider, more heterogeneous group of contributors who have different working styles, tools, and incomplete shared context.
  AI + Teams = ? — read next: Literature on cross-functional team size, coordination cost, and the trade-off between diversity-of-perspective gains and communication-overhead losses as group heterogeneity increases.
• incompleteCutler treats fiefdoms as cultural-political artifacts produced by unwilling leaders and self-interested fief-heads. He does not engage with the genuine structural pressures that may force fiefdom-like structures: capital-allocation cycles, headcount accounting, regulatory accountability, the way investors and boards read org charts, the difficulty of cross-fiefdom budgeting in a quarterly cadence. If those structural pressures are real, the 'hard choices' framing is too voluntarist.
  AI Won't Save the Kingdoms We Built — read next: Read management-accounting and capital-allocation critiques (e.g., Beyond Budgeting Round Table — Bjarte Bogsnes; Robert Simons on accountability systems; Niels Pflaeging on cell-structure designs). Also: Henry Mintzberg on configurations as responses to environmental contingency, not pathology.
• incompleteThe essay names 'coordination theater' but offers no test to distinguish it from real coordination in flight. Without a diagnostic, the concept risks becoming a rhetorical move rather than an operational lens.
  AI Won't Save the Kingdoms We Built — read next: Pair with Cutler's own prior work on operating systems / TBM 412 (institutional overload), and with explicit decision-rights frameworks (RAPID, DACI) that surface where decisions actually get made vs. where they are documented.
• incompleteThe 'people with a bias toward working alone' characterization is psychological, not structural. It does not interrogate why an organization rewards or selects for that bias — which is itself a fiefdom-era artifact (individual P&L-style accountability, individual performance ratings, etc.).
  AI Won't Save the Kingdoms We Built — read next: Allen Holub on accountability culture; Edmondson on psychological safety; Cutler's own earlier writing on directly-responsible-individuals and accountability culture.
• incompleteThe essay addresses leaders and the front lines but is silent on the middle layer — the fief-leaders themselves as actors who must decide whether to dissolve their own kingdoms. Their incentive structure is sketched (self-interest) but not engaged as a design problem.
  AI Won't Save the Kingdoms We Built — read next: Schein on organizational culture and middle-management as load-bearing; classic literature on 'turkey voting for Thanksgiving' problems in restructurings.
• incompleteThe U-shaped cost curve and its variants (single- vs multi-agent, BDD vs prose) are presented as illustrative line charts with no axis units, no measured data points, and no cited study — the model is asserted as intuitively obvious rather than empirically demonstrated.
  Why AI Coding Agents Still Need Clear Specs — read next: Look for empirical studies quantifying rework/correction cost under varying spec completeness with AI coding agents (e.g., controlled comparisons of BDD vs prose-spec agent tasks, or DORA-style research) to test whether the curve's shape and minimum location actually hold.
• incompleteThe essay proposes a spec-validation ('critic') agent as a cost-lowering step but never addresses who or what validates that critic, or what happens when its critique is itself wrong or incomplete — an infinite-regress problem inherent to using agents to check agents.
  Why AI Coding Agents Still Need Clear Specs — read next: Look at multi-agent debate and self-consistency literature, or formal-verification framing of 'who verifies the verifier,' for how (or whether) this regress is bounded in practice.
• uninformedThe claim that specification, not implementation, has always been the hard part of software engineering closely tracks Fred Brooks's essential-vs-accidental-complexity distinction, but the piece never engages that lineage or the decades of requirements-engineering literature built on it.
  Why AI Coding Agents Still Need Clear Specs — read next: Fred Brooks, 'No Silver Bullet — Essential and Accidental Difficulties of Software Engineering' (1986); also classic requirements-engineering work distinguishing validation ('are we building the right thing') from verification ('are we building it right').
• incompleteThe cost ledger treats 'the human' as a single, already-aligned oracle who knows what the spec should say; it never addresses the more common real-world case of multiple stakeholders disagreeing about intent, which is a large share of why specs are hard to write and validate in the first place.
  Why AI Coding Agents Still Need Clear Specs — read next: Organizational and requirements-engineering material on stakeholder conflict and specification as a negotiated artifact, not merely an accuracy artifact — relevant to team-space and change-adoption thinking about how groups actually converge on shared intent.
• incompleteThe binary is asserted, not shown to be exhaustive. The citations (Meta, Amazon, Gartner, Faros) establish that flattening is happening, not that it resolves into exactly these two EM archetypes rather than a spectrum, durable hybrids, or outright role dissolution. No evidence is offered that organizations must pick one; the intermediate case (a TLM who also carries some cross-team scope) is excluded by construction rather than by argument.
  The engineering manager role is splitting in two — read next: Read against 'AI Won't Save the Kingdoms We Built' (flattening as politics and cost, with coordination burden re-emerging in a new shape rather than vanishing) and 'Your AI strategy has a trust problem' (flat high-autonomy pods as a third structural option), which suggest the fork is one framing among several.
• incompleteThe claim that cutting a team to 4-5 seniors removes the need for a project manager, business analysts, or designers treats those roles as pure overhead that disappears once seniors can ship directly, without engaging what those roles actually absorbed besides shippable output — stakeholder alignment, prioritization trade-offs, user research, cross-team coordination. That work doesn't vanish just because seniors can type code themselves; it has to land somewhere.
  What happens when the coding becomes the least interesting part of the work — read next: extract-kill-your-org-chart-for-ai (a related claim that at least names 'the development of better judgment' as management's remaining purpose) and extract-ai-native-engineering-org (bottleneck shifts to alignment/decision-making, not away from coordination entirely).
• uninformedThe claim that typing code 'feels like a waste of time' when billed at an expensive hourly rate treats the economics purely from the senior consultant's individual vantage; it doesn't address the same calculus for salaried engineers inside a company absorbing the AI spend, or whether clients will keep paying the same hourly rate once they also realize how much of the work is agent-executed.
  What happens when the coding becomes the least interesting part of the work
• incompleteFowler claims the lessons are 'still relevant today' but provides no modern examples or evidence. The piece is purely retrospective endorsement. What does violating conceptual integrity look like in 2026 — in microservices, AI-generated code, or platform teams? How does Brooks's Law manifest with remote/async teams, AI pair programmers, or open-source contribution models?
  Bliki: Mythical Man Month — read next: Brooks's own 'No Silver Bullet' essay (included in the anniversary edition); Conway's 1968 paper on organizational structure mirroring system design; Team Topologies (Skelton & Pais) for a modern treatment of communication paths as architectural constraints; Fred Brooks's later reflections in 'The Design of Design' (2010).
• incompleteThe article focuses entirely on individual developer-AI interaction. There is no treatment of how AI collaboration patterns interact with team dynamics — e.g., whether standardized prompts reduce healthy variation in approach, or whether shared priming docs create new coordination costs.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Research on coordination costs in software teams; Brooks's 'The Mythical Man-Month' on communication overhead
• 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 lab-vs-enterprise conflation. The argument is strongest for frontier labs that BUILD token capital (models, evals, loops require irreverent frontier-movers) and weakest for the telco, bank or typical enterprise that BUYS and absorbs it. A firm that consumes AI rather than pushing the frontier may not need 'permission-averse, loudly-wrong' talent at all — for it the binding constraint is more likely absorption, integration and process legibility than porousness for mavericks. The essay treats the two as one problem and never tests whether its prescription even applies to the majority of the 54% of employment it invokes.
  What is the harder human-capital problem beneath token capital? — read next: Read against the enterprise-AI-adoption literature that separates building vs. buying/absorbing AI capability (e.g. forward-deployed-engineer and readiness models): does a token-capital consumer need frontier-mover porousness, or is its real obstacle organizational absorption, and would importing 'uncorporate' talent even help?
• incomplete'Porous structure' is named as the answer but never operationalized. The essay supplies no mechanism, org-design pattern, incentive structure, or worked example of what porousness looks like, nor how a firm hands 'corporate-scale compute + responsibility' to uncorporate people without recreating the committees and procurement logic that sand them down. The prescription is a direction, not a design.
  What is the harder human-capital problem beneath token capital? — read next: Read toward concrete structural patterns that could fill the mechanism — small-teams/tiny-core bets, autonomous-team designs, skunkworks and lab-within-a-company structures — and test which actually preserve irreverence at corporate scale.
• illogicalThe essay's own evidence strains against its thesis. Demis Hassabis built Gemini INSIDE Google, a corporate giant — 'in spite of' it, yes, but still inside it and still winning — which shows rigid incumbents CAN produce frontier results, cutting against the flat claim that structure 'selects frontier talent out.' By naming only the winning obsessives (Hassabis, Dean, Liang Wenfeng) it also survivorship-selects, saying nothing about the uncorporate people who were in fact crushed. So 'structure selects them out' is asserted more strongly than the evidence, which really shows 'structure taxes them, but some still win.'
  What is the harder human-capital problem beneath token capital? — read next: Read comparatively for cases where incumbents DID retain and productively hold frontier talent, to separate the strong claim ('structure filters them out') from the weaker, better-supported one ('structure imposes a heavy tax they sometimes overcome').
• 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 essay's closing advice ('Protect it. Expand it.') treats investing more time in alignment as a matter of individual/team will, without addressing the structural incentive problem: if delivery speed and shipped output remain what an organization measures and rewards, AI-accelerated teams under pressure to ship have no organizational cover to spend more time in workshops, however strongly an individual leader is urged to prioritize it.
  Experience Mapping Matters More the Faster You Move — read next: DORA-style incentive and metrics literature, or Cutler's writing on institutional overload, flow, and where slack actually gets funded from.
• unstated assumptionThe argument assumes that coordination, alignment, and context-sharing across teams are either unnecessary or automatically handled in flat structures. Large-scale organizations face coordination problems that are not solely caused by hierarchy but by the inherent complexity of distributed work.
  The founder of Postman says you have to kill your existing org chart — read next: Literature on coordination costs in flat organizations (e.g., Galbraith's information-processing theory of organization design); case studies of flat-org failures at scale.
• missing evidenceNo evidence is provided that PMs building APIs or designers shipping PRs produces better outcomes than the prior division of labor. The implicit claim is that directness equals quality, but this conflates shipping speed with product quality.
  The founder of Postman says you have to kill your existing org chart — read next: Research on specialization vs. generalization in knowledge work; outcomes data from companies that have adopted these structures.
• selection biasThe argument is attributed to the founder of Postman — a developer-tools company where engineering culture is dominant. The prescription may not transfer to organizations where the core work is not software (healthcare, logistics, manufacturing).
  The founder of Postman says you have to kill your existing org chart — read next: Compare with AI-era org design thinking in non-tech industries.
• unacknowledged tensionThe binary 'either you're building, or you're selling' erases important organizational functions: strategy, research, compliance, people development, customer success. These are neither building nor selling but may be essential.
  The founder of Postman says you have to kill your existing org chart — read next: Consider which organizational functions are genuinely automatable vs. which are being rhetorically dismissed.
• uninformedThe headline '10x value' claim for well-topologized teams is presented as personal observation ('I have been on these teams a few times') with no comparison group, metric definition, or controlled attribution — exactly the kind of practitioner-anecdote-as-data this reader's persona is skeptical of (wants benchmark data over vendor/anecdotal claims), and strikingly similar in rhetorical shape to AI-adoption 10x productivity claims made elsewhere in this corpus (see extract-latent-space-yegge-vibe-coding-manifesto#p2) without either source examining whether the two '10x' claims share, confound, or are independent of each other.
  Optimizing teams: A dual perspective on Team Topologies — read next: Look for controlled or larger-sample studies isolating team-topology quality as a productivity variable, independent of the AI-adoption productivity claims appearing elsewhere in the corpus.
• incompleteThe essay never reconciles the tension its own evidence walks into: the LeadDev data it cites to show managers 'doing more' (more scope, more reports, more communication) is, elsewhere in this corpus, flagged as an unresolved structural contradiction — manager quality/attention is the single biggest lever on wellbeing, yet spans of control keep widening. If managers are stretched across more reports and more scope, their capacity to perform the very behaviors credited with driving AI value (individualized modeling, psychological safety, quality-standard setting) may itself erode, an inference the essay never draws.
  Managers Are Not Overhead: They Are Infrastructure — read next: Reads as a partial answer to the reconciliation gap named in extract-lenny-noam-segal-tech-worker-ai-sentiment-2026#g2 and extract-tech-workers-2026-workforce-splitting-in-two#g4 (orgs flattening while manager quality is the biggest wellbeing lever) and extract-postman-engineering-leadership-report-2026#g5 (the same report's own reassurance-vs-accelerating-flattening tension) — but it only asserts a side (invest in/preserve managers) rather than explaining how broader spans and deeper manager investment can coexist.
• incompleteThe piece is written entirely from the perspective of one self-motivated individual's personal transition; it never addresses the team or organizational dimension — how review capacity, coordination, and quality standards hold up when many engineers in the same org are each independently 'leading' their own agent swarms, or how an organization trains and rewards this shift systematically rather than relying on individuals to discover it the way the author did.
  Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge — read next: extract-engineering-manager-role-splitting-in-two and extract-software-teaming-age-of-ai-zuill-herr, which address the team- and org-level coordination costs this piece elides.
• incompleteNo discussion of durable, large-scale, or legacy codebases; every example (CLI tool, personal dashboard, browser extension, a user-management endpoint) is small, disposable, or greenfield. The claim that the Staff Engineer skillset transfers to leading agents is untested against the harder case of agents operating inside a decade-old, high-stakes production system.
  Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge — read next: extract-orosz-when-ai-writes-almost-all-code (production-quality regressions already observed) and extract-whats-an-orchestrator-why-software-needs-one (accountability scaling with agent-driven productivity).
• illogicalThe author frames 'reviewing becomes more important' as sufficient reassurance without reconciling it with his own admission that agents 'make mistakes... sometimes create bugs that look very convincing.' If agent output is specifically liable to look convincing while being wrong, review itself becomes harder exactly as it becomes more necessary — a tension the piece raises but doesn't resolve.
  Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge
• incompleteDose and boundary of protected focus are unspecified. It prescribes starting with a 60-minute focus block once or twice weekly but offers no evidence on optimal dosage, how focus blocks scale with team size or task interdependence, or where protected solitude tips into reduced alignment. It asserts collaboration still needs discussion but never says how much focus is too much.
  The Office Amenity That Actually Improves Teamwork — read next: Deep-work dosage research and meeting-science; coordination-cost literature on the focus/alignment trade-off.
• incompleteInteraction is measured; outcomes are not. The study equates a ~70% drop in F2F-interaction minutes with reduced collaboration and productivity, but the only outcome evidence is one firm's executives qualitatively reporting a productivity decline (confidential, self-reported, uncontrolled). In systems terms it measures a flow (interaction) and infers a stock (collaborative capability/output) without measuring the stock — and never tests whether some of the electronic substitution (async, focused, documented) improves rather than harms certain outcomes.
  The impact of the 'open' workspace on human collaboration — read next: Read studies that link open-office redesign to measured output/decision quality/performance, not just interaction; the media-richness empirical literature on when leaner channels help or hurt; and deep-work/async-collaboration research on whether shifting interaction off the floor can raise productivity for some task types.
• incompleteThe mechanism — a balancing feedback loop of privacy restoration under observation — is hypothesized but not instrumented. No measure of headphone use, avoidance, or perceived observability was collected, so the mediating variable is inferred from volume shifts. Competing explanations (noise avoidance, changed physical adjacency of one's actual collaborators, task changes, or a Hawthorne/observer effect from being badged) are not ruled out.
  The impact of the 'open' workspace on human collaboration — read next: Read Bernstein's own transparency-paradox work (2012) and privacy/boundary-management theory (Altman) for the mechanism; look for studies that directly measure the mediator (privacy-seeking behavior, perceived observability) rather than inferring it, and that separate 'loss of enclosure' from 'change of neighbors'.
• incompleteGeneralizability is thin: n=2 organizations, both US Fortune-500 headquarters, specific open designs (undivided tables), short observation windows (3 and 8 weeks) beginning only ~2 months after the move, so a transient adjustment/novelty phase cannot be distinguished from long-run equilibrium. The framing universalizes ('a natural human response') without testing national/cultural context, org type, which open designs or mitigations (quiet zones, activity-based working, norms) change the result, or steady-state behavior a year on.
  The impact of the 'open' workspace on human collaboration — read next: For a leader housing teams (esp. in a Norwegian flat, high-trust, quiet-office context), read cross-cultural office-design studies, longitudinal (>1 year) open-office evaluations, and activity-based-working assessments to see whether the effect holds where privacy norms, trust levels and design specifics differ.
• incompleteThe counterfactual is narrow: the studies compare open space only against cubicles. They cannot tell a decision-maker what to do instead, only that a cubicles-to-fully-open move backfired — private offices, hybrid/activity-based layouts, and remote/distributed work are untested comparators. Nor can they separate 'losing enclosure' from 'changing who sits nearby'. The implicit assumption that architecture is the right leverage point (rather than norms, incentives, or meeting design) is left unexamined.
  The impact of the 'open' workspace on human collaboration — read next: Read comparative office-typology studies (private vs cubicle vs open vs ABW vs remote) and, in Meadows' leverage-point terms, work on whether interaction is more effectively shaped by rules/norms/incentives than by the physical structure the paper treats as the intervention.
• incompleteThe piece asserts 'smaller teams can do more' and 'fewer handoffs, less coordination drag' as the team-shape endpoint, but never engages with the literature on why human cooperation doesn't scale automatically (trust-building, psychological safety, Dunbar-style cognitive limits) — shrinking headcount doesn't automatically shrink the coordination burden if the remaining members still need to build shared context and trust from scratch.
  We don't write code anymore — read next: extract-human-scalability-problem.
• uninformedAll reported practice comes from one senior, well-resourced team (10+ years' experience each) at a company absorbing roughly $2,000/month per engineer in AI spend; the piece generalizes 'the review bar cannot drop' and 'months of coaching to get good engineers up to standard' as achievable expectations without addressing whether less senior, less resourced, or more cost-constrained teams can sustain the same review intensity, or what happens to engineers who never built hand-written-code intuition in the first place.
  We don't write code anymore
• incompleteThe claim that psychological safety is negatively correlated with success is stated as a blanket assertion without evidence beyond a sports analogy (Jordan Rules). No engagement with the substantial research literature on psychological safety in knowledge work, nor acknowledgment that survivorship bias may be at play (we see the winning teams that lacked it, not the many that failed).
  Hard truths about building in the AI era | Keith Rabois (Khosla Ventures)
• incompleteThe anti-customer-feedback position is argued entirely through consumer examples (Porsche, Airbnb, DoorDash) but then extended to SMB without distinguishing where on the consumer-to-enterprise spectrum the advice flips. The Porsche example proves that stated preferences diverge from revealed preferences, not that all consumer feedback is harmful.
  Hard truths about building in the AI era | Keith Rabois (Khosla Ventures)
• illogicalThe argument that public criticism optimizes for the system while private criticism optimizes for the individual assumes a binary choice. It does not address whether the information benefits of public criticism could be achieved through other means (e.g., transparent issue tracking, team retrospectives) without the potential costs of public shaming.
  Hard truths about building in the AI era | Keith Rabois (Khosla Ventures)
• uninformedThe claim that AI writing quality degrades with length due to 'token rationing' by LLMs optimizing economics is presented as a confident theory but reflects a misunderstanding of how inference works. Output quality degradation with length has more to do with attention mechanisms, context window limitations, and the difficulty of maintaining coherence over long sequences than with deliberate economic throttling.
  Hard truths about building in the AI era | Keith Rabois (Khosla Ventures)
• incompleteThe advice to skip senior hires and develop talent internally is supported by examples from companies that had extraordinary founding teams (Ramp, Trade Republic). The selection bias is unaddressed: these companies may have been able to develop internal talent precisely because their initial talent density was exceptional. The advice may not generalize to companies with weaker founding teams.
  Hard truths about building in the AI era | Keith Rabois (Khosla Ventures)
• incompleteThe existential question about whether foundation model labs will absorb all value from application-layer AI startups is raised but never addressed. Given that Rabois is actively investing in AI companies, this is a significant gap — he identifies the question but offers no framework for how startups should think about durability against improving foundation models.
  Hard truths about building in the AI era | Keith Rabois (Khosla Ventures)
• incompleteThe guide never addresses the organizational conditions -- funding, margin, competitive position -- that made 'hire slower than user growth' a viable choice for Stripe. A resource-constrained or competitively pressured organization may not have the latitude to trade headcount speed for team health, and the piece offers no alternative playbook for that case.
  Guide to scaling engineering organizations — read next: Corpus material on coordination cost and organizational debt under growth pressure would clarify whether Stripe's deliberate-slowness choice generalizes or is a luxury specific to well-capitalized, high-margin companies.
• incompleteThe essay provides no method for diagnosing which strategy to apply where — the questions at the end are reflective prompts, not a decision framework. How do you determine whether a given consistency point should be sharp, flexible, or legible variety?
  TBM 421: Minimally Viable Consistency (Part 3)
• incompleteJob 3 is missing from the AI section (jumps from Job 2 to Job 4) — either an editing artifact or a deliberate omission, but it is unexplained.
  TBM 421: Minimally Viable Consistency (Part 3)
• incompleteThe taxonomy is presented as exhaustive (three strategies) but no argument is given for why these three are sufficient. Could there be a fourth strategy (e.g., emergent consistency that arises from shared tooling without explicit design)?
  TBM 421: Minimally Viable Consistency (Part 3)
• incompleteThe AI risk analysis identifies that friction can be a learning mechanism but offers no heuristic for distinguishing productive friction from pure overhead — the central practical question for anyone applying the framework to AI adoption.
  TBM 421: Minimally Viable Consistency (Part 3)
• uninformedCutler asserts that AI 'hasn't eliminated the social work of coordination, negotiation, and shared judgment' between specialists and generalists (Integration subsection), but doesn't engage the possibility -- raised elsewhere in this reader's corpus about the same author's fiefdom essay -- that AI's friction-busting on translation and handoff costs could, over a longer horizon, shift the political economy of coordination itself (who needs whom, who can bypass whom), not just its transactional cost. He treats the political layer as static while granting the cost layer is dynamic.
  TBM 432: Bundling & Unbundling Capabilities (and AI) — read next: extract-cutler-ai-wont-save-kingdoms#g3 poses exactly this dynamic-vs-static coordination-cost question from the fiefdom side; reading the two together tests whether Cutler's own corpus is internally consistent on this point.
• incompleteThe 'small teams that never merge into one' scaling hypothesis rests on a three-person anecdote and does not address where plain issues-and-PRs coordination breaks down as the number of subsystems, their coupling, or team count grows.
  What Survived Contact — read next: Read on coordination cost, Conway's law limits, and the failure modes of loosely federated subsystems at larger scale.