Engineering Flow – Part 3
A series exploring how high-performing engineering organizations improve the flow of software delivery through DevOps, Platform Engineering, DORA Metrics, and systems thinking.
We make software delivery harder than it needs to be. Not intentionally. Most of the friction starts with perfectly reasonable decisions.
We need infrastructure expertise, so we create an infrastructure team. We need stronger security, so we establish security reviews. Databases need to be reliable, so database engineers manage them. Production needs to be stable, so we create change controls.
Every decision makes sense on its own.
Eventually, an engineer needs infrastructure, networking, a database, security approval, and a production deployment just to deliver one change.
Nobody designed the system to be slow. It just grew that way.
And that, more than any particular technology, is why platform engineering exists.
We Built Dependencies Into the Organization
In Part 2 of this series, I wrote about how every dependency creates a tax on delivery.
I’ve spent much of my career in large enterprise environments, and I’ve seen this firsthand.
The problem usually isn’t that infrastructure, database, security, or operations teams aren’t moving fast enough. Quite often, they’re filled with talented people doing exactly what the organization asked them to do.
The problem is the system we’ve created around them.
When dozens of engineering teams depend on the same specialized teams for routine work, those teams inevitably become queues.
Our natural response is to make the queues faster. We create better ticketing systems, establish SLAs, prioritize requests, or add people.
Those things can help. But we’re still managing the queue.
Eventually, we need to ask a different question:
Why does this need to be a queue at all?
Turn Expertise Into Capability
Databases are an easy example for me.
Traditionally, if an application needed a database, someone submitted a request to the database team. A DBA reviewed the requirements, provisioned the database, configured security, established backups and monitoring, applied organizational standards, and handed it over.
There are good reasons for that process. You want someone who understands databases making those decisions.
But there’s a difference between needing database expertise and needing a database engineer to manually perform the same process every time.
What if database engineers defined those standards once, then encoded their expertise into something software engineering teams could consume on demand through a self-service platform?
The database engineers haven’t become less important. Their expertise has become more valuable because it can scale beyond the requests they can personally complete.
Platform engineering doesn’t eliminate specialized expertise. It productizes it.
Platform Engineering Is Core to DevOps
Platform engineering became a buzzword several years ago. But like many technology trends, some organizations simply slapped the label on teams that continued to build and manage infrastructure the same way they always had.
What often gets missed is that modern platform engineering grew out of many of the same principles as DevOps, with a stronger focus on internal developer platforms, self-service, golden paths, and developer experience.
The platform team wasn’t designed to become another team software engineers depend on. It was designed to make those dependencies less visible—or eliminate them altogether.
For a while, everyone was talking about platform teams, developer portals, Kubernetes, Terraform, and paved roads.
Then some of the excitement moved on to the next thing.
The underlying problem didn’t.
Many organizations adopted DevOps tooling without fundamentally changing how work flows through the organization.
We automated builds and deployments. We built CI/CD pipelines. But developers still opened tickets for infrastructure and waited for environments, security reviews, databases, and other teams before they could deliver software.
The tooling changed. The delivery system didn’t.
DevOps was never simply about CI/CD, automation, or putting developers and operations engineers on the same team. It’s about improving the system through which software moves from idea to production.
Platform engineering is one of the key ways we make that work at scale.
It isn’t a replacement for DevOps. It’s a core part of putting DevOps into practice at scale.
The Goal Isn’t the Platform
It’s easy to turn platform engineering into a technology initiative.
Build the developer portal. Deploy Kubernetes. Standardize Terraform. Create reusable pipelines.
Those things can all be useful, but none of them proves that we’ve improved software delivery.
The better question is:
Did we make it easier for an engineering team to deliver software?
If developers still need to understand the organizational chart to get something into production, we haven’t solved much.
We’ve spent years learning how to abstract technical complexity. Platform engineering gives us an opportunity to abstract something just as damaging to flow: organizational complexity.
That might mean provisioning an approved database without knowing who the DBA is, creating an environment without an infrastructure ticket, or deploying safely without manually coordinating with operations.
The platform is the mechanism.
Flow is the outcome.
Guardrails Instead of Gates
None of this means removing governance. Security, reliability, compliance, architecture, and operational controls still matter.
But controls don’t always have to take the form of another person giving permission.
A gate stops you until someone lets you through.
A guardrail allows you to keep moving while staying within acceptable boundaries.
If encryption is required, make it the default. If only certain infrastructure configurations are approved, make those the configurations teams can provision. If deployments must meet specific requirements, enforce them automatically.
The control doesn’t disappear. The waiting does.
Don’t Build Another Queue
There’s an irony in platform engineering.
It’s entirely possible to create a platform team and recreate the exact problem it was supposed to solve.
Instead of opening an infrastructure ticket, you open a platform ticket. Instead of waiting for operations, you wait for the platform team.
We’ve changed the name of the dependency without removing it.
A platform team shouldn’t primarily exist to perform work for engineering teams. It should create capabilities that allow those teams to do more themselves—safely, consistently, and independently.
That’s why treating the platform as a product matters. The engineers using it are customers.
If every interaction with your platform requires a ticket, you may have built another dependency, not a platform.
Why Platform Engineering Exists
Small engineering organizations can survive on relationships.
Everyone knows who manages the infrastructure. Someone knows the security engineer. A developer can message the DBA.
That doesn’t scale to hundreds or thousands of engineers.
Eventually, organizational boundaries become delivery boundaries.
Platform engineering gives us a way to expose the expertise of specialized teams without requiring every engineer to navigate those boundaries.
Instead of figuring out how to coordinate more efficiently, we can start asking how much coordination we can eliminate altogether.
That’s why I don’t think platform engineering was just another DevOps buzzword.
If anything, I think many organizations moved on from the buzzword before they fully implemented the idea behind it.
And that idea is still incredibly relevant.
DevOps asks us to improve the system of software delivery.
Platform engineering gives us a powerful way to do that at scale—when done right.
The goal isn’t to build a platform. The goal is to help teams flow autonomously.
Engineering Flow Series
- Your Team Isn’t Slow. Your Delivery System Is.
The foundation of Engineering Flow: why software delivery is constrained more by systems than by individual effort. - Every Dependency Is a Tax on Delivery
why team dependencies reduce autonomy and slow delivery - Why Platform Engineering Exists (Current Article)
How platforms enable autonomy without sacrificing governance. - CI/CD Isn’t About Automation. It’s About Reducing Risk.
Why smaller deployments are actually safer deployments. - Every Handoff Is a Queue
The hidden cost of waiting, approvals, and organizational bottlenecks. - Stop Measuring Output. Start Measuring Flow.
Why engineering effectiveness starts with measuring systems, not activity. - DORA Metrics Aren’t KPIs
How to use DORA Metrics to improve systems, not evaluate people. - CI/CD Is Easy. Culture Is Hard.
Why trust, ownership, and feedback matter more than tooling. - Why Engineering Leaders Should Care About DORA Metrics
Using engineering metrics to improve organizational performance. - Why Most Data Engineering Teams Aren’t Practicing DevOps
Applying modern software delivery principles to data platforms.
If you enjoyed this article, consider subscribing for future posts in the Engineering Flow series.
Brendan McCaffrey 