Post
JA EN

Which Layers You Can Leave Free, and Which You Have to Nail Down: Looking for Companies That Succeed by Letting Everyone Pick Their Own Stack

Posted
By
18 min read
Which Layers You Can Leave Free, and Which You Have to Nail Down: Looking for Companies That Succeed by Letting Everyone Pick Their Own Stack
  • Target audience: CTOs, VPs of Engineering, EMs, and tech leads deciding whether to lean toward team autonomy or technical uniformity
  • Prerequisites: Experience working on a software team. Stands alone without the companion articles (linked at the end)
  • Reading time: ~15 minutes (full read) / ~5 minutes (key points)

Overview

I wrote two articles on what breaks in an organization that leaves technology choices to each team. After finishing them, an obvious counter-question remained. Are there companies that succeed by doing the opposite, by staying free-for-all?

There must be, I assumed, so I went looking. Amazon, Netflix, Spotify, Valve. The companies routinely described as “teams pick whatever technology they want,” checked down to primary sources. This wasn’t an exhaustive survey, and I should say up front that it covers four frequently-cited companies, no more.

The short answer: I didn’t find one that stays genuinely free and succeeds. What I found instead is more specific and more useful. Every one of these companies deliberately separates which layers stay free from which layers get nailed down. Amazon left the implementation layer completely open and, in exchange, fixed the interface between teams at a level where violating it meant getting fired. Netflix declines to mandate its standard and pays a continuous cost in talent density and context supply instead.

I also found the record of an organization that didn’t separate the layers. Spotify. A former employee’s 2020 retrospective describes ways of working diverging team by team, making it harder for people to move between squads1. And in that same year, Spotify itself published the Golden Path article acknowledging a “fragmented ecosystem of developer tooling”2. The pieces fit together.

This article checks what those four companies actually do, then sorts the question into four layers: which you can leave free and which you have to nail down. After that, it narrows the conditions for freedom to three. The goal is to give you a way to test whether “we value autonomy here, so we don’t standardize” actually meets those conditions.

Amazon: buying implementation freedom with a rigid boundary

The claim that Amazon lets teams pick whatever they want traces back to a piece Steve Yegge wrote in 2011. He wrote it while at Google, meant it to stay internal, published it publicly by accident, and in it he reconstructs from memory a mandate Bezos supposedly issued around 2002, after his own six and a half years at Amazon3.

Worth saying first: this is not an Amazon document. Yegge himself dates it as “back around 2002 I think, plus or minus a year.” It gets quoted as established fact, but it’s one former employee’s recollection.

With that noted, the part everyone quotes turns out to be item four.

It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter3

The interesting question is what the three items before it say.

All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever3

Then comes “all service interfaces, without exception, must be designed from the ground up to be externalizable,” and item six is “anyone who doesn’t do this will be fired.” (Item seven is a joke about having a nice day, but Yegge goes out of his way to note that item six was quite real)3.

So the freedom of technology choice arrives bundled with an absolute fixing of the interface. The implementation layer got opened by clamping the boundary layer shut. Requiring the interface to be externalizable on top of that closes off the option of a sloppy internal-only interface.

There’s a second price. Amazon CTO Werner Vogels, in a 2006 ACM Queue interview, described each service as having a team attached to it that is completely responsible for it, from scoping the functionality through architecting, building, and operating it. Then:

You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer4

You pick what you like. And you operate what you picked, around the clock. Choice and operational responsibility landing on the same person is what stops technology selection from becoming careless. “This looks fun, let’s try it” only clears the bar when the person getting paged at 3am is you.

Netflix: freedom is the consequence of an investment, not the premise

That Netflix doesn’t mandate adoption of its officially supported paved road came up in the companion article5. What I want here is the next question: why does it work without a mandate?

Part of the answer is in what the paved road contains. The tooling Netflix enumerates in its full cycle developer post is operational: deployment, monitoring, alerting, incident response5. Once a developer owns their service around the clock, that doesn’t hold together unless the operations and observability tooling is already there. Implementation choice stays free; this part is supplied centrally.

The rest is in the official culture document, which spells out the preconditions.

Managers carry an obligation. Their job is defined as “giving their teams the context and clarity needed to make good decisions instead of trying to control everything themselves.” And the sentence that tends to get dropped when this gets quoted follows immediately.

context not control should not be confused with hands-off management6

There’s also a premise about people. The official text says it takes an “unusually responsible person” to thrive on this level of freedom: self-motivated, self-aware, self-disciplined, not waiting for direction6. The vacation policy is “Take vacation.” The expense policy is “Act in Netflix’s best interests.” You can minimize rules only when the people who remain don’t break without them.

So the freedom isn’t Netflix’s starting point. It comes later, as the result of paying to gather and keep that kind of person and of managers continuously supplying context. Get the order backwards and hand out only the freedom, and what’s left is hands-off management.

Spotify: the record of an organization that didn’t separate the layers

This was the most instructive case. Spotify, long cited as the exemplar of an organization that went all-in on autonomy, has a published account of failure from someone who was there.

The key points from Jeremiah Lee’s 2020 piece, “Spotify’s Failed #SquadGoals”1:

“Autonomy requires alignment.” But at Spotify, the documentation on alignment and accountability never got finished, and only the autonomy part reached the world. The “Spotify model” everyone copied was aspirational, not a description of reality. The co-author and multiple agile coaches had been telling people not to copy it for years.

On the consequences, Lee quotes former agile coaches.

Every time you have a new team, they have to reinvent the wheel in how they should be working. (Joakim Sundén, at Spotify 2011–2017)1

If you have inconsistent ways of working, it’s more difficult for people to move… it will just reinforce until all of a sudden, you’re not really working for the same company anymore. (Jason Yip)1

What Lee describes is the absence of a defined common process for cross-team collaboration. Letting every team have a unique way of working meant each team needed a unique way of engagement when collaborating1.

Worth separating carefully here. Lee’s article is about inconsistency in ways of working, not about the dispersion of the technology stack itself. The one acknowledging fragmentation on the technical side is Spotify.

That same Spotify published the Golden Path article in 2020. They called the fragmented ecosystem of developer tooling rumour-driven development and described building an opinionated, supported path2.

The organizational model cited for years as the exemplar of free-for-all was written off as a failure by someone who was there, while the company itself moved to the side that builds paved roads. Spotify the business is a success, so what failed was the model. The blunt conclusion is that the citation simply never got updated.

Valve: what “flat” actually looks like, and the limits from the research

I also checked Valve, famous as a flat organization without bosses.

The Journal of Organization Design carries a four-page piece by Matthew McCaffrey in its Point of View section. It reviews Foss and Klein’s book Why Managers Matter (2022), and it isn’t empirical research. The Foss and Klein argument that McCaffrey endorses as persuasive and summarizes comes to three points7.

  • Bossless and flat organizations sometimes work well under relatively certain and stable conditions, but in more dynamic and time-sensitive situations they typically struggle with innovation, scale, and longevity
  • Management hierarchy performs valuable economic functions by solving coordination and cooperation problems and providing a framework within which employees make decisions
  • Valve appears as an example of replacing formal hierarchy with informal hierarchy, and is described as having struggled with the creative inertia that comes from a lack of formal management

Two layers of caution apply. This is a commentary rather than empirical research, and it argues one side of a debate (the pro-management side). Valve is also private, with little internal data available. Don’t treat this evaluation as settled. What’s worth holding onto is narrower: the claim that going flat makes you faster is not treated as self-evident on the academic side.

Valve doesn’t appear in the layer discussion that follows. It removed hierarchy itself rather than any technology-selection layer, which puts it upstream of the question. I’m keeping its scope separate.

The structure that emerges: four layers

Line the four companies up and the question stops being freedom versus control. It becomes a question of where you cut the layers.

flowchart TB
    subgraph FIX["Nail down (the joints between teams)"]
        L1["Layer 1<br>Interfaces between teams"]
        L2["Layer 2<br>Operations and observability floor"]
    end
    subgraph FREE["Can stay free (inside a team)"]
        L3["Layer 3<br>Implementation: language, framework, libraries"]
        L4["Layer 4<br>Process within a team"]
    end

Top and bottom aren’t stages. They’re the fixed side and the free side, side by side.

LayerTreatmentWhyExamples
1. Interfaces between teamsNail downLoosen this and another team’s change breaks you. This is the organization’s couplingAmazon’s API mandate3, Zalando’s API First8
2. Operations and observability floorNail downWithout logs, tracing, metrics, and deployment lined up, other teams can’t help during an incidentMonzo’s scaffold (logs and tracing on by default)9, Netflix’s operational tooling5
3. Implementation (language, framework, libraries)Can stay freeNot unconditionally. The conditions come nextAmazon: “doesn’t matter what technology”3
4. Process within a teamShould stay freeControlling it gains nothing and costs autonomyNetflix’s minimal rules6, Moe et al.10

What organizations get wrong is inverting this. They try to control layer 4 (how a team works) while leaving layers 1 and 2 (boundaries and operations) alone. I suspect that inversion is why standardization arguments get so tangled.

What travels is the layer split itself. All four are enormous companies, and neither the level Amazon imposed on layer 1 nor the talent cost Netflix carries is reproducible as-is at a few dozen to a few hundred engineers.

“What should be aligned is the path, not people’s discretion,” from “What Quietly Breaks When Every Team Picks Its Own Stack,” translates into layer language like this. The path is layers 1 and 2. The discretion is layers 3 and 4.

Three conditions for freedom to work

Whether you can actually leave layer 3 free comes down to these three.

Condition 1: layers 1 and 2 are already fixed

Amazon could open up implementation because it had already fixed the interface at a violate-and-you’re-fired level3. Leave the boundary loose and free up only implementation, and another team’s technology choice lands directly in your incident response.

The test on your own organization is easy. Is there any code reading another team’s data store directly? If yes, layer 1 isn’t fixed, and freeing layer 3 in that state has the order backwards.

Condition 2: choice and operational responsibility sit with the same team

“You build it, you run it”4. If the person choosing doesn’t operate it, choosing is an act of pushing cost onto someone else. Free up technology selection in a structure where a different team takes over operations, and no cost returns to the chooser, so the count grows without limit.

Plenty of organizations split development and operations, or contract operations out. In that case layer 3 freedom is missing its premise.

Condition 3: talent density, and someone supplying context

The “unusually responsible person” and the manager who keeps supplying context that Netflix states explicitly6. Hand out freedom where those two are absent and you get hands-off management. The official document bothers to say “don’t confuse context not control with hands-off management” presumably because people confuse them.

And Spotify showed what happens when that supply is interrupted. Autonomy went out while the alignment documentation stayed unfinished, and teams ended up reinventing how to work1.

These three aren’t a simple AND. The relationship is that a missing condition can only be covered by fixing the remaining ones harder.

Amazon is the clear illustration. Nothing resembling Netflix’s talent density argument appears in Yegge’s recollection or Vogels’ interview. Whether condition 3 is met isn’t something the sources checked here can determine. What Amazon did instead was push condition 1 to the extreme of getting fired for violations (the firing line being itself part of a recollection, as noted earlier). When one condition is weak, another goes to an extreme. That’s the compensation structure.

Put the other way: an organization mediocre on all three has no layer 3 freedom. And at a few dozen to a few hundred engineers, not many organizations have even one of these pushed to an extreme. “We value autonomy here, so we don’t standardize” usually hasn’t been through this examination.

The companion article, “Where to Start in an Organization With No Standards,” also has three conditions (fast / recorded / changeable), and they’re different ones. Those are conditions for making the path side (layers 1 and 2) work; these are conditions for permitting the discretion side (layer 3). They complement each other.

Common misreadings

“Netflix is free, so we can be free”

Netflix’s freedom is a result, not a premise. It comes bundled with continuous investment in talent density and a manager’s obligation to supply context. And the paved road exists, and gets used because it’s fast5. Import only the freedom part and you get a Netflix without the paved road.

“Let’s do the Spotify model”

That model was aspirational rather than descriptive, and someone who was there wrote publicly that it failed1. The co-author and multiple agile coaches have been saying don’t copy it. Arguing for autonomy on the basis of the “Spotify model” in 2026 means leaning on a citation that never got updated.

“Amazon lets teams pick whatever technology they want”

They do. They have zero choice about how they communicate with other teams3. And they operate what they picked4. Take home the freedom part without those two and you have something other than Amazon’s design.

“Standardizing reduces autonomy”

Depends on the layer. Controlling layer 4 does reduce it, but fixing layers 1 and 2 is what makes layer 3 freedom possible. In Moe et al.’s comparison of two large-scale agile cases, the approach that excluded managers from membership and had a community of all teams, product owners, and experts decide was the one where teams could influence architecture, requirements, and organizational direction10 (that study also appears in “Where to Start in an Organization With No Standards”). Change who decides, and deciding doesn’t have to cost autonomy.

Wrapping up

I went looking for companies that succeed by being free-for-all and didn’t find one. What I found were companies that deliberately separate the free layers from the fixed ones, and a company that published what happened when it didn’t separate them.

Amazon opened the implementation layer completely and, in exchange, fixed the inter-team interface at a violate-and-you’re-fired level (per the recollection) and stapled operational responsibility onto the freedom of choice. Netflix declines to mandate its standard and pays a continuous cost in talent density and context supply, with the official text saying not to confuse this with hands-off management. Spotify handed out autonomy without separating the layers, ended up with teams reinventing how to work, and built a Golden Path afterward. On flat organizations generally, the organizational-design side argues they can work under stable conditions but struggle with innovation, scale, and longevity in dynamic ones, with Valve cited there as a case of replacing formal hierarchy with informal hierarchy.

Sorted out, it’s four layers. The interface between teams and the operations and observability floor get nailed down. Implementation and process within a team can stay free. Most organizations do this backwards, weighing in on how a team works while leaving boundaries and operations alone.

Three conditions govern layer 3 freedom. Layers 1 and 2 fixed first. Choice and operational responsibility in the same team. Talent density and someone supplying context. Not a simple AND: a missing condition can only be covered by fixing the rest harder. Mediocre on all three and it isn’t freedom, it’s hands-off management.

As long as the discussion runs as autonomy versus control, it never reaches this. Replacing the question with “which layer are we talking about?” gets there faster.

What breaks in an organization with a scattered stack is covered in “What Quietly Breaks When Every Team Picks Its Own Stack,” and where to start and how to get it through the organization in “Where to Start in an Organization With No Standards.” This article started from the counter-question to those two: isn’t there a case for the freedom side?

You may also be interested in these related articles:

References

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

  1. Spotify’s Failed #SquadGoals - Jeremiah Lee (2020). 【Reliability: Medium】An insider retrospective by a former Spotify employee. A personal view that quotes several colleagues, but not Spotify’s official position ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5 ↩︎6 ↩︎7

  2. How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem - Spotify Engineering (2020). 【Reliability: Medium-High】First-party account ↩︎ ↩︎2

  3. Stevey’s Google Platforms Rant - Steve Yegge (2011). 【Reliability: Needs verification】Not an Amazon document. A paraphrase from the memory of a former employee (six and a half years there). The author dates it himself as “back around 2002 I think, plus or minus a year.” Widely quoted, but the original document has never been published. The detail that it was meant to stay internal and was published by accident isn’t in the gist itself; it comes from contemporary reporting (Forbes / TechCrunch, 2011) ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5 ↩︎6 ↩︎7 ↩︎8

  4. A Conversation with Werner Vogels - Werner Vogels, interviewed by Jim Gray / ACM Queue (2006). 【Reliability: Medium-High】A first-party interview with Amazon’s CTO. The origin of “You build it, you run it” ↩︎ ↩︎2 ↩︎3

  5. Full Cycle Developers at Netflix — Operate What You Build - Netflix Technology Blog (2018). 【Reliability: Medium-High】First-party account ↩︎ ↩︎2 ↩︎3 ↩︎4

  6. Netflix Culture - Netflix. 【Reliability: Medium-High】The company’s official culture document. A recruiting document; any gap between it and practice isn’t verifiable from outside ↩︎ ↩︎2 ↩︎3 ↩︎4

  7. Who’s the boss? The persistence of entrepreneurial hierarchy in flat organizations - Matthew McCaffrey / Journal of Organization Design 12:37-40 (published online November 2022, issue 2023). 【Reliability: Medium】Not a peer-reviewed research article but a Point of View commentary (four pages). It reviews Foss & Klein’s Why Managers Matter (2022), and the three points cited above are McCaffrey summarizing and endorsing that book’s argument. The Valve material is likewise based on public information rather than original research ↩︎

  8. Zalando RESTful API and Event Guidelines - Zalando. 【Reliability: Medium-High】A published internal standard in active use. No quantified effect data ↩︎

  9. How Monzo’s Opinionated Platform and Tools Support their Developer Experience - Container Solutions, interview with Suhail Patel (Monzo). 【Reliability: Medium】Practitioner testimony, not third-party verified ↩︎

  10. Finding the sweet spot for organizational control and team autonomy in large-scale agile software development - Moe, Šmite, Paasivaara, Lassenius / Empirical Software Engineering 26, 101 (2021). 【Reliability: High】Peer-reviewed. A two-company case study, so generalize with care ↩︎ ↩︎2

Management・Organization
Tech Standardization Org Design Team Design Platform Engineering Organizational Change
This post is licensed under CC BY 4.0 by the author.