There is a particular fate that befalls a successful platform team. It launches something good, people adopt it, the standards start to matter, and then, slowly, the team stops being engineers who built a product and becomes clergy who guard a faith.

You can usually spot the moment it happens. The platform stops being a thing developers use and becomes a thing developers must obey. Standards harden into commandments. The architecture review turns into confession. The wiki becomes scripture, and going around the platform stops being feedback and starts being heresy.

I want to argue against the priesthood, because it is the most common way a good platform team goes bad. And the alternative is not chaos. The alternative is product management.

How a good platform team turns into a priesthood

The drift is rarely deliberate. It comes from a real place: the team does know more than its users about Kubernetes, networking, and the seventeen ways to misconfigure a bucket. That expertise is genuine. The mistake is what the team does with it.

A priesthood converts expertise into authority, and authority into mandate. The platform becomes the official way, then the only sanctioned way, then a thing you are not allowed to question. The standards stop being defended on their merits and start being defended because they are the standards. Teams that route around the platform are treated not as customers sending a signal but as sinners to be brought back into the fold.

The tell is the language. A product team says "developers aren't adopting this, what's wrong with our product?" A priesthood says "developers aren't complying, what's wrong with developers?" One of those questions leads somewhere useful. The other one leads to a governance memo.

Compliance is the cheap imitation of adoption

The priesthood measures the wrong thing, and the wrong thing is compliance.

Compliance looks like success. The mandate went out, the dashboard says 90% of services are "on the platform", the box is ticked. But mandated adoption is not the same as chosen adoption, and the gap between them is where all the value leaks out. A developer forced onto a platform they resent does the minimum, works around it where they can, and abandons it the instant a credible alternative appears. You have a captive congregation, not a happy customer base, and captives are always looking for the exit.

Chosen adoption is different. It is what you get when the platform is genuinely the easiest correct way to do the thing, so people use it because using it is in their interest, not because a committee said they must. That kind of adoption survives the moment your mandate weakens. The priest's kind does not.

DORA makes this concrete. Its platform engineering research found that treating development teams as the users of a product works better than the "build it and they will come" approach, and that platforms often follow a J-curve: an early dip in performance as complexity rises, before things recover. The priest, hitting that dip, panics and mandates harder, which deepens the dip. The product manager reads the dip as a product problem and fixes the product. Same data, opposite instinct.

The job was always product management

If the priesthood is the failure mode, product management is the discipline that prevents it. Not the job title. The actual work, applied to an internal platform with developers as the customers.

Discovery. A product manager starts by finding out what users actually need, not by assuming. Most internal platforms are built from the platform team's taste, then defended when developers fail to share it. Discovery means going and watching how people really work, where they get stuck, and what they reach for instead of you. The platform exists to solve their problem, not to express your architecture.

Segmentation. A priesthood has one congregation and one doctrine for all of it. A product knows its users are not identical. A senior infrastructure team and a hard-pressed feature squad want different things from the same platform; the golden path that delights one will infuriate the other. You segment, and you serve the segments, instead of issuing one commandment and blaming the people it does not fit.

Adoption, not mandate. This is the heart of it. The strongest platforms win the way Netflix described its paved road: optional, but so well supported that leaving it looks like a bad idea. You earn that by making the supported path the path of least resistance, then letting people choose it. Adoption you have to earn is durable. Adoption you mandate evaporates the moment nobody is enforcing it.

Trust. Your platform competes, always, with "I'll just do it myself". You win that competition on reliability and support, not on a memo from an architect. Every outage you handle quietly, every breaking change you migrate for people instead of dumping on them, every time the docs are actually right, buys trust. Every broken promise spends it. A priesthood assumes trust as its due. A product knows it is earned per release.

Support. A product has a way to get help: a channel, an SLA, a human who cares that you are blocked. A doctrine has a wiki and a shrug. The unglamorous work of supporting your users, answering the question, unblocking the build, owning the incident, is most of what separates a platform people rely on from one they merely tolerate.

Lifecycle ownership. Products get versioned, deprecated, and migrated with care. Priesthoods never sunset anything, so old commandments stay on the books forever, contradicting the new ones, until the standard is a pile of sediment nobody fully understands. Owning the lifecycle means having the discipline to kill your own darlings and carry users through the change, rather than leaving a decade of mandates fossilising in the wiki.

The machine will not attend your church

There is one more reason the priesthood model is finished, and it is the one running through everything on this blog.

The platform's users are no longer only people. They are increasingly the agents those people delegate to, and an agent cannot be mandated. It does not read your governance memo, feel your disapproval, or attend the architecture review. It routes through whatever interface gets the job done, and if the supported path is not the easiest correct one, it will quietly find another. This is when the consumer is a machine: authority by decree reaches a human, however grudgingly, and reaches a machine not at all.

So the product instinct stops being merely healthier and becomes the only thing that works. You win an agent's adoption exactly the way you win a developer's, by being the easiest correct path, with good contracts and reliable behaviour. A platform that depended on mandate to drive adoption has nothing to say to a consumer that cannot be commanded. This is also why I keep insisting the real work of AI engineering is boring: the boring product discipline is what an agent responds to, and the priestly authority is noise it cannot hear.

The reframe

A platform team holds real expertise, and expertise is worth having. The error is believing expertise entitles you to obedience. It does not. It entitles you to build something good enough that people choose it.

I have argued that platform value is usually measured in the wrong place. This is the organisational version of the same mistake. Measure your platform by compliance and you will optimise for a number that means nothing, defended by a priesthood nobody likes. Measure it by chosen adoption, by whether developers and the agents they send would still use it if you stopped making them, and you are forced to build something genuinely worth using.

The standards still matter. The expertise still matters. They just stop being a religion and start being a product. Fire the priest. Hire the product manager. Then go and ask your users what they actually want, which is the one question a priesthood is constitutionally unable to ask.