Why Developers Route Around Your Platform

There is a version of this move that is a job title change and nothing else. You were the person who knew Terraform; now you are the person who knows Terraform on a team called Platform. Nothing about the work is different.

The real version changes one thing, and everything else follows from it.

In DevOps, your work gets used because it is in the way. You own the pipeline. To ship, a developer goes through it. They may complain, but they use it, because there is no alternative.

In platform engineering, your work gets used only if it is better than the alternative — and the alternative is always available. A developer can write their own Terraform. They can build their own pipeline. They can kubectl apply straight at the cluster. The moment your platform is more annoying than doing it themselves, they do it themselves, and you find out months later when something they built breaks and it turns out to be yours to fix.

That is the shift. You have users now, and they can refuse you.

What transfers

Most of it, and this is not false comfort. The technical foundation of a platform is the work you have been doing.

• Infrastructure as code — unchanged, and now it is the product rather than the plumbing
• CI/CD — unchanged, except you are building the pipeline other people's pipelines are made of
• Kubernetes — unchanged, and increasingly something you are hiding rather than exposing. Hiding it well means the abstraction has to hold: a developer should not need to know why Kubernetes uses desired state to deploy, but somebody on your team does
• Observability — unchanged, plus you now need it for the platform itself, and alerting on symptoms rather than causes matters more when the symptom is somebody else's deploy failing
• Secrets and identity — unchanged, and now centralised, which is mostly an improvement
• Debugging other people's systems — the single most transferable skill, because that is the whole job now

If you can build a deployment pipeline that works, you have the engineering half. What is missing is not technical.

What is genuinely different

1. Adoption is the success metric, not uptime

Your platform can have four nines and be a failure. If half the teams are not using it, it has not reduced anything — it has added a system that must be maintained alongside all the ones it was supposed to replace.

This is uncomfortable coming from operations, where the numbers are about whether the thing works. Here the number that matters is whether anyone chose it.

The honest measure is voluntary adoption: what fraction of teams use the paved path when they could avoid it. If the answer is high because nobody is allowed to avoid it, you have not learned anything, and you may well have a shadow platform you cannot see.

2. You are building for people who can say no

Every design decision becomes a negotiation with somebody's convenience.

A golden path that covers the common case in three minutes will be used. One that covers every case but requires reading a wiki first will not, however much better it is in the abstract. Developers are not evaluating your architecture — they are comparing time-to-first-deploy against the thing they already know how to do.

This does not mean giving people whatever they ask for. It means the thing you build has to be easier than the alternative at the moment of use, and that is a different design constraint from the ones you are used to.

3. The escape hatch is a design decision, not a failure

Platform teams split into two camps here and one of them is wrong.

The walled garden says: the platform is the only way, and if it does not support your case, we will add it. This is appealing and it collapses under the weight of exceptions. Somebody always has a genuinely unusual requirement, and blocking them makes you the obstacle rather than the path.

The alternative: the golden path covers the common cases very well, and there is a documented way off it for the cases it does not. The escape hatch is not an admission of defeat — it is what stops people building an undocumented one behind your back.

The rule worth holding: make the paved path easier, never make the alternative harder. Blocking kubectl access does not increase platform adoption. It increases resentment and creates a second, hidden path you now cannot observe.

4. Your users are colleagues, which is harder

Ordinary product teams have users who are strangers. You have users who sit near you, know how the thing is built, and have opinions about your implementation choices.

Two practical consequences. First, feedback arrives constantly and informally, which is valuable and unrepresentative — the loudest team is not the median team. Second, the team that spent eight months building their own deployment tooling is not neutral about replacing it with yours. That resistance is rational and it is not really about your platform.

5. Documentation stops being optional

In DevOps, undocumented knowledge is a personal inefficiency: you are the one who has to remember. In platform engineering it is a product defect. An undocumented feature is a feature nobody uses, and it costs the same to maintain as one people use.

A worked example

A team is standing up a new service. Here is the same task under each model.

Without a platform:

copy Terraform from the last service        ~2 hours, plus whatever was wrong in the original
copy the CI workflow                        ~1 hour
work out what secrets it needs              ~1 hour, mostly asking people
get it deployed to staging                  ~half a day, mostly debugging IAM

Every team does this. Every copy carries the previous copy's mistakes forward, and no two services end up configured the same way — which is how you end up with state drift in six places and a pipeline that passes locally and fails in CI for a different reason in each one.

With a golden path that works:

scaffold the service                        a command, a few minutes
push                                        pipeline, environments, secrets and observability already wired
first deploy                                same afternoon

With a golden path that does not work:

scaffold the service                        a command
discover it does not support the database they need
ask the platform team                       two days for an answer
give up and copy Terraform from the last service

The third outcome is the common failure mode, and notice what it costs: the team lost two days and ended up where they started, so next time they skip straight to copying. One bad experience buys a permanent opt-out.

The traps

Building for 100% of cases before shipping any. The instinct is to handle everything before releasing, because a platform that does not support a team is embarrassing. The result is a multi-year project that demonstrates nothing, loses its sponsor, and gets cancelled. Ship the path for the most common service shape, get it used, extend from evidence.

Mandating adoption instead of earning it. It works on paper and produces malicious compliance: teams use the minimum surface required and route everything else around you.

Treating the platform as infrastructure rather than a product. No roadmap, no owner, no user research, no changelog. Features appear and disappear. Teams cannot plan against it and stop relying on it.

Confusing a wrapper with a platform. A shell script around terraform apply is not an abstraction. If a developer still has to understand Terraform to use it, you have added a layer without removing a concept, and now they must understand both. A real abstraction makes a decision on their behalf and stands behind it — sensible resource requests and limits, for instance, which most teams otherwise set once by guessing and never revisit.

Never measuring. If you do not know what fraction of deploys go through the paved path, you do not know whether you have a platform or a side project.

When an organisation should not build one

This is the section most platform engineering writing omits, and it matters.

When there are not enough teams. A platform's value is amortised across the teams that use it. Three teams do not generate enough repetition to pay for a product, and the platform engineer's time is better spent on the three teams directly.

When the teams are too different. A platform serves a common shape. If every service is genuinely unusual, there is no common shape to pave, and the golden path will fit nobody.

When the underlying practice is not settled. Paving a path across ground that is still moving produces an abstraction over something nobody agrees on yet. Get to a working pattern manually first, then automate the pattern that emerged.

When it is really a reorganisation. Renaming the operations team to Platform, changing nothing else, and expecting different outcomes is common and does not work. The change is that you now have users with a choice; if that is not true, nothing has changed.

A realistic path

You do not need permission or a reorganisation to start.

Find the thing every team does badly. Not the most interesting problem — the most repeated one. Usually it is a new service reaching staging, or getting a secret to a workload, or a database that needs provisioning.

Automate it for one team, with them. Not a platform. One paved path for one real use, built alongside somebody who will use it tomorrow.

Get a second team onto it. This is where you learn what was actually specific to the first team, and it is the step most first attempts skip.

Write down how to use it, and how to get off it. Both. The second is what makes people willing to try the first.

Then measure. How many teams use it. How long the common task takes now. What fraction of deploys go around it. If that last number is high, you have a finding, not a failure.

The honest summary

The technical skills transfer almost entirely. What is new is that you are building something people choose, which means design decisions get made against convenience rather than correctness, and a technically excellent platform nobody adopts is a failure by the only measure that counts.

If you like the infrastructure work and dislike the idea of persuading colleagues to use what you built, this move will be frustrating — and that is worth knowing before you make it rather than after. It is not a promotion track that everyone should take. It is a different job that happens to use the same tools.