After spending two decades building and scaling engineering organizations, I’ve come to a conclusion that might seem counterintuitive: the biggest productivity killer in most enterprises isn’t technical debt, legacy systems, or even organizational politics. It’s cognitive load. Developers spend an unconscionable amount of time navigating infrastructure complexity instead of solving business problems. Platform engineering, done right, is the antidote.
The Developer Experience Crisis
Let me paint a picture that will be familiar to anyone who’s worked in a large organization. A developer needs to deploy a new service. They spend three days navigating Confluence pages, Slack channels, and tribal knowledge to understand the deployment process. They submit tickets to three different teams. They wait two weeks for a Kubernetes namespace. By the time they can actually write code, they’ve forgotten half of what they were trying to build.
This isn’t an exaggeration—it’s the reality I’ve seen in organization after organization. The irony is that these same companies have invested millions in cloud infrastructure, CI/CD tools, and observability platforms. The tools exist; the problem is that developers can’t access them without becoming infrastructure experts themselves.
What Platform Engineering Actually Means
Platform engineering is the discipline of building and maintaining an Internal Developer Platform (IDP) that provides self-service capabilities to development teams. The key word is “self-service.” If developers still need to file tickets and wait for approvals for routine operations, you don’t have a platform—you have a help desk with better tooling.
A well-designed IDP abstracts away infrastructure complexity while preserving the flexibility that teams need. It’s not about limiting what developers can do; it’s about making the right thing the easy thing. When spinning up a new environment takes five minutes instead of five days, developers naturally gravitate toward better practices.
The Four Pillars of Effective IDPs
Developer Portal: This is the front door to your platform. It should provide service catalogs, documentation, API exploration, and project scaffolding. Backstage from Spotify has become the de facto standard here, though I’ve seen successful implementations with Port, Cortex, and custom solutions. The key is that developers should be able to discover and consume platform capabilities without reading a manual.
Self-Service Infrastructure: Developers should be able to provision environments, databases, secrets, and other resources without filing tickets. This doesn’t mean giving everyone admin access to AWS—it means providing guardrailed interfaces that enforce organizational policies while enabling autonomy. Crossplane and Terraform with proper abstractions are my go-to tools here.
Automated Pipelines: CI/CD should be a platform capability, not something each team builds from scratch. Golden paths for common deployment patterns, with escape hatches for teams that need custom workflows. ArgoCD for GitOps, Tekton for complex pipelines, and GitHub Actions for simpler workflows form a solid foundation.
Observability as a Service: Developers shouldn’t need to configure Prometheus, set up Grafana dashboards, or figure out log aggregation. The platform should provide these capabilities out of the box, with sensible defaults and the ability to customize when needed.
When to Use What: Platform Engineering Tools
The platform engineering ecosystem has exploded in the past two years. Here’s my framework for choosing tools based on organizational context:
Backstage (Spotify): Best for organizations with strong engineering culture and willingness to invest in customization. It’s open-source and infinitely extensible, but requires significant engineering effort to implement well. Choose this if you have a dedicated platform team of 3+ engineers and want full control over the developer experience.
Port: Ideal for organizations that want Backstage-like capabilities without the implementation overhead. It’s a SaaS platform that provides developer portals, service catalogs, and self-service actions out of the box. Choose this if you want to move fast and have budget for commercial tooling.
Humanitec: Best for organizations focused on standardizing deployment workflows. Its Platform Orchestrator provides a powerful abstraction layer for Kubernetes deployments. Choose this if your primary pain point is deployment complexity rather than service discovery.
Crossplane: Essential for organizations that want to treat infrastructure as Kubernetes-native resources. It’s the best tool for building self-service infrastructure capabilities that integrate with GitOps workflows. Choose this if you’re already deep in the Kubernetes ecosystem.
The Metrics That Matter
Platform engineering success should be measured by developer outcomes, not platform metrics. I focus on four key indicators:
Time to First Deploy: How long does it take a new developer to deploy their first change to production? World-class platforms achieve this in under 30 minutes on day one.
Self-Service Rate: What percentage of infrastructure requests are fulfilled without human intervention? Target 90%+ for routine operations.
Mean Time to Recovery: When things break, how quickly can developers diagnose and fix issues? Good platforms provide the observability and rollback capabilities to achieve sub-15-minute MTTR.
Developer NPS: Do developers actually like using the platform? Survey regularly and act on feedback. A platform that developers avoid is worse than no platform at all.
Common Pitfalls to Avoid
I’ve seen platform engineering initiatives fail in predictable ways. The most common mistake is building a platform in isolation from the developers who will use it. Platform teams that don’t embed with product teams end up building solutions to problems that don’t exist while ignoring the problems that do.
Another failure mode is over-engineering. The goal is to reduce complexity, not shift it. If your platform requires a PhD to understand, you’ve failed. Start with the simplest possible solution that solves real problems, then iterate based on feedback.
Finally, don’t underestimate the organizational change required. Platform engineering isn’t just a technical initiative—it’s a cultural shift. Teams that have been filing tickets for years won’t automatically embrace self-service. You need champions, training, and patience.
The Path Forward
Platform engineering is not optional for organizations that want to remain competitive. The companies that figure out how to give developers superpowers—while maintaining security, compliance, and operational excellence—will outpace those that don’t. The investment is significant, but the returns compound over time.
Start small. Pick one high-friction workflow and automate it completely. Measure the impact. Use that success to build momentum for broader platform investments. The goal isn’t to build the perfect platform on day one—it’s to create a foundation that evolves with your organization’s needs.
Discover more from Code, Cloud & Context
Subscribe to get the latest posts sent to your email.