The world we live in
If your platform can spin up environments but can’t tell you what work to prioritize, is it really done?
I’ve seen countless organizations go all-in on platform engineering — rolling out shiny tools, automating workflows, and deploying environments in seconds. But too often, the processes surrounding that automation get left behind.
That’s why I’m a firm believer in a “two lane approach” when transforming organizations towards a more productive IT environment. Far too often, I have seen only technical implementation without considering the processes surrounding automation. On the other hand, only implementing something like the “spotify-model” for organizing teams doesn’t solve anything if it is not backed up by a supporting technology stack. So, from that perspective, Platform Engineering (for me) is both a technical thing (as supported by platformengineering.org) and an organisational thing (as described in Team Topologies).
However, what I notice in the technical implementation of a platform is that there’s little room for the supporting business processes. Where is the Process of development and management being managed? Where do we fit tools like Jira, ServiceNow, …? What about our CMDB?
The missing layer
Today’s platform architectures are great at provisioning environments and deploying services — but where does the actual work get managed?
Tools like Jira, ServiceNow, and even Slack are essential to how teams collaborate, yet they sit outside the reference architecture. They’re not part of any “plane.” There’s no defined space for planning, prioritizing, or governing the flow of work itself.
Figure 1: A typical Internal Developer Platform layout — structured for infrastructure, but with no space for process or governance.
We talk about Developer Control Planes and Resource Planes — but who’s managing the processes that run across them? Where do “golden paths” live? Where does documentation go? Who owns the roadmap?
A real life use case
I was in a workshop with a client, mapping how work flowed through their IT organization. At one point, I asked what seemed like a simple question:
“How does work get assigned to IT engineers?”
What followed was 30 minutes of controlled chaos.
- Requests came in through email, and sometimes via Slack or Microsoft Teams.
- Bugs were reported through Zendesk, or directly to engineers via WhatsApp.
- The development team used Jira internally — but it wasn’t customer-facing. That was handled elsewhere.
- When teams had to collaborate, they copied Jira tickets into Excel, and the project manager was responsible for updating statuses across tools.
Their CMDB? A patchwork of CSV files, Word documents, ServiceNow records… And documentation? Oh, there was plenty — but it was scattered across Dropbox, Git repos, OneNote, and ServiceNow knowledge bases.
That was the moment it clicked.
We’ve built reference architectures with Control Planes and Resource Planes — tools that let developers spin up environments and ship code. But none of it answers a simple question: Where does the actual work live? You can build golden paths. You can automate deployments. But if bugs get reported in Slack and tracked in Excel, your platform is missing something.
Governance is hard
Reflecting on that workshop — and many others before it — I realized something uncomfortable:
In all my reference architectures, reports, and platform designs, I had overlooked governance.
Not the governance of the platform infrastructure itself — but the governance of the work that flows through it. The processes. The documentation. The service catalogs. The handovers. The planning.
The stuff that makes or breaks collaboration in real organizations.
Technical transformation without process transformation doesn’t work. Organizational change without a supporting platform doesn’t work.
And neither works without governance.
Creating a new reference
That’s when I created the idea of the Governance Plane.
The Governance Plane is an overarching layer that sits alongside the Developer Control Plane, the Resource Plane, and all other planes of the Internal Developer Platform.
It manages:
- Development workflows
- Process integrations (Jira, ServiceNow, CMDBs, etc.)
- Documentation standards
- Compliance and traceability
It doesn’t replace the existing planes. It supports them — giving structure, visibility, and flow to everything that moves through the platform.
Figure 2: The Governance Plane — an essential vertical layer supporting the full flow of work across all platform planes.
Implementing a Governance Plane allowed us to have different conversations with clients:
- Clearer definitions of work intake and ownership
- Consistent documentation and knowledge sharing
- Smarter integration of business goals and technical workflows
Suddenly, golden paths (as part of a Minimal Viable Platform) weren’t scattered documents. They became part of the platform. Part of the governance. Part of the product.
Without governance, you don’t have a platform — you have a toolbox.
The new standard
Since introducing the Governance Plane into my work, the difference has been night and day.
Before, conversations with clients often stalled over basic questions:
- Where does work come from?
- Who owns which tools?
- How do teams align on priorities and progress?
After, with the Governance Plane in place, everything changed:
- Workflows became visible, structured, and integrated.
- Documentation found a clear home — not scattered across five tools.
- Tool ownership was mapped out as part of platform design, not an afterthought.
- Golden paths could be implemented consistently, because they had a governance framework to live in.
One client, after adopting the Governance Plane approach, linked their Jira workflow directly into their Developer Portal.
When a developer moved a Jira ticket from To Do to In Progress, the portal automatically provisioned a development environment — no extra clicks, no manual work.
Later, after the deployment pipelines completed their tests, the system automatically updated the ticket status to Done.
What used to be a disconnected jumble of emails, tickets, and Slack messages became a single, auditable flow — visible to everyone, supported by governance, and dramatically reducing context switching across teams.
Having a reference point — a visible, agreed-upon Governance Plane — turned vague conversations into clear decisions.
Teams understood not just how their platforms operated, but how their work flowed through them. Platform Engineering stopped being just about spinning up environments; it became about orchestrating real work across the entire organization.
A platform without governance is just automation. A platform with governance becomes a true enabler for the business.
Final reflections
Having a Governance Plane transformed the way teams work, collaborate, and build on top of their platforms. It gave structure to the invisible. It turned chaos into clarity.
So ask yourself:
- Where does work come from in your platform?
- Where does it live?
- How do you ensure that the flow of work — not just code — is visible, managed, and governed?
If your platform doesn’t answer those questions yet, maybe it’s time to add a new plane.
The Governance Plane isn’t just an add-on. It’s the missing piece that turns automation into acceleration — and platforms into true enablers for your organization.
Without governance, a platform is fragile. With governance, it becomes unstoppable.