Treating internal platforms as products rather than infrastructure, and how evolutionary governance can transform developer experience and organizational effectiveness.
In the previous post, we explored why traditional governance fails complex socio-technical systems—it's a category error, like trying to manage a forest ecosystem with the same approaches you'd use for a car engine. We talked about desire paths, emergent behavior, and the fundamental reality that you can't govern autonomous teams from the top down.
But recognizing the problem is only half the battle. If complicated-system governance doesn't work for complex platforms, what does?
The answer lies in a fundamental shift: from process thinking to product thinking. Your internal platform isn't infrastructure to be managed—it's a product to be evolved.
I call this approach Desire Path Governance—a framework that treats those organizational "workarounds" and emergent behaviors not as problems to eliminate, but as valuable signals to follow and eventually pave into your platform's evolution.
Most platform teams think like infrastructure providers. They build capabilities, document them, roll them out, and consider their job done. Success is measured by uptime, deployment frequency, and compliance with architectural standards.
But here's the thing: your platform has customers. They're called developers.
Those application teams using your CI/CD pipelines, your service mesh, your observability stack—they're not just "users" consuming your "services." They're customers making daily decisions about whether your platform creates value or friction in their work. And just like external customers, they vote with their feet.
When a team bypasses your deployment pipeline to roll their own CI jobs, that's customer churn. When they build shadow databases instead of using your data platform, that's market feedback. When they copy-paste a hacky shell script instead of adopting your elegant abstraction, they're telling you something important about product-market fit.
The Customer Development Imperative
Product managers spend enormous effort understanding user journeys, pain points, and unmet needs. Platform teams should too. But most don't, because we've been trained to think in terms of technical capabilities rather than customer outcomes.
Customer development for platform teams looks different than for external products, but the principles are the same:
The key insight: your customers (developer teams) are trying to get work done, and your platform is either helping or hindering that work. Everything else is secondary.
Remember desire paths from the first post? Those worn trails that show where people actually walk, not where the urban planner intended? In platform engineering, desire paths are your most valuable source of customer feedback.
Every workaround is a feature request. Every shadow system is a gap analysis. Every bypassed process is usability research.
Desire Path Governance operationalizes this insight: instead of fighting emergence, you systematically read it, learn from it, and evolve your platform based on what you discover. It's governance that follows the flow of actual work rather than trying to redirect it.
Systematic Path Reading
But most platform teams see desire paths as problems to eliminate rather than signals to understand. They add more documentation, tighten access controls, or schedule "education sessions" to get people back on the official path.
This is backwards. Instead of fighting the desire paths, learn to read them systematically:
Shadow System Archaeology: When teams build their own solutions, don't just shut them down—understand what they were optimizing for. What made the official solution inadequate? Speed? Flexibility? Simplicity? The shadow system is often a prototype of what your platform should become.
Workaround Pattern Analysis: Look for patterns in how teams route around your systems. If everyone is writing similar shell scripts to work around your deployment process, maybe the process needs to evolve, not the scripts need to be banned.
Friction Point Mapping: Map where teams consistently hit roadblocks or slow down when using your platform. These friction points are where desire paths typically emerge—early warning signs of customer dissatisfaction.
Adoption Curve Analysis: Don't just measure total adoption—understand adoption patterns. Which teams adopt quickly? Which resist? What characteristics differentiate early adopters from laggards? This reveals who your platform actually serves well.
The Paving Principle in Practice
Remember the urban planning wisdom: pave the path people are actually using. In platform engineering, this translates to:
This isn't about lowering standards or accepting "technical debt." It's about recognizing that your customers often know things about their work that you don't, and their solutions might be more elegant than your abstractions.
So what does governance look like when you embrace this product mindset and follow the desire paths? It shifts from compliance-based to outcome-based, from preventive to adaptive, from controlling to enabling.
Fitness Functions Over Feature Requirements
Instead of mandating specific implementations, define the qualities you care about and let teams evolve solutions that meet those criteria.
Traditional governance: "All services must use our standard authentication library." Evolutionary governance: "All services must achieve single sign-on with audit trails, sub-200ms authentication, and graceful failure modes."
The fitness function approach tests for the outcomes you actually want (secure, fast, reliable auth) while allowing teams to innovate on implementation. Maybe your standard library works great for some teams. Maybe others need something lighter, or have constraints you didn't anticipate. The fitness function lets both approaches coexist as long as they deliver the required outcomes.
Safe-to-Fail Experimentation
Complex systems require experimentation, but enterprises need safety. The answer isn't to avoid experiments—it's to design experiments that are safe to fail.
This means building experimentation into your governance model:
The goal isn't to eliminate failure—it's to make failure informative rather than catastrophic.
Team Interfaces as System Interfaces
Here's where insights from Team Topologies become crucial: the way teams interact shapes system behavior more than architectural diagrams do.
Instead of focusing only on technical interfaces (APIs, message schemas, data contracts), evolutionary governance designs team interfaces:
When team interfaces are well-designed, good technical interfaces emerge naturally. When team interfaces are poorly designed, no amount of technical standards will create clean system boundaries.
Observability as Organizational Sensing
Traditional governance relies on compliance metrics: Did teams follow the process? Did they use approved technologies? Did they document their decisions?
Evolutionary governance focuses on outcome metrics: Are teams delivering value? Are they able to respond to changing requirements? Are they learning and adapting effectively?
This requires observability that goes beyond technical metrics to include organizational health signals:
The best platform teams instrument their organization the same way they instrument their systems—with dashboards that show when things are working well and alert when they're not.
This brings us to the fundamental measurement challenge in complex systems: you can't predict exactly what success will look like, but you still need to know whether you're moving in the right direction.
Leading vs. Lagging Indicators
Traditional governance focuses on lagging indicators—outcomes you can measure after the fact. Code coverage, deployment frequency, incident count. These metrics tell you what happened, but they don't help you steer.
Evolutionary governance emphasizes leading indicators—signals that predict future outcomes. Developer satisfaction predicts platform adoption. Time-to-recovery predicts system resilience. Cross-team collaboration ease predicts architectural health.
The North Star Metric Problem
Product teams often have a "North Star" metric that guides all decisions. But complex socio-technical systems resist single metrics because they optimize for multiple, sometimes competing outcomes.
Instead of one North Star, evolutionary governance uses constellation metrics—a small set of indicators that together paint a picture of system health:
The key insight: optimize for the ability to adapt, not for any specific outcome.
Economic Thinking for Platform Teams
Product teams understand unit economics—the cost to acquire customers, lifetime value, churn rates. Platform teams should think economically too, but about developer productivity instead of revenue.
What's the economic impact of:
These aren't just "quality of life" improvements—they're economic levers that affect the entire organization's ability to deliver value.
The deepest shift in evolutionary governance is philosophical: you stop trying to control the system and start participating in its evolution.
The Symbiotic Relationship
You're not managing your platform from outside the system—you're part of the system. Your platform team's decisions influence how application teams work, which influences how they use your platform, which influences what capabilities you need to build next.
This creates a feedback loop where your success depends on your customers' success, and vice versa. True symbiosis, not just service provision.
Governance as Conversation
Instead of governance as enforcement, think of governance as an ongoing conversation between human intentions and emergent realities.
You set constraints and create capabilities. Teams use those capabilities in ways you didn't expect. New patterns emerge. You learn from those patterns and evolve your constraints. The cycle continues.
This conversation happens at multiple levels:
Day-to-Day Implications
What does this look like in practice? It means:
It means recognizing that your most important governance decisions aren't about code standards or deployment processes. They're about creating conditions where good things can emerge.
Here's the thing about Desire Path Governance: it never stops evolving. Your platform will continue to grow, your organization will continue to change, and new desire paths will continue to emerge.
The goal isn't to find the perfect governance model and stick with it. The goal is to build adaptive capacity—the ability to sense when your current approach isn't working and evolve something better.
Your platform isn't a machine that you build once and maintain. It's not even a garden that you tend. It's a living system that co-evolves with the organization around it.
The desire paths will keep appearing. Your job isn't to prevent them—it's to read them, learn from them, and help the system find better paths forward.
Because in the end, the most successful platforms aren't the ones with the most elegant architecture or the most comprehensive documentation. They're the ones that help their customers do their best work, and keep evolving to do it better.
Desire Path Governance gives you a framework for that evolution—a way to govern complex socio-technical systems by working with their natural patterns of emergence rather than against them.
Your platform is having a conversation with your organization about what's possible. Make sure you're listening to both sides.
In the next post, we'll explore how to identify and eliminate organizational senescence - the zombie processes and legacy systems that block healthy evolution and drain resources while providing minimal value.