Here is a diagnosis we keep meeting in engineering organisations of every size, and the discipline built to end it is PlatformOps. A company has six teams. Someone needs a deployment dashboard, so a team in one building builds one. Six months later, a second team ships their own version with slightly different charts. A year on, there are four, none of them quite complete, all of them half-maintained, and nobody — including the people who built them — can tell you which is current. Multiply that pattern across pipelines, alerting, scaffolding, environments, and you have an organisation paying four times for one capability and receiving it badly every time.
The industry even has a name for the underlying disease, borrowed from researchers studying how Spotify’s engineering culture worked: rumour-driven development. Teams rebuild similar things because nobody knows what already exists. Knowledge travels as gossip, so does duplication. The cure is not another memo. It is treating shared engineering capability as a product that one accountable group runs — and this post walks through the diagnosis and the treatment the way we walk client teams through it.
Symptoms: how rumour-driven development shows up
Before prescribing anything, check the signs against your own floor:
- The same question, answered four ways. Ask three engineers how to get a new service deployed and you receive three different runbooks, each privately maintained.
- Discovery by corridor. People learn a tool exists by overhearing a standup, not by searching. The organisation’s real catalogue lives in chat scrollback.
- Ghost ownership. Shared components whose builders moved on two restructurings ago. Everyone uses them; nobody feels entitled to fix them.
- The build-versus-rebuild shrug. When a team needs something, they quietly budget two weeks to write it rather than a day to find it — because finding it has never once worked.
None of these are talent problems. They are visibility and accountability problems, which is why the standard responses — wiki pushes, tooling mandates, an all-hands about reuse — reliably fail.
Why the quick fixes disappoint
The reflexive remedy is consolidation: pick a standard, announce it, expect alignment. But a standard without an operator is just a suggestion with letterhead. The second reflex is a mandate, which converts enthusiasm into compliance and teaches teams to look obedient rather than to look for the shared tool. The third is hiring more engineers for every team, which multiplies the duplication at higher salaries.
The deeper mistake in all three is treating the symptom — scattered tools — while leaving the disease intact: no one owns shared capability as their actual product. Once you see that, the solution writes itself, and the industry has been converging on it for a decade.
Worth naming, too, is the cost accounting that keeps the disease invisible. Duplicated tools are paid for in small denominations: two weeks here, a sprint there, a maintenance afternoon once a month. Each line item slides under every approval threshold a manager watches. Consolidated, the same spend would demand a business case — which is precisely why the rebuild habit survives every cost review. When we total the duplication for clients, the number usually exceeds what a dedicated platform group would cost, and the conversation changes from “can we afford one?” to “how long have we been paying for one without getting it?”
The PlatformOps solution: build the thing once, run it like a product
The treatment has three ingredients, and the interesting part is how old each one is.
Ingredient one: golden paths
The idea got its name at Spotify around 2014, though Netflix had been running the same concept for years under a friendlier label — the paved road. A golden path is the supported route through a common engineering journey: scaffold here, pipeline there, deploy this way, dashboards appear automatically. Two properties make it work where mandates failed. It is opinionated — decisions are pre-made by people who made them carefully. And it is optional with consequences: teams may step off the path when they genuinely need to, yet in doing so they inherit the support consequences themselves. Freedom preserved; freeloading ended. Most teams, offered a route that is faster and supported, take it without a single policy email.
Ingredient two: a product owner with a real mandate
Golden paths do not maintain themselves. The fix for ghost ownership is a platform group whose roadmap, support hours and upgrades are somebody’s day job — the operating half of the practice we call PlatformOps. This group publishes what exists (killing discovery-by-corridor), states service levels (killing support-by-luck), and retires duplicates deliberately (killing the four-dashboards problem at its root). When a capability has a name and a face, the rumour network loses its monopoly on truth.
Ingredient three: start embarrassingly thin
The most common way this cure kills its patient is overdosing: a two-year programme, a grand portal, a big-bang migration. The practitioners who study team design — Team Topologies most influentially — prescribe the opposite and call it the thinnest viable platform. Build the smallest bundle of capability that removes the most repeated pain, ship it to one friendly team, and expand only when pull appears. Thinness is not a lack of ambition; it is how the platform earns the trust that ambition later spends. We see the same sequencing in hands-on training contexts too — you learn Kubernetes by deploying one service well, not by architecting a fleet, a principle we apply in our hands-on Kubernetes learning approach.
A PlatformOps diagnosis worksheet for this fortnight
- Count the duplicates. Pick one capability category (dashboards, pipelines, scaffolding). List every instance you can find. The number usually ends the debate about whether a platform is needed.
- Trace one rebuild to its cause. Find the most recent duplicate and ask the builders why they did not reuse. The answer is almost always “we did not know it existed” or “we could not get it” — map which.
- Name a candidate owner. One engineer, part-time to start, accountable for the thinnest viable version of the most-duplicated capability.
- Give it ninety days and one design team. Measure adoption by usage, not by announcement applause.
Automation habit is the raw material for all four steps — teams that already script their repetitive work are halfway to golden paths. Our guide on improving internal workflows with smart automation covers that groundwork, and the wider engineering context it sits in is exactly what we teach through our work on AI, cloud, DevOps and platform engineering.
A note on who should run the worksheet: not the person with the most enthusiasm, and not whoever built the tool being duplicated — both carry biases the exercise is designed to remove. The best facilitator is someone trusted by every team involved and answerable to none of them. In consulting engagements that is us; inside a company it is usually a staff engineer or an architect who has quietly helped everybody at least once.
The follow-up visit
Six months into a proper treatment, the diagnostic signs invert. New engineers find the supported route by search, not gossip. Duplicate counts fall instead of rise. The platform group has a backlog argued over in public. And the deepest change is cultural: “somebody should build that” becomes “somebody should own that” — because the organisation has learned that building was never the scarce part. For the full map of this practice, from reference architecture to lifecycle policy, the PlatformOps reference in the Ops Atlas is the most complete single source we recommend to clients.
One honest caveat before you prescribe it to yourself: the treatment has a course length. A fortnight buys you the worksheet and the duplicate count; the first thin golden path realistically lands inside a quarter; the culture shift takes two or three quarters of visible ownership. Teams that stop at the announcement get none of it. Treat PlatformOps like physiotherapy — progress comes from the sessions actually done, not from the referral letter.
Rumour-driven development feels harmless because each individual duplicate looks small. Stack enough of them and you have paid for a platform team anyway — except distributed, unmanaged, and with none of the benefits. The choice is not whether to fund shared capability. It is whether to fund it once, deliberately, or forever, accidentally.
