What Quietly Breaks When Every Team Picks Its Own Stack: Diagnosing "No Standards" Across Six Axes

• Target audience: CTOs, VPs of Engineering, EMs, and tech leads at organizations of a few dozen to a few hundred engineers struggling with stack fragmentation, aging systems, and knowledge that never accumulates
• Prerequisites: Experience working on a software team. No familiarity with Platform Engineering or Golden Paths required. The how-to-start and how-to-sell side is covered in the companion article (linked at the end)
• Reading time: ~18 minutes (full read) / ~6 minutes (key points)

Overview

Past a few dozen engineers, a cluster of symptoms tends to show up together. Technology choices are left to each team and each individual, and the stack has spread out wide. Meanwhile the core product runs on something aging that ought to be replaced, and no one has written down when, what, or how. There is a place to put knowledge, but opening another team’s page rarely helps because none of it transfers to your environment. Nobody measures how long a new hire takes to become productive. Incident reviews exist as a process, but they are thin, and similar failures keep recurring somewhere else. And mid-career engineers leave, saying some version of “experience doesn’t compound here.”

These look like separate problems. They come from one structure. When technical diversity gets high enough, the transferability of whatever knowledge the organization has accumulated approaches zero. Knowledge that doesn’t transfer doesn’t get read, unread documents don’t get updated, and un-updated documents mean the next person solves it from scratch. Compounding stops working, and the people who most expected compounding are the first to leave a place where it doesn’t.

There is a second-order problem. In this state, the organization also can’t decide to retire anything. With no criteria for replacement, modernization becomes a volunteer side project. The old technology stays and a new one gets added on top. Modernization ends up functioning as an accelerant for fragmentation.

Spotify had a name for their own version of this: rumour-driven development¹. Their strong commitment to autonomous teams produced a fragmented ecosystem of developer tooling, and knowledge transfer came to depend on informal networks of colleagues. Autonomy isn’t the villain here. Handing out autonomy without building the shared substrate that supports it produces this.

This article breaks down why the state arises, then turns it into something you can diagnose: not “do we have standards or not” but six axes scored on five levels. The point is to place your organization using observable facts rather than a feeling. Where to start and how to get a proposal through the organization is the companion piece, “Where to Start in an Organization With No Standards, and How to Get the Proposal Through.”

The symptoms split into six axes

Here are the symptoms above, decomposed into things you can measure independently.

1. Technology selection governance (who decides what new things get used, on what basis)
2. Renewal and retirement (when and how old things get dropped)
3. Knowledge transferability (whether accumulated information is usable by another team)
4. Onboarding visibility (whether you measure how long a new hire takes to contribute)
5. Learning from failure (whether incidents change the next design)
6. Cross-cutting shared foundation (what is aligned, and how far up the stack)

Axes 1 and 2 are separated on purpose. They look like the same “technology policy” question, but they carry different kinds of difficulty. Choosing what to adopt is something the chooser can settle alone. Deciding when to drop something means touching a running system and changing what somebody’s job is. Plenty of organizations tidy up the first and leave the second alone.

Most organizations have these six axes at wildly different stages. A common combination: the shared API platform and cloud account management are aligned org-wide, while everything above that layer is a free-for-all. Having only the infrastructure layer aligned is the most misleading state of all. It creates the belief that “we do have cross-cutting standards,” while the layer engineers actually touch every day has none.

The shape of the loop

The six axes can be measured independently, but they degrade together.

flowchart TB
    A[No criteria for<br>tech selection] --> B[Stack fragments]
    A --> H[No retirement policy]
    H --> I[Replacement becomes<br>a solo effort:<br>one more technology]
    I --> B
    B --> C[Other teams' knowledge<br>doesn't transfer]
    C --> D[Docs go unread<br>and unmaintained]
    D --> E[Same problems solved<br>from scratch everywhere]
    E --> F[Mid-career engineers feel<br>nothing is compounding]
    F --> G[Attrition erases<br>tacit knowledge]
    G --> A

Unless you cut this loop somewhere, initiatives get swallowed. Ordering people to write more documentation won’t restore D while C is unsolved. Likewise, launching a legacy-replacement project while A is blank just routes through I and lands back at B.

The next five sections walk through where and how this loop turns.

Mechanism 1: Diversity kills transferability (axis 3)

When a knowledge repository goes hollow, the diagnosis is usually “we don’t have a writing culture.” In a fragmented organization, a condition further upstream has already broken.

For a piece of knowledge to help another team, the writer’s environment and the reader’s environment need enough overlap. If the language, framework, CI, deployment method, and logging stack all differ, then “the gotchas we hit with DB connection pooling” is a string of proper nouns to everyone else. Writers half-sense this, so they stop writing. What does get written drifts up to generic advice, and generic advice isn’t findable by search and isn’t useful when found.

The higher the technical diversity, the fewer readers a single document can reach. Fewer reachable readers means lower expected value for the writer. This is not a question of document volume. It’s a question of return on investment. Leave the structure in place and tell people to write more, and what you get is documents written for auditors (I covered that phenomenon itself in “Documentation Theater”).

This is the starting point. Everything below derives from this missing transferability.

Mechanism 2: Without measurement, you can’t tell it’s getting worse

An organization that doesn’t measure onboarding has no way to judge whether things are degrading. If a new hire takes four months to ramp, nobody knows whether that was two months or five months three years ago. Fragmentation advances over years, so absent measurement, the change gets absorbed as “just how it is.”

DX Core 4 proposes time to 10th PR as the ramp metric². Time to first commit gets artificially fast because of sign-up and account-registration chores, so the tenth PR is a cleaner proxy for reaching sustained contribution. Even that single metric can surface a pattern where teams on more fragmented stacks ramp more slowly. That last part is my read, not a published empirical finding, so measure it in your own organization before believing it.

What makes the absence of measurement awkward is that it inconveniences no one directly. Nothing hurts, so it never gets prioritized, so nothing gets measured, so the degradation stays invisible. This axis is also the only sensor you have for the other five.

Mechanism 3: Without policy, old things can’t move either (axes 1 and 2)

An organization with no selection criteria doesn’t only break in the direction of adding technologies. It breaks equally in the direction of never retiring them.

Retirement decisions are far heavier than adoption decisions. They mean stopping a running system, and they mean changing the work of whoever has owned that technology. If nobody is designated to decide, nobody decides. Frameworks and runtimes that are visibly at end of life survive for years past their support windows.

Then somebody gets alarmed enough to act, and with no policy in place, the new technology gets picked according to that person’s taste. The old system never fully migrates, so the new one runs alongside it. The count goes up by one instead of down by one. A few years later that person leaves, and the technology that was supposed to be the new one becomes legacy that nobody will touch. Organizations that went down this path have added one technology for every modernization push they made.

In Stack Overflow’s 2024 survey, the top frustration developers reported was technical debt at 62.4%, with second and third being the complexity of the tech stack for builds (32.9%) and for deployment (32.3%)³. They’re tabulated as separate problems, but they’re two sides of the same hole: the old things nobody could discard, and the new things that multiplied. Both trace back to no one in the organization owning the technology lifecycle.

Mechanism 4: Hollow incident reviews are a learning-loop problem, not a culture problem (axis 5)

When incident reviews end at “we’ll be more careful next time,” it gets read as a problem of individual attitude. In Argyris’s terms, it’s a system stuck in single-loop learning⁴. Single-loop learning corrects the action. Double-loop learning interrogates the policies, assumptions, and incentives that produced the action.

Push into “why did we choose this design,” “why were we on this technology,” “why were we running something past end of support,” and you necessarily arrive at selection and retirement. If the organization has no criteria there, the discussion dead-ends. With nowhere left to go, wrapping up at the level of behavior is the only option. The hollowness is a result, not a cause.

Argyris, in Overcoming Organizational Defenses (1990), defined organizational defensive routines as any policy, practice, or action that prevents embarrassment or threat to the people involved while simultaneously preventing learning⁴. A thin postmortem fits that definition exactly. Nobody gets hurt, and nothing changes.

Which means urging people to “reflect more deeply” won’t work. There’s nothing changeable at the bottom of the deeper reflection. The operational details live in “Running Blameless Postmortems.”

Mechanism 5: Mid-career people leave first (axes 3 and 2)

The feeling that experience isn’t compounding hits hardest in mid-career. For juniors, touching a scattered set of technologies is itself learning. Mid-career engineers are watching whether the time they invest converts into solving the next problem faster. Solving from scratch every time registers directly as time here losing value.

A survey study of 224 software professionals found job satisfaction and job embeddedness to be strong predictors of turnover intention⁵. Embeddedness is determined by the assets you accumulate that only work at this organization and by the connections you’d lose on leaving. Reasoning from that framework, an organization where technologies are scattered and knowledge stays with individuals ends up, ironically, with thin organizational assets and therefore low embeddedness. The cost of leaving is low. That last inference is mine, derived from the definition of embeddedness, not something the study tested directly.

Axis 2 bites here too. A mid-career engineer pinned to an aging technology feels their market value depreciating daily. With no replacement policy, there’s no visible release date either. As reasons to leave go, this one is the quietest and the strongest. Exit interviews record it as “wanting a new challenge,” so the structure stays invisible from the inside.

Then the tacit knowledge that person held disappears, and the loop returns to the top.

The awkward part: control doesn’t fix it

In Stack Overflow’s 2025 developer survey, only 45.6% of developers said they were not looking for a new role. “Considering somewhat” (28.8%) plus “considering strongly” (14.8%) puts 43.6% in play, and including those who actually changed jobs in the past year (8.8% voluntarily, 2% involuntarily) takes it past half. The attribute ranked first for contributing to job satisfaction was autonomy and trust to manage your own tasks⁶.

This is what makes the standardization argument hard. Tighten control and you erode autonomy. Leave it alone and nothing compounds. There are attrition drivers in both directions. How to resolve that tension is the companion article’s subject. What matters at the diagnostic stage is this: the moment you translate “we’re not aligned” into “we lack control,” you’ve picked the wrong prescription. What should be aligned is the path, not people’s discretion.

Diagnosing severity across six axes

Here’s the actual instrument. Each axis gets levels 0 through 4. Place your organization on observable facts rather than impressions.

Axis 1: Technology selection governance

Lv	State	Observable signs
0	No criteria	No record anywhere of who chose what, or why
1	Implicit convention	There’s a “roughly this,” undocumented, and it wobbles on each new project
2	Recommended list exists	A list of recommended technologies exists, with no procedure for departing from it
3	Deviation has a procedure	Going off-list requires a recorded rationale (an ADR) and an agreement process
4	Recommendations get updated	The list itself rotates periodically based on proposals from the field

There’s a big step between Lv2 and Lv3. Making a list takes a day, but a list with no deviation procedure gets treated as a list you don’t have to follow.

Axis 2: Renewal and retirement

Lv	State	Observable signs
0	Not tracked	The organization can’t produce a list of what runs on which version
1	Inventory exists	An audit happened, but whether to upgrade is left to each team
2	Crisis-driven	Action happens only when support ends or a vulnerability lands
3	Retirement criteria exist	Technologies marked “not for new work” are explicit, with migration deadlines
4	Migration is supported	Moving off a retiring technology comes with shared runbooks, allocated capacity, and an owner

Lv2 is the most common. It also looks like it’s working, so urgency stays low. A good test: can you name the things that aren’t yet out of support but will be within three years? If not, you’re at Lv1 or below.

The Lv3 declaration of “not for new work” costs close to nothing and does a lot. You don’t have to stop anything that’s running, and the count stops growing.

Axis 3: Knowledge transferability

Lv	State	Observable signs
0	No repository	Information lives in chat logs and individual heads
1	Repository only	There’s a wiki, but another team’s page doesn’t transfer to your situation
2	Partial circulation	Knowledge flows only among the few teams on the same stack
3	Referenced across teams	Concrete cases exist of someone solving a problem by reading another team’s docs
4	Reference is measured	Access logs, owners, and review deadlines manage whether documents are alive

Lv1 is both the most common and the most frequently misdiagnosed. “We have a knowledge sharing platform” is a true statement at Lv1. Put the test on evidence rather than existence: has anyone actually solved a problem this month using another team’s page?

Axis 4: Onboarding visibility

Lv	State	Observable signs
0	Unmeasured	Nobody knows how long a new hire takes to become productive
1	Gut feel only	There’s a shared sense of “about three months,” with no number
2	Numbers exist	Time to 10th PR is collected but isn’t connected to any initiative
3	Differences are visible	Ramp times are compared across teams and across stacks
4	Improvement loop runs	Ramp bottlenecks get identified, environments and docs get fixed, and the number moves

Moving from Lv0 to Lv2 takes about a week at most organizations, because the PR data already exists. That it doesn’t happen is because nobody has decided what to do after measuring, which is the flip side of having no real move available while axis 1 sits at Lv2 or below.

Axis 5: Learning from failure

Lv	State	Observable signs
0	No sharing	Incidents stay inside the affected team
1	Ritualized	Postmortems happen and end at “we’ll be more careful”
2	Actions get written	Action items get produced, aren’t tracked, and more than half go stale
3	Assumptions get questioned	Discussion reaches “why that design, why that technology”
4	Learning returns to the standard	Findings change recommended technologies, templates, or the retirement list

The reason organizations can’t escape Lv1 is, as in Mechanism 4, that the discussion has nowhere to go. Reaching Lv3 takes more than psychological safety. It takes the existence of a place where design decisions can be changed.

Axis 6: Cross-cutting shared foundation

Lv	State	Observable signs
0	Nothing aligned	Even cloud accounts differ team by team
1	Infrastructure only	Shared API platform and account management are aligned; everything above is free
2	Templates exist	There’s a service-creation template, and not using it is normal
3	A Golden Path exists	The recommended route is the fastest one, and most new services go through it
4	The path runs as a product	It improves based on usage data, and reasons for deviation feed back in

Lv1 is a trap. Having only infrastructure aligned reads as “standardization is progressing” from the executive floor and as “nothing is aligned” from the field. That perception gap keeps the priority down indefinitely.

Reading the profile

Lay the six levels side by side. The state described at the top of this article usually produces roughly this profile.

Axis	Level
1. Technology selection governance	0–1
2. Renewal and retirement	0–2
3. Knowledge transferability	1
4. Onboarding visibility	0
5. Learning from failure	1
6. Cross-cutting shared foundation	1

All axes pinned at 0–1 is Phase A (not started). Some axes up at 2–3 is Phase B (patchy). Most at 3 or above is Phase C (working).

The six levels combine more like multiplication than addition. Leave one at 1 and raising the others to 3 or 4 still drags the whole thing back toward 1. So the goal of the diagnosis isn’t finding an axis you can grow. It’s finding the lowest axis. Which combinations jam in which way is covered with examples in the companion article’s Phase B section.

Wrapping up

What breaks in an organization that leaves technology selection to individual discretion isn’t the technology. It’s the transferability of knowledge. It doesn’t transfer, so it isn’t written; it isn’t written, so it isn’t measured; it isn’t measured, so the decline goes unnoticed; unnoticed, incident reviews stop at the behavioral level; stopping there, the same problem repeats somewhere else. Mid-career engineers leave first because they are the group that estimates the missing compounding most accurately.

The absence of policy works in both directions: more new technologies, and fewer old ones removed. With no criteria for replacement, someone acts, the old thing stays, and one more thing gets added. Organizations that have added one technology for every modernization push are not rare.

The diagnosis isn’t a binary of whether standards exist. It’s a level per axis: selection governance, renewal and retirement, transferability, onboarding visibility, learning from failure, and the shared foundation. Having only infrastructure aligned (axis 6 at Lv1) is the classic trap where executives and the field see different realities.

One thing to watch: don’t read the diagnosis as “we lack control.” The attribute that contributes most to developer job satisfaction is autonomy and trust, and prescriptions that tighten control manufacture a different attrition driver. What should be aligned is the path, not people’s discretion.

Where to start and how to get the proposal through the organization is covered in the companion article, “Where to Start in an Organization With No Standards, and How to Get the Proposal Through.” It walks through Monzo running 2,000 services with about 200 engineers, Netflix declining to mandate its standard, and Zalando putting a practitioner guild in charge of one, then lays out phase-specific moves and the material you need to persuade people who don’t see the need.

Related Articles

You may also be interested in these related articles:

• Where to Start in an Organization With No Standards, and How to Get the Proposal Through - The companion article: case studies, phase-specific moves, and how to sell it internally
• Fix Organizational Context Supply First - The whole picture of an organization where knowledge doesn’t flow, and 12 cross-cutting symptom patterns
• Documentation Theater - The structure of organizations that write a lot and whose docs are all dead
• Running Blameless Postmortems - Implementation that keeps failure sharing from becoming a ritual
• Tool Sprawl and Single Source of Truth - Consolidating by topic rather than by tool
• Organizations Where Accumulation Never Happens - Knowledge management assuming people rotate out

References

References are numbered to match the citation markers in the text.

Additional references (not cited by number in the text)

• What Really Matters? Turnover Intention Factors of Software Developers - ICSIM 2024. 【Reliability: Medium-High】

1. How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem - Spotify Engineering (2020). 【Reliability: Medium-High】First-party account. A practice report rather than a quantified effect measurement ↩︎

2. Measuring developer productivity with the DX Core 4 - Abi Noda, Laura Tacho, Margaret-Anne Storey, Michaela Greiler / DX (2024). 【Reliability: Medium-High】Involves the creators of the DORA, SPACE, and DevEx frameworks. Reported adoption results are self-reported ↩︎

3. Developers want more, more, more: the 2024 results from Stack Overflow’s Annual Developer Survey - Stack Overflow (2025). 【Reliability: Medium-High】Reporting on the 2024 survey. Self-selection bias applies ↩︎

4. Chris Argyris: theories of action, double-loop learning and organizational learning - infed.org. 【Reliability: Medium】Secondary summary. The single/double-loop distinction is based on this page. The definition of organizational defensive routines comes from the primary source, Argyris, C. (1990) Overcoming Organizational Defenses: Facilitating Organizational Learning, Allyn & Bacon (ISBN 978-0205123384) ↩︎ ↩︎²

5. Staying or Leaving? How Job Satisfaction, Embeddedness and Antecedents Predict Turnover Intentions of Software Professionals - Kuutila et al. (2025). 【Reliability: Medium-High】Survey study with n=224. The arXiv version is a preprint, but the paper is accepted to the ICSE 2026 research track. A single study; see also the ICSIM 2024 reference below ↩︎

6. 2025 Stack Overflow Developer Survey - Work - Stack Overflow (2025). 【Reliability: Medium-High】The full survey drew 49,756 responses across 177 countries, but the job-seeking question drew 35,451 responses and the job satisfaction attribute ranking drew 24,900 (top five countries), so the denominator varies by question. Self-selection bias applies ↩︎