Organizational Debt

Accumulated structural and coordination liabilities in how an organization is arranged — the sibling of technical debt.

Also known as: organizational debt, organisatorisk gjeld

How authors use it

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

Documents (7)

• 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.
• Pascal BORNET's Post Pascal BORNET · 2026-08-01 Reader 🖥️
  Organizations mistake a team's ability to keep performing despite a broken system (endurance, sustained by workarounds and quiet compensation from strong employees and loyal managers) for evidence that the system itself is healthy, and leaders should instead treat the places demanding the most resilience as the places most in need of structural redesign.
• 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 and IT Teams Often Clash. But They Don't Have To. Graham Kenny, Kim Oosthuizen, and Ganna Pogrebna · 2026-07-31 Reader 🖥️
  AI and IT teams clash not because of a single technical disagreement but because they optimize for structurally different priorities (control vs. experimentation), and organizations resolve this — without simply picking a side — through deliberate structural interventions: reframing disputes around shared outcomes, separating roles with an explicit risk taxonomy, and mapping AI ambitions to the specific IT foundations they depend on.
• TBM 430: Incubate, Compound, Refinance, Liquidate John Cutler · 2026-07-12 Reader 🖥️
  Software assets, teams, and initiatives can be read as a portfolio positioned by the value they create against what they cost to carry -- moving between Incubate, Compound, Refinance, and Liquidate over time -- and AI does not change this underlying economic physics of complexity, coupling, and decay, only the cost, speed, and feasibility of accelerating whichever direction, healthy or pathological, the portfolio is already moving.
• The Pulse: AI load breaks GitHub – why not other vendors? The Pragmatic Engineer · 2026-05-07 source ↗ Reader 🖥️
  GitHub's ongoing reliability crisis is not adequately explained by AI-driven load increases alone; it reflects deeper organizational and technical failures that competitors have avoided, making GitHub increasingly unfit for professional software development.
• 5) Vidar Moe: Det eneste Vidar vil er å ha det lett Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-11-17 source ↗ Reader 🖥️
  Vidar Moe's core engineering-leadership philosophy is 'gjøre det lett og rett' (make it easy and right) — a Toyota-Way-inflected craft and leadership stance in which you lead an organization most powerfully not by exhortation but by patiently building the tooling, frameworks, fagtid, hiring filters, fixed-term leadership rotation, and shared decision arenas that make the right thing the path of least resistance; the episode's ironic title ('the only thing Vidar wants is to have it easy') inverts this — Moe wants the work to be easy precisely because he is willing to do the very hard, decade-long, mostly invisible work of removing friction from doing the right thing, and his current concern with AI agents is the natural next chapter of the same project.

Propositions touching this concept (2)

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

2026-05

• explicitcontestedGitHub's problems are substantially self-inflicted, stemming from tech debt, organizational debt, and a simultaneous datacenter-to-Azure migration.
  The Pulse: AI load breaks GitHub – why not other vendors? · p4

2026-06

• implicitStorey's Triple Debt Model is the correct taxonomy of software-development debt for the agent era — not, e.g., process debt, dependency debt, data debt, or organizational debt.
  The Intent Debt · p28

Open gaps (15)

• incompleteThe competitor comparison lacks depth. Saying Vercel, Linear, and Sentry handle AI load better ignores that these services have fundamentally different architectural profiles (stateless APIs vs. GitHub's stateful git storage, merge queues, and CI/CD). The comparison needs to account for architectural complexity, not just load volume.
  The Pulse: AI load breaks GitHub – why not other vendors? — read next: Architecture deep-dives on how GitLab or Bitbucket handle similar stateful workloads at scale; post-mortems from services that did scale successfully through AI load spikes.
• incompleteThe article does not examine whether AI agents' usage patterns (high-frequency, bursty, API-heavy, low-value-per-request) are qualitatively different from human usage in ways that make them harder to scale for — beyond simply 'more load.'
  The Pulse: AI load breaks GitHub – why not other vendors? — read next: Analysis of AI agent traffic patterns vs. human developer traffic patterns on infrastructure services; rate limiting and traffic shaping strategies for AI agent workloads.
• uninformedThe article assumes competitors are 'presumably experiencing similar load spikes' without data. It is possible that GitHub's dominance means it absorbs a disproportionate share of AI agent traffic, making the comparison unfair.
  The Pulse: AI load breaks GitHub – why not other vendors? — read next: Market share data on AI agent tool integrations; which platforms AI coding tools (Cursor, Copilot, Claude Code) actually target most heavily.
• incompleteNo discussion of whether GitHub could implement rate limiting, pricing changes, or architectural isolation for AI agent traffic specifically — treating agent and human traffic differently.
  The Pulse: AI load breaks GitHub – why not other vendors? — read next: GitHub's own blog posts on agent rate limiting; how cloud providers differentiate pricing for automated vs. interactive workloads.
• incompleteThe episode systematically tells the success-side of the story. Crisis → response → improvement is the recurring arc, but failed experiments, dead-end framework choices, or instances where 'gjøre det lett og rett' produced unintended organisational uniformity are absent. Moe's stated regret is only directional (could have done more, faster, in more places), not structural (e.g. 'this particular default we engineered was wrong'). The hosts twice surface the hierarchy-is-inevitable point but do not press on whether the framework-team's 'easy and right' becomes a hidden orthodoxy.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with Allen Holub's #NoAccountability strand (already in the user's persona) and with anything on the costs of platform-engineering paved roads (e.g. Charity Majors / Honeycomb on the limits of golden paths). The user's existing extraction on Cutler's institutionalised overload is a strong complement here — Cutler's frame would ask what the second-order costs of the SpareBank 1 system look like.
• incompleteMoe's persistent 'vi' is itself a load-bearing rhetorical pattern that the hosts notice in closing but do not unpack. The episode is a portrait of a person who declines to be individuated — he says 'vi' even when narrating decisions whose intellectual origin clearly lies with him personally. This is consistent with the leadership-through-defaults thesis (the work is the structure, not the speaker) but it also obscures the part of the story that does depend on a specific senior practitioner persistently present in the system for 14 years. The question 'how transferrable is this without Moe (and Stian)?' is not engaged.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in tension with the previous Heis episode on hierarchy (Eikeland, ep 4, alluded to: 'forrige podcast-episoden snakket om... det er sjelden helt flat struktur') and with the leadership-presence strand in the user's library (Cutler on power and space, TBM 413). Beck's writing on senior individuals' role in evolutionary design is a direct anglophone parallel.
• incompleteThe 'organisatorisk gjeld' coinage at the close is the most pregnant unfinished idea in the episode. Moe gestures at the next direction of 'lett og rett' — engineering golden paths for product development itself, with good practices baked into roadmap tooling — but does not work it out. This is exactly the territory where the AI question reconnects: an agentic product-development assistant that encoded the right defaults could be the next instance of 'lett og rett', and would be a Moe-shaped answer to the alienation worry from his essay.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with the user's existing extractions on harness engineering for AI coding agents and on 'Agents Don't Know What Good Looks Like'. The Backstage / Internal Developer Platforms tradition (Spotify) is the obvious anglophone analogue. Team Topologies (Skelton & Pais) and DORA's recent platform engineering findings are the natural canon. Truls's closing observation that Toyota → DORA → Team Topologies is one lineage is exactly the bridge.
• incompletePair programming is named as the most effective form of knowledge sharing and as the substrate that the rest of the infrastructure exists to support, but the cost question (developer preference, time investment, neurodiversity, hybrid/remote context) is not engaged. Moe acknowledges that change in this direction is 'ordentlig seig' — really tough/slow — but does not ask why even at SpareBank 1, with all the structure in place, pair programming is not yet universal. The same gap exists in his essay's TDD-with-the-agent prescription.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read Birgitta Böckeler's recent work on remote pair programming, and the user's already-extracted Beck material on TCR (which functions as a half-step toward pair-discipline). The 'AI Joy Gap Developers' extraction the user already has — which treats reconnection-of-developers as needing organisational structure — is a direct complement.
• incompleteThe Norwegian / Lean-Norwegian context is implicit but not theorised. The åremål concept comes from Norwegian political and academic life and is being repurposed for engineering leadership. The fagtid concept has roots in Norwegian work-culture autonomy ideas. The DORA / Lean / Toyota convergence Truls names at the end is itself partially a Nordic management-culture convergence. There is a comparative essay latent here that the episode does not write.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in parallel with NAV's 'optimizing for fast flow' piece (already in the user's queue), with Norwegian Self-Determination Theory–inflected management writing (autonomi, mestring, mening), and with the wider tradition of Nordic engineering culture vs. anglophone agile-at-scale. The user's coding-agents corpus already includes Nils Brede Moe (no relation? — but a Nordic empirical-software-engineering voice in the same neighbourhood, including the upcoming Heis episode 9).
• incompleteThe article never discusses failure modes of the mapping/gardening practice itself — e.g. the coping-mechanisms-substitute-for-repair pattern already identified in the corpus, where organizations build translators, dashboards, or maps that make incoherence bearable without ever fixing it. Faull's proposed coherence dashboard/framework risks becoming exactly this kind of coping mechanism rather than a forcing function for repair.
  Coherence, Connections, and… Spacetime Crystals — read next: See extract-tbm-434-how-maps-can-hide-problems#p5 and #p6 for the coping-substitutes-for-repair pattern this document doesn't engage.
• incompleteNo worked example or case study illustrating the mechanism, despite the author's framing ('one pattern I keep seeing in transformation work') implying repeated first-hand observation. The whole causal chain — workaround, recovered performance, false leader confidence, permanent normalization, invisible dysfunction — is asserted in the abstract.
  Pascal BORNET's Post — read next: Look for a concrete transformation-consulting case study or postmortem that walks through this exact sequence with names, timelines, and what redesign actually looked like.
• incompleteNo diagnostic method is given. The post's central prescription — 'ask where people are quietly compensating for structural failure' — presupposes that compensation is discoverable, but by the post's own logic that compensation is exactly what stays invisible to leadership. No audit technique, survey instrument, incident-review practice, or workload signal is proposed for actually surfacing it.
  Pascal BORNET's Post — read next: Practitioner or academic sources on surfacing invisible/absorbed organizational work — e.g. resilience-engineering methods (Hollnagel/Woods/Dekker) for observing adaptive capacity, or workload/burnout diagnostic instruments.
• 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 piece analyzes portfolio movement from a God's-eye systems view and never addresses the political economy of admitting an asset belongs in Liquidate or a Build Trap -- whose careers, teams, and budgets depend on the asset continuing, who has the authority to call the move, and what happens when the people who benefit from an asset's continuation are also the people who would have to authorize its liquidation. This is the same organizational-authority gap already flagged in extract-tbm-416-investment-stewardship-as-habit's open gaps about who has standing to insist on stewardship habits.
  TBM 430: Incubate, Compound, Refinance, Liquidate — read next: extract-tbm-416-investment-stewardship-as-habit#g1 (authority to insist on stewardship habits); sunk-cost and loss-aversion behavioral-economics literature; organizational-debt concept.
• incompleteNo cost accounting for the review process itself — the custodian-time cost of quarterly reviews across what the piece implies are hundreds of systems is never mentioned, an interesting omission for an organization that otherwise frames its practices in terms of barriers and cost.
  What good software looks like at REA — read next: Organizational-debt literature on the overhead cost of governance and measurement processes themselves, not just the systems they measure.