Where to Start in an Organization With No Standards, and How to Get the Proposal Through

• Target audience: CTOs, VPs of Engineering, EMs, and tech leads who want to fix stack fragmentation but are stuck on where to begin or how to get it approved
• Prerequisites: Experience working on a software team. Reading the companion article’s six-axis diagnosis first gives you your organization’s current position
• Reading time: ~20 minutes (full read) / ~6 minutes (key points)

Overview

Technology choices left to each team, knowledge that doesn’t transfer, old systems nobody retires. The companion article, “What Quietly Breaks When Every Team Picks Its Own Stack,” decomposed that state into six axes. This article takes the next step: where to start, and how to get it through the organization.

The conclusion up front: the most common failure in sequencing is launching a company-wide standardization project. An organization with no prior experience of standardization that tries this almost always stalls at “we made a recommended list.” The cost of building consensus is too high to leave any energy for designing the deviation procedure.

DORA’s 2025 research lists “ivory tower” among its platform anti-patterns: rigid top-down standards that alienate developers and produce workarounds¹. A standard has to be designed as the fastest road, not a fence, or it doesn’t function.

So this article runs in four parts. First, what real organizations actually do, read by size. The most useful reference point is Monzo, running over 2,000 services with about 200 engineers; Google and Uber operate at a scale that makes their approaches hard to bring home. Second, the moves that differ by diagnostic phase. Third, the conditions under which standardization becomes actively harmful. And last, what tends to be the real hard part in this space: how to get a proposal through when nobody sees the need. Opposition here contains legitimate arguments, so going in with a make-them-understand posture gets you cut down by a correct objection.

Background: the six axes and five levels

This article uses the companion article’s framework. Here’s a summary for readers arriving directly.

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

Each axis is scored Lv0 through Lv4. Read Lv0 as no mechanism at all, Lv1 as a mechanism in form only, Lv2 as working in places, Lv3 as functioning, and Lv4 as self-updating. All axes pinned at Lv0–1 is Phase A, some up at Lv2–3 is Phase B, and most at Lv3 or above is Phase C. The detailed criteria per axis are in the companion article’s tables.

What real organizations do

Concrete mechanisms travel better than abstract principles. Watch the scale differences, though. These are ordered by how usable they are.

The closest reference point: Monzo (about 200 engineers)

The UK digital bank Monzo runs a system serving 6 million customers with about 200 engineers, holds more than 2,000 microservices (mostly Go), and deploys to production over 100 times a day². For an organization in the tens-to-low-hundreds range, this is the most realistic reference.

Their approach is relentlessly about making the path singular. There’s a defined paved road for starting a new microservice, and per Senior Staff Engineer Suhail Patel, “as a result the microservices all look very uniform”². The scaffold ships with hooks into the ORM and queueing systems, logs and tracing on by default, and standard metrics emitted automatically.

From the companion article’s angle, the decisive part is the effect Patel describes:

You can go and contribute to another team’s service because the structure is entirely familiar to you²

That is transferability itself. Uniformity isn’t the goal here. It’s the precondition for people moving across team boundaries. Uniformity is also what makes security patches and runtime upgrades applicable in bulk, which means axis 2 (renewal and retirement) only turns because axis 6 provides the uniformity.

Patel also states the success criterion: “a mark of success is you can have your entire Monzo career in a product team and never have to interact with Kubernetes or write any YAML at all”². Setting the goal of standardization at “you never have to touch it” rather than “you must comply” is directly reusable.

Not making the standard mandatory: Netflix’s paved road

Netflix maintains a paved road formally supported by central teams, and does not mandate its adoption. Adoption is encouraged by making development and operations on the paved road a far better experience than off it³. It’s the technical expression of their “highly aligned, loosely coupled” organizing principle.

This lines up with DORA’s framing of a fast road rather than a fence¹. A standard functions while deviation stays legal only when the standard wins on speed. Put the other way: if the recommended path is slower, mandating it just produces workarounds. Before considering a mandate, measure whether your recommended path is actually faster.

Creating a body that operates the standard: Zalando’s API Guild

Zalando’s “API First” requires defining APIs in OpenAPI before implementation⁴. What makes it work is the operating model more than the rules themselves. An API Linter Service runs automated checks, and on top of that, early review by peers and client developers plus a lightweight API review process applies. The guidelines themselves are drafted and owned by the API Guild.

The guild is not a management committee. It’s a cross-team community of practitioners. That shape matches what Moe et al. found comparing two large-scale agile cases. In one, area product owners set direction and mandatory processes aligned teams, and team autonomy stayed confined to internal process. In the other, managers were excluded from membership and a community of all teams, product owners, and experts made the decisions; there, teams could influence architecture, requirements, and organizational direction⁵.

Who operates the standard determines adoption as much as its contents do. At a hundred engineers, you can start with this shape before building a dedicated platform team. Form a guild with one person from each team and give it responsibility for maintaining the recommended list and the retirement list. It costs no new headcount.

The parts you can’t copy: Google and Uber

Google restricts officially approved programming languages to five (C++, Java, Python, Go, JavaScript), maintains a style guide per language, and requires approval from someone holding “readability” in that language⁶. The bet is that the benefits of global conformity outweigh local inefficiency.

The mechanism has a price. Brian Kihoon Lee, a former Google engineer who served as a readability mentor, calls it “death by a thousand cuts” and argues that prioritizing global consistency over local efficiency slows research deployment and product velocity. For other companies he recommends “Readability Lite,” a mentorship program without the mandatory gate⁷. Read Google’s approach as something that works because Google has Google’s scale and cash.

Uber’s DOMA is similar. They sorted 2,200 microservices into 70 domains and structured dependencies into five layers. The reported outcomes: platform support costs dropped an order of magnitude, onboarding time fell 25–50%, and one team cut feature integration from three days to three hours⁸. Appealing numbers, but this is the prescription of an organization that lived through the chaos of 2,200 services, and the figures are self-reported. What travels isn’t the numbers. It’s the existence of a practice of periodically reviewing services and re-grouping them into domains.

Standardizing by not adding: Shopify

Aligning isn’t the only response to fragmentation. Shopify keeps its primary functionality in a single large Ruby on Rails application (Shopify Core), and instead of splitting into microservices, divides the monolith internally into components with boundaries enforced by tooling⁹.

Not increasing the number of technologies can be the strongest form of standardization. If you’re at a hundred engineers and midway into a microservices migration, it’s worth confirming that not splitting is still on the table. If you don’t split, there’s nothing to align.

The mechanism you can run today: a Tech Radar

The lightest instrument that handles both selection and retirement without a dedicated team is the Technology Radar. Neal Ford of Thoughtworks published how to build an internal one¹⁰.

• Four rings: Hold (don’t start anything new with this), Assess (worth exploring to understand the impact), Trial (worth pursuing, try it on a project where the risk is tolerable), Adopt (take as standard)
• Four quadrants: techniques, tools, platforms, languages and frameworks (adapt to your context)
• How to run it: nominate on sticky notes, have a facilitator group them, discuss placement, write a paragraph of rationale per item. Review existing entries each round for movement, fade-out, or reinstatement
• Participants: representative senior technologists plus interested parties. The original assumes a fairly small group
• Cadence: annually at minimum, twice a year if you can

The Hold ring is the entry point to axis 2 (renewal and retirement). Stopping a running system is a heavy decision, but declaring “don’t start anything new with this” costs close to nothing and halts further fragmentation. A single half-day workshop can plausibly move axis 1 (selection governance) from Lv0 to Lv2 and axis 2 (renewal and retirement) from Lv0 to Lv3. Little else in this space beats that return on effort.

What an organization that has kept at it says: Mercari

Mercari has been running platform engineering for about seven years. In an interview, Taichi Nakashima said the hard part isn’t the launch period but after the platform gets large. Because it’s already running, requests arrive from every direction and security problems surface. On balancing prioritization against continued evolution, he says there’s no framework and no right answer, and they’re still working by trial and error¹¹.

As the platform team grew, they introduced a fractal structure, a platform for the platform, to distribute cognitive load across teams.

For anyone evaluating adoption, this testimony is useful for calibrating expectations. Standardization is not a project that finishes when you build it. The operating phase is longer and harder. Estimate only the build effort and you stall in year two.

Which case maps to which axis

Axis	Mechanisms worth borrowing
1. Selection governance	Tech Radar10, Zalando’s API Guild4
2. Renewal and retirement	The Tech Radar Hold ring10, Uber’s periodic service review8
3. Knowledge transferability	Monzo’s uniform service structure2, Spotify’s Golden Path12
4. Onboarding visibility	DX Core 4’s time to 10th PR13
5. Learning from failure	Feeding findings back into recommended and retirement lists1
6. Shared foundation	Monzo’s scaffold2, Netflix’s non-mandatory paved road3, Shopify’s non-split9

Moves by phase

The right move differs completely by the phase defined in the diagnosis. Trying to fix everything at once is the most common way this kind of improvement dies.

Phase A: all axes at 0–1

As stated above, don’t launch a company-wide standardization project here. Take this order instead.

Move 1: measure axis 4. Compute time to 10th PR going back two years¹³. The data is already in Git, so this needs no new process and no agreement. It works because it hands every subsequent discussion a shared yardstick. “Fragmentation is hurting us” is an opinion. “Teams on stack X reach their tenth PR in 34 days on average, teams on stack Y in 89” is a fact.

Move 2: build only the Hold list, in a half-day workshop. Don’t attempt the full Tech Radar. Agree first on the list of “don’t start anything new with this”¹⁰. It doesn’t touch stopping any existing system, so political resistance barely appears. Fragmentation stops growing regardless. Axes 1 and 2 both move here.

Move 3: pave exactly one path, the highest-frequency one. DORA consistently recommends starting with a minimally viable platform¹. Rather than unifying every technology, pick only the path for standing up a new service and fix the recommended configuration, template, CI, deployment, and log output on that path alone. This is what Monzo’s scaffold does². Narrowing to one path also makes the outcome measurable: compare ramp time and failure rate between services that went through the paved path and those that didn’t.

Move 4: don’t prohibit deviation, require a reason. Choosing an off-list technology stays allowed. What becomes mandatory is one ADR (Architecture Decision Record). This isn’t a control procedure. It’s groundwork for raising axis 5 (learning from failure) to Lv3, so that when a postmortem asks “why was this the design,” an answer exists.

None of these four break an existing process. For a Phase A organization, a proposal that breaks an existing process carries too much political cost to pass at all.

Phase B: a mix of 2s and 3s across axes

What happens in a patchy state is that the advanced axes get dragged down by the ones that lag. A common case: a Golden Path exists (axis 6 at Lv3) but selection governance hasn’t caught up (axis 1 at Lv1), producing the odd condition of “we have a recommended path but no recommended technologies.” The contents differ every time, so going through the path doesn’t make knowledge reusable.

Another common one: axis 1 climbs to 3 while axis 2 stays at 0–1. New work gets aligned but old things never leave, so the total keeps growing. At this point, allocate capacity to retirement (raise axis 2 to Lv4). While migration depends on each team’s goodwill, the retirement list is a wish list.

The Phase B move is to concentrate on raising the single lowest axis. The six levels behave more like multiplication, and one axis stuck at 1 drags the whole thing back to 1.

One more thing becomes necessary here: a process for updating the recommended list, which is axis 1 at Lv4. Leave recommendations frozen for two years and the field starts to feel it’s being made to comply with an outdated standard, and avoidance behavior begins. DORA’s “ivory tower” anti-pattern describes exactly this state¹. Running the Tech Radar once or twice a year builds the update in automatically¹⁰.

Phase C: most axes at 3 or above

The problem shifts from getting the standard followed to getting the standard to evolve. Axis 3 at Lv4 (measuring how documents are referenced) and axis 5 at Lv4 (learning returning to the recommended and retirement lists) become the focus. As Mercari’s account suggests, this operating phase is the long one¹¹.

When standardization backfires

None of the above argues for strong control. The research and the case studies point the other way.

What Moe et al. showed is that who decides the standard determines whether the standard works⁵. Build a technology selection committee out of the management layer and, in a Phase A organization, it turns into an ivory tower almost every time. Put field representatives in the decision-making room and move managers to an advisory role, and the same standard sticks at a different rate. Zalando’s guild⁴ and the Tech Radar workshop¹⁰ both take this shape.

Spotify is candid about the trade-offs in Golden Paths¹². Abstract too much and the internal complexity gets hidden and the educational value drops. Organizing paths by discipline doesn’t match how multi-disciplinary teams actually build products. Distributing ownership broke coordination. The internal criticism of Google’s readability points the same direction⁷. Standardization isn’t something you build once. It carries an ongoing cost of operation.

As a rule of thumb, standardization tends to backfire unless these three hold.

1. The recommended path is faster than doing it yourself (in DORA’s phrasing, a road to ship fast rather than a fence¹. Netflix gets away without a mandate because it meets this condition³)
2. Deviation is handled by recording it, not banning it
3. The field has a way to change the standard

Tighten control without those three and you strip out autonomy and trust, the attributes that contribute most to developer job satisfaction¹⁴. You set out to reduce the people who leave because nothing compounds, and you increase the people who leave because it’s stifling.

How to persuade people who don’t see the need

A diagnosis and a plan mean nothing if the proposal doesn’t pass. And the reason it doesn’t pass is usually not that the other party is foolish. They’re looking at a different shape of cost and benefit.

As the previous section showed, opposition contains legitimate parts. Control does erode autonomy, and rigid standards do get worked around. So a make-them-understand posture gets cut down by a correct objection. What you need is different material per audience, and a proposal shape that removes room for objection up front.

Three kinds of opposition, three kinds of material

Audience	The objection	What doesn’t work	What works
Executives	“What do we actually gain?”	Other companies’ cases, technical correctness	Cost translated into your own numbers
Field engineers	“You’re taking away our freedom”	Explaining why control is necessary	A demonstration of speed, plus an exemption rule
Middle managers	“We don’t have bandwidth for that”	Appeals to long-term importance	One zero-effort move available this week

If you’re handing the same document to all three, that’s where it’s failing.

For executives, turn the invisible cost into an invoice

The cost of not being aligned never arrives as an invoice to anyone. So it never reaches the agenda. Getting it there requires translating it into money and time.

Price the ramp difference. Compare the time to 10th PR from axis 4 across stacks. If teams on stack X average 34 days and stack Y averages 89, multiply those 55 days by a loaded monthly rate and by annual hires. Present it as an estimate and say so. If the order of magnitude is right, the discussion moves.

Price the attrition. Gallup estimates the cost of replacing an individual employee at one-half to two times their annual salary¹⁵. That’s a US all-occupations estimate, not a software-engineer-specific figure, so carry the caveat with the number into any internal document. If you’re losing a few mid-career engineers a year, put that figure on the page. The same research found that 52% of people who left voluntarily said their manager or organization could have done something to prevent it¹⁵. If an exit interview contains some version of “I keep solving the same problem over again,” that’s your strongest material.

As of 2026, the context that lands easiest is AI. DORA’s 2025 research describes AI as an amplifier of an organization’s existing strengths and weaknesses, and reports that when platform quality is high, the effect of AI adoption on organizational performance becomes strong and positive, while on a half-built platform the effect is negligible¹. Speed individual developers gain gets lost at downstream bottlenecks in testing, security, and deployment.

To an executive committed to a return on AI investment, “let us align the foundation underneath so the AI investment pays back” lands better than “let us do standardization.” It’s the same request with different framing.

For the field, skip the control language and show the speed

Start by not using the word “standardization.” It reads as control. Say scaffold, paved road, do-not-start-new list. Renaming isn’t a dodge. If what you’re proposing isn’t control, there’s no reason to use a name that reads as control.

Then invert the order. Persuading people to use it before building it is the long way around. Build one and show that it’s faster. Netflix gets away without mandating its paved road because development and operations on it are clearly better³. Monzo’s stated success criterion is finishing a career without touching Kubernetes, not compliance with a rulebook².

Put the exemption rule on the table yourself. Writing “teams meeting these conditions don’t have to follow this” in your own proposal drops the guard considerably. Handling deviation by record (one ADR) rather than prohibition has the same effect. What opponents fear most is a world where no exception is granted.

For middle managers, bring a proposal that doesn’t touch anything existing

“We don’t have bandwidth” is usually true. So lead with a proposal that requires no effort.

This is where the constraint of aligning only new things pays off. Nothing existing gets touched. No migration plan. “Only the things we build from here start in an aligned shape.” A half-day workshop producing the Tech Radar Hold ring, the list of “don’t start anything new with this,” is that constraint turned into an artifact¹⁰.

The political cost of that proposal is close to zero. Nothing running gets stopped, so nobody’s scope changes. It needs no budget. And fragmentation stops growing today. A proposal that’s hard to construct an objection to passes for that reason alone.

If it still doesn’t pass, shrink the scope to two teams

Giving up on company-wide agreement isn’t a loss. Transferability goes from zero to one the moment two teams are aligned. Your team, and the neighboring team you can talk to. Align the scaffold and configuration across those two and a document written on one side becomes usable on the other. That state didn’t exist with a company-wide wiki in place.

Spotify’s Golden Path started from eight engineers in a hack week¹². It didn’t begin as an approved company-wide initiative.

Six months later, bring the time-to-10th-PR comparison between those two teams and the rest, and propose again. This time you aren’t citing another company. You’re citing your own.

Getting it through is its own hurdle, and so is what comes after. Initiatives stalling the moment their champion or sponsor moves on is covered in “Sponsor Loss Risk in Change Initiatives,” and manufacturing decisions in an organization where decisions never come down is covered in “Conditions for a Leader Who Breaks the Status Quo.”

Shape the proposal as a falsifiable small experiment

Last, the form of the proposal itself. Writing these four things into it changes the odds.

1. Set an end date (three months)
2. Limit the scope to one thing (the single next new service)
3. Write the exit condition first (what would make you stop. “If going through the paved path is slower, we kill it”)
4. Decide the metric first (ramp time, days to first deploy)

Written this way, the objection shifts from “what if it fails” to “then try it.” You no longer have to win the large argument about whether standardization is right. You only have to get permission for a small experiment.

And since it’s an experiment, keep the possibility of failure genuinely open. DORA’s “build it and they will come” anti-pattern¹ comes from being certain you’re right without checking. Whether your own proposal has landed there is worth doubting once before you send it.

Wrapping up

Get the sequencing wrong and even a correct diagnosis produces nothing. Starting with a company-wide standardization project is the most common failure, and it ends at a recommended list.

The closest case study is Monzo. About 200 engineers can run over 2,000 services because the service structure is uniform enough that you can contribute to another team’s service directly. Netflix doesn’t mandate its standard; it wins on speed. Zalando puts a practitioner guild in charge of operating one. Google and Uber operate at a scale that makes their approaches hard to bring home, and Google’s readability draws criticism from inside.

The four Phase A moves: measure ramp time, spend half a day building only the Hold list, pave exactly one high-frequency path, and require a reason instead of prohibiting deviation. None of them break an existing process, and each leaves a shared yardstick for the next discussion.

A standard is not a fence. Faster than doing it yourself, deviation handled as a record, and a way for the field to change it. Standardization missing those three conditions only swaps the complaint that nothing compounds for the complaint that it’s stifling.

When the proposal doesn’t pass, change the material by audience. Translate invisible cost into money for executives and connect it to the return on AI investment. Demonstrate speed to the field and offer the exemption rule yourself. Bring middle managers only proposals that don’t touch anything existing. If none of that works, shrink the scope to one neighboring team. Transferability goes from zero to one the moment two teams are aligned.

Why the state arises, and which level your organization sits at, is covered in the companion article, “What Quietly Breaks When Every Team Picks Its Own Stack.” It lays out the five mechanisms by which knowledge transferability disappears and the six-axis, five-level severity diagnosis. Phases A, B, and C in this article correspond to that diagnosis.

Related Articles

You may also be interested in these related articles:

• What Quietly Breaks When Every Team Picks Its Own Stack - The companion article: five mechanisms and the six-axis, five-level diagnosis
• Sponsor Loss Risk in Change Initiatives - Preparing for the initiative to survive its champion
• Conditions for a Leader Who Breaks the Status Quo - Manufacturing decisions in an organization that can’t decide
• Tool Sprawl and Single Source of Truth - Consolidating by topic rather than by tool

References

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

1. Capabilities: Platform engineering - DORA / Google Cloud (2025, last updated 2026). 【Reliability: High】Capability guide grounded in DORA’s annual research. CC BY 4.0 ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸

2. 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 ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸

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

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

5. 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 ↩︎ ↩︎²

6. Software Engineering at Google - Fergus Henderson (2017). 【Reliability: Medium-High】An account of internal practice by a Google engineer. A 2017 snapshot; the set of approved languages may have changed since ↩︎

7. Readability: Google’s Temple to Engineering Excellence - Brian Kihoon Lee (2023). 【Reliability: Medium】Insider criticism from a former Google readability mentor. A personal view ↩︎ ↩︎²

8. Introducing Domain-Oriented Microservice Architecture - Adam Gluck / Uber (2020). 【Reliability: Medium-High】First-party account. The 25–50% onboarding figure and similar numbers are self-reported with no methodology disclosed ↩︎ ↩︎²

9. Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity - Shopify Engineering (2019). 【Reliability: Medium-High】First-party account ↩︎ ↩︎²

10. Build Your Own Technology Radar - Neal Ford / Thoughtworks (2013). 【Reliability: Medium】The origin of the internal tech radar practice. A method description with no empirical effect data ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷

11. Raising the productivity of the whole team: Mercari’s deeeet on the appeal of Platform Engineering - CodeZine (2024, in Japanese). 【Reliability: Medium】Interview with Taichi Nakashima. A practitioner’s view ↩︎ ↩︎²

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

13. 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 ↩︎ ↩︎²

14. 2025 Stack Overflow Developer Survey - Work - Stack Overflow (2025). 【Reliability: Medium-High】49,756 responses across 177 countries in the full survey; denominators vary by question. Self-selection bias applies ↩︎

15. This Fixable Problem Costs U.S. Businesses $1 Trillion - Shane McFeely, Ben Wigert / Gallup (2019). 【Reliability: Medium-High】A US all-occupations estimate, not software-engineer-specific. The underlying methodology is not published ↩︎ ↩︎²