Platform engineering automates the string, not the nodes
Enterprises have world-class automation inside every individual tool (Terraform pipelines, GitOps deployments) and almost none in the manual work that connects them. That gap is what platform engineering exists to close.
Every large enterprise can point to excellent automation. A Cloud team with
a CI/CD pipeline that runs Terraform against Azure and hasn't needed a manual apply
in years. An OpenShift team with a GitOps setup so clean that a new image version
rolls out to dev the moment the PR is merged. These are not small
accomplishments. They were built by people who know their tool
better than almost anyone else in the building.
And yet the developer who wants to use both of those things may still spend most of a day trying to work with them.
The string-and-nodes picture
Take a business process, say "get a new Java service running in dev", and treat it as a string with a few nodes tied onto it. Each node is a place where automation lives: the Terraform pipeline that provisions the Azure resources, the GitOps pipeline that deploys to OpenShift or the CI pipeline to build a new image. Zoom into any of those nodes and you'll find a specialist team that has spent months, sometimes years, making that one thing fast, safe, and repeatable.
The string between the nodes is a different story. Getting from "I have an idea for a service" to "the Terraform pipeline has something to run against" is not automated at all. It's a person creating a repository, wiring up the CI/CD triggers by hand, writing the first Terraform module from a copy-pasted example, requesting the Azure subscription the module needs to target. Getting from "the resources exist" to "the GitOps pipeline picks this up" is the same story again: someone manually adding an application entry, manually setting the right namespace, manually requesting access so it's even visible to the team that owns it.
The automation happens at the instant the pipeline is triggered. Getting to the point of triggering it is where the developers still lose a lot of time.
Why the nodes get all the investment
This comes down to incentives, not negligence. The Cloud team is measured on the Cloud team's automation; the OpenShift team is measured on the OpenShift team's automation. Nobody owns the string, because the string crosses team boundaries, and crossing team boundaries is the kind of work that never shows up on anyone's roadmap unless someone is explicitly told to own it.
The result is an organization with three or four islands of elite automation, and a sea of manual process between them that every developer has to swim across, alone, every time they need something new. Measured in isolation, every team's tooling looks great. Measured end to end, from "I need a new service" to "it's running and deployed", the organization looks like it has almost no automation at all, because the string, not the nodes, is most of the distance.
What platform engineering is for
Platform engineering often gets reduced to "we run Kubernetes" or "we write Terraform modules". Both are already covered by the nodes above, and both are already someone's job. The thing nobody else's job description covers is the string: the repo creation, the pipeline wiring, the environment request, the access grant, the handoff from one team's automation to the next team's automation.
A platform capability doesn't replace the Cloud team's Terraform pipeline or the OpenShift team's GitOps setup. It sits in front of both and turns "create a repo, wire up CI, request Azure resources, wait, wire up GitOps, request access, wait" into one self-service request that triggers both pipelines in the right order with the right inputs, automatically. The nodes stay as they are. The string, however, disappears along with its manual steps.
It's kinda like building a railway system to go from A to B really fast, but there is a river in between. And we didn't build a bridge to cross the river. So everyone needs to step out, cross the river on foot, then board the train again on the other side of the river. Platform engineering is about thinking critically about how we consume these automated nodes (or railways) and coming to the conclusion that maybe, just maybe, we should build a bridge to speed up the process.
The definition I use: platform engineering is the discipline of automating the gaps between an organization's already-automated processes. Instead of adding another node, it finally builds the bridges across the gaps that were left untouched.
Why this explains platforms that "have automation" and still feel slow
It also explains a pattern a lot of platform teams run into: every individual pipeline in the org is fast, every team's automation metrics look good, and developers still say the platform feels slow. They're not being unfair. They're describing the string, which nobody measures, because we focus so much on the trees that we fail to see the forest for what it truly is. A platform's throughput is the sum of the automated nodes and the manual string between them, and the string is usually the bottleneck that remains.
The platform capability lifecycle is the same idea from the individual engineer's point of view, from request through decommission. This is the organizational version of it: the string is where every one of those stages either exists as a capability, or doesn't exist at all and gets rebuilt by hand, differently, every time someone needs it.