Posted by The Problem with DevOps-as-a-Team
We’ve all seen it. A company announces they’re “doing DevOps” by creating a DevOps team. That team becomes a bottleneck, fielding tickets for pipeline fixes, infrastructure requests, and change approvals. Application team waits. Frustration builds. The promised agility never materialises.
Sound familiar?
The issue isn’t DevOps as a philosophy; it’s the implementation. After a decade of DevOps adoption, we’re learning that throwing tools and teams at the problem isn’t enough. Enter platform engineering: a product-oriented approach to building the internal capabilities that application teams actually need.
What Platform Engineering Actually Means
Platform engineering is the discipline of designing and building self-service internal developer platforms (IDPs) that enable application teams to autonomously build, deploy, and operate their applications. Unlike traditional DevOps implementations, platform engineering treats infrastructure and developer tooling as a product, not a service.
The key difference? Platform teams don’t do work for application teams; they build capabilities that empower application team members to do work themselves.
Think of it this way:
– Old model: Application team submit tickets to get a database provisioned (wait time: days)
– Platform model: Application team uses a self-service portal to provision a database (wait time: minutes)
The platform team focuses on building paved roads, not fulfilling requests.
Why Now? The Cognitive Load Crisis
Modern infrastructure services are overwhelmingly complex. Teams juggle:
– Container orchestration (Kubernetes)
– CI/CD pipelines
– Cloud infrastructure (multi-cloud, often)
– Security scanning and compliance
– Observability and logging
– Secret management
– Cost optimisation
– And oh yes, actually writing application code
This cognitive load is unsustainable. Research shows that when teams exceed their cognitive capacity, quality drops, incidents increase, and burnout accelerates.
Platform engineering addresses this by abstracting complexity without removing control. Application teams get sensible defaults and guardrails, but can still dive deep when needed.
The Product Operating Model for Platforms
Here’s where platform engineering intersects with modern operating models. Your internal platform is a product. It has customers (your Business teams), features, a roadmap, and success metrics.
This means applying product management discipline:
1. Know Your Users
Conduct user research. What slows your application team down? Where do they spend time on undifferentiated heavy lifting? What frustrates them most?
One financial services company I worked with discovered its application teams were spending 40% of their time dealing with unstable environments, manual release steps, unclear ownership during incidents, and slow handoffs between teams. That became the platform team’s north star.
2. Define Success Metrics
Forget vanity metrics. Track what matters:
– Time to onboard new services
– Lead time for changes (DORA metric)
– Application team satisfaction (NPS or similar)
– Platform adoption rate across teams
– Reduction in incidents or support tickets related to environments, releases, or service handoffs
3. Build a Roadmap
Don’t boil the ocean. Start with the highest-impact pain points. Maybe that’s:
– Standardised CI/CD templates
– Self-service environment provisioning
– Unified observability stack
– Golden paths for common service delivery patterns (e.g., incident response, deployments, scaling)
Iterate based on feedback, just like any product.
4. Create Feedback Loops
Hold office hours. Maintain a public roadmap. Run retrospectives with platform users. The platform isn’t done when it ships; it’s never done.
Real-World Implementation: A Practical Framework
Let’s get tactical. Here’s how to start:
Phase 1: Assessment (Weeks 1-4)
– Map your current state: what tools, processes, and teams exist?
– Survey application teams: where’s the friction?
– Identify quick wins vs. long-term investments
Phase 2: Build the Minimum Viable Platform (Months 2-4)
Don’t build everything. Pick 2-3 high-impact capabilities:
– Example: A standardized Terraform module library + a self-service portal for common resources + basic CI/CD templates
Phase 3: Drive Adoption (Months 4-6)
– Start with one friendly team (early adopters)
– Document everything
– Gather feedback relentlessly
– Iterate quickly
Phase 4: Scale and Evolve (Month 6+)
– Expand to more teams
– Add more capabilities based on demand
– Measure relentlessly
– Celebrate wins publicly
Common Pitfalls to Avoid
Building in Isolation: Platform teams that don’t engage with users build the wrong things. Ship early, ship often, get feedback.
Over-Engineering: Don’t build the perfect platform. Build a useful platform. Start with conventions and documentation before custom tooling.
Mandating Adoption: If you have to force teams to use your platform, you’ve built the wrong thing. Great platforms get adopted because they make life easier.
Ignoring Security and Compliance: Bake these in from day one. Security as a feature, not an afterthought. Your paved road should be secure.
Treating It Like a Project: Platforms are products with lifecycles. They need sustained investment, not a one-time build.
The Business Case: Why Leadership Should Care
Platform engineering isn’t just about making endusers happy (though that matters). It delivers measurable business value:
– Faster time to market: Reduce deployment friction, ship features faster
– Better resource utilisation: Application users focus on business logic, not infrastructure
– Improved security posture: Standardised, vetted patterns reduce vulnerabilities
– Cost optimisation: Centralised management of cloud resources and tools
– Retention: Application teams stay where they can focus on meaningful work
One retail company documented a 60% reduction in time-to-production for new services after implementing its IDP. That’s the difference between quarterly and weekly releases.
Where ITSM Fits In
For organisations with mature ITSM practices, platform engineering doesn’t replace governance; it automates it. Your platform becomes the enforcement mechanism for policies:
– Change management? Automated approvals for standard changes through the platform
– Configuration management? Infrastructure as code tracked in version control
– Security compliance? Baked into templates and enforced via policy-as-code
The platform becomes your automated control plane, not a circumvention of controls.
Getting Started Tomorrow
You don’t need a massive budget or a year-long initiative. Start small:
1. This week: Talk to three application users about their biggest time-wasters
2. This month: Document one golden path (e.g., “how to deploy a containerised service”)
3. This quarter: Automate that golden path so it’s self-service
4. This year: Measure adoption and iterate
Platform engineering is DevOps, evolved. It’s taking the cultural principles we’ve learned: collaboration, automation, measurement, and applying them with a product lens. The result? Application teams that move faster, operate more safely, and focus on what actually matters: delivering value to customers.
The Bottom Line
The future of DevOps isn’t more tools or more teams; it’s better platforms. Platforms built with empathy for users, grounded in product discipline, and focused on removing friction rather than adding process.
If your DevOps transformation has stalled, or if your end users spend more time fighting tools than building features, it might be time to think like a platform engineer. Build the roads. Let your teams drive.
What’s one friction point your platform could eliminate this quarter?