What is platform engineering, and when does a company need it?

Platform engineering means building an internal platform that other engineering teams use to ship — deployment, environments, observability, and the surrounding machinery — treated as a product with users rather than as infrastructure with tickets.

The premise is that the alternatives are both bad. A central team doing the work for everybody becomes a bottleneck; every team doing it independently produces a dozen incompatible approaches and a great deal of duplicated effort. A platform is the attempt at a third option, and it works when it is genuinely optional and fails when it is imposed.

What we'll cover

• The problem it addresses
• A platform is a product
• Golden paths, not mandates
• What belongs in a platform
• When a company needs one
• How platform teams fail
• Measuring it honestly
• The portal, and whether you need one
• Automating the edges with CodeWords
• What to get right first
• Frequently asked questions

The problem it addresses

Cognitive load. The amount a product engineer must know to ship — container orchestration, networking, secrets, observability, deployment — grew faster than anybody's capacity to learn it.

Duplication. Six teams each solving deployment, logging, and configuration produces six solutions, five of which are worse than the best one and all of which need maintaining.

Inconsistency. Every service having its own conventions makes moving between them expensive and makes organisation-wide changes nearly impossible.

The central bottleneck. The traditional answer — a team that does it for you — creates a queue, and the queue is the thing everybody was trying to escape.

A platform is meant to give the consistency without the queue, by providing capability rather than performing the work.

A platform is a product

The framing that distinguishes platform engineering from infrastructure with a new name.

It has users, who are engineers, and they can choose not to use it.

It has a roadmap driven by what those users need rather than by what the platform team finds interesting.

It has documentation, and the quality of that documentation is a substantial part of whether anybody adopts it.

It has support. A platform with no route to ask a question is a platform people work around.

It should be measured on adoption and satisfaction, not on features delivered — a capability nobody uses is not a capability.

The user research is real. Platform teams that talk to the engineers they serve build different things from those that do not, and the difference is visible in the adoption numbers.

Golden paths, not mandates

The design principle that most reliably separates platforms that work from those that are resented.

A golden path is the supported, easy, well-documented way to do a common thing — deploy a service, add a database, get observability.

It is optional. Teams may leave it, and some will, for reasons that are usually legitimate.

It should be so much easier that leaving it feels costly, which is the mechanism that produces consistency without enforcement.

Mandates produce compliance and resentment. People do the minimum, route around it where they can, and stop reporting problems with it.

When a team leaves the path, find out why. That is the best product feedback available and it usually indicates a real gap rather than stubbornness.

Cover the common case well rather than every case adequately. A path covering the eighty per cent excellently is more valuable than one covering everything poorly.

What belongs in a platform

Deployment and environments. Getting code running, repeatably, in each environment.

Observability by default. Logging, metrics, and tracing configured without each team wiring them independently.

Secrets and configuration, so nobody is inventing their own storage.

Templates for new services, which is where consistency is cheapest to establish.

Self-service infrastructure — a database, a queue, a bucket — provisioned without a ticket and within sensible constraints.

Not the business logic, obviously, and not the things that genuinely differ per team. A platform that tries to standardise what should vary becomes the constraint it was meant to remove.

When a company needs one

The honest answer, which is later than platform engineering discourse implies.

Not with one or two teams. The duplication is small and the platform team would be a substantial fraction of engineering.

Probably not with three or four, where a shared repository of conventions and a couple of scripts does most of the work.

Somewhere past that, when the same problem is being solved repeatedly and the cost of divergence is visible.

The signal is duplication you can point at, not a headcount. If three teams have three deployment approaches and the inconsistency is costing time, that is the argument.

Start with one person or a small group, part-time, on the single most duplicated thing — rather than forming a platform team and asking it what to build.

A platform team without a platform is a bottleneck with a better name.

How platform teams fail

Building what they find interesting, rather than what their users need.

Becoming the bottleneck they replaced, by making the platform the only route and then being unable to keep up.

Abstracting too early, producing a layer over a cloud provider's abstraction that is two things to learn instead of one.

No documentation, which means the platform's capability is inaccessible without asking somebody.

No support, so problems become workarounds.

Measuring the wrong thing. Counting features shipped rather than adoption, satisfaction, or the time it takes a team to get a new service into production.

Measuring it honestly

Time from nothing to a service in production, which is the headline number and the one that justifies the investment.

Adoption of each golden path, since a path nobody uses is a signal.

Developer satisfaction, asked directly. A short survey, regularly, which is uncomfortable and more informative than any dashboard.

Time spent on platform-related toil by product teams, before and after.

How often teams leave the path, and why, treated as product feedback rather than as non-compliance.

Not lines of platform code, not services migrated under duress, and not tickets closed — all of which can improve while the platform gets worse.

The portal, and whether you need one

Internal developer portals get equated with platform engineering, and they are one possible interface rather than the thing itself.

A portal is a front door: a catalogue of services, their owners, their documentation, and the actions a team can take.

The catalogue is the valuable part. Knowing what services exist, who owns each, and what depends on what answers questions that otherwise require asking around.

The actions matter less than they look. Most teams are comfortable with a command line, and a button that wraps a command is convenience rather than capability.

A portal over an incomplete platform is a menu of things that do not work, which damages credibility faster than having no portal.

Ownership data rots fastest. A catalogue whose owner column is a year out of date is worse than none, because people act on it.

Build the capabilities first and add a portal when people are asking where things are — which is a real signal and one you will notice.

Automating the edges with CodeWords

Not everything around an engineering organisation belongs in the platform. The connective work — reporting across projects, notifying the right people, joining engineering systems to business ones — is integration rather than infrastructure. CodeWords connects to more than 3,000 integrations.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder.
3. Describe the exceptions explicitly.
4. Connect the systems involved once and reuse the connections.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What to get right first

One golden path, for the most duplicated thing, made genuinely easier than the alternative — and optional. A single path people choose voluntarily establishes both the pattern and the credibility; a platform of mandated capabilities establishes neither.

Two habits make the difference. Ask the engineers you serve what costs them time, and build that, since platform teams that guess build different things from those that ask. And when a team leaves the path, treat it as product feedback rather than as a compliance problem, because it is almost always pointing at a real gap.

Frequently asked questions

What is the difference from a DevOps or infrastructure team?

The product framing. A platform team has users who can choose not to use it, a roadmap driven by their needs, documentation, and support. An infrastructure team with a ticket queue is the bottleneck a platform is meant to remove.

Should using the platform be mandatory?

No. Golden paths should be optional and so much easier that leaving them feels costly. Mandates produce compliance, resentment, and people who stop reporting problems — which removes your best source of feedback.

When does a company need a platform team?

Later than the discourse suggests. The signal is duplication you can point at — the same problem solved repeatedly at visible cost — rather than a headcount. Below that, a shared repository of conventions does most of the work.

How should a platform team start?

With one person, part-time, on the single most duplicated thing. Forming a team first and then deciding what to build produces a platform shaped by what the team finds interesting rather than by what anybody needs.

What should a platform not include?

The things that genuinely differ between teams. A platform that standardises what should vary becomes the constraint it existed to remove, and teams route around it — which is worse than not having offered it.

How do I measure whether it is working?

Time from nothing to a service in production, adoption of each golden path, and developer satisfaction asked directly. Not features shipped or tickets closed, both of which can improve while the platform gets worse.

What is the most common failure?

Building what the platform team finds interesting instead of what their users need. The remedy is unglamorous and reliable: ask the engineers what costs them time, and build that.

Do we need an internal developer portal?

Not to begin with. The catalogue — what services exist, who owns them, what depends on what — is the valuable part; the buttons are convenience. A portal over an incomplete platform is a menu of things that do not work.

What part of a portal rots fastest?

Ownership. A catalogue whose owner column is a year out of date is worse than no catalogue, because people act on it and contact somebody who left. Tie ownership updates to the leaving process.

How large should a platform team be?

Small enough that it cannot do the work for everybody, which is the constraint that keeps it building capability rather than becoming a service desk. Growth should follow adoption rather than ambition.

What if teams ignore the platform?

Find out why, service by service. It is the most useful feedback available and it nearly always points at a genuine gap — a case the golden path does not cover, or an abstraction that costs more than it saves.

Related reading

• Infrastructure as code
• CI/CD pipelines explained
• Service mesh