Platform engineering has rapidly evolved from a niche practice into a central discipline within modern software organizations. But the most common mistake teams make is treating it as purely a technical endeavour — building tools, APIs, and infrastructure abstractions — while neglecting the social and organizational systems in which those tools must operate.
This article explores platform engineering through a sociotechnical lens, drawing on key themes from Lesley Cordero's presentation at QCon. The core argument is that effective platform engineering must optimize for both technical systems and the human organizations that use them — and that treating these as separate concerns leads to platforms that fail to deliver on their promise.
What Makes Platform Engineering Sociotechnical?
A sociotechnical system is one in which technical components (software, infrastructure, architecture) and social components (teams, communication, incentives, culture) are deeply intertwined. Changing one inevitably affects the other.
Platform engineering sits at the intersection:
- Technical: The platform provides shared infrastructure, abstractions, and developer tools — CI/CD pipelines, service meshes, observability stacks, deployment automation.
- Social: The platform shapes how teams work, what decisions they can make independently, how they collaborate across boundaries, and what skills they need.
A platform that is technically excellent but ignores team dynamics, cognitive load, or organizational incentives will fail. Conversely, a platform that is well-marketed internally but technically unreliable will erode trust. Sociotechnical excellence requires optimizing both simultaneously.
The Pendulum of Tension
One of the central concepts is the pendulum of tension between two competing goals:
- Developer Experience (DevEx): Making it fast, easy, and pleasant for developers to build, test, and deploy software. This typically means more abstraction, more automation, and fewer operational concerns for product teams.
- System Reliability: Ensuring the infrastructure is stable, secure, observable, and performant. This often requires guardrails, standards, and constraints that can feel restrictive to developers.
These two goals are not inherently opposed, but they create a natural tension. Optimizing exclusively for developer experience can lead to platforms that are easy to use but fragile under production conditions. Optimizing exclusively for reliability can produce platforms that are robust but so restrictive that developers work around them.
graph LR
DX["Developer Experience"] <-->|"Tension"| R["System Reliability"]
subgraph "Platform Engineering"
DX
R
JO["Joint Optimization"]
end
DX --> JO
R --> JO
JO --> S["Sustainable Platform"]The role of the platform team is to find the joint optimization — the designs that improve both developer experience and system reliability simultaneously, or that make the trade-offs between them explicit and manageable.
Joint Optimization in Practice
Joint optimization means solving problems in ways that benefit both the technical system and the human organization. Examples include:
Golden Paths, Not Golden Cages
A golden path is a well-supported, opinionated default workflow for common tasks (e.g., "create a new service," "set up a CI/CD pipeline," "add monitoring"). It provides the best developer experience for the common case while encoding reliability best practices.
The distinction between a golden path and a golden cage is critical:
- Golden path: "Here's the recommended way. It's fast, well-documented, and well-supported. You can deviate if you have a good reason, but you'll own the additional complexity."
- Golden cage: "You must use this, no exceptions." This breeds resentment and shadow platforms.
Self-Service with Guardrails
The platform should enable teams to provision resources, deploy services, and configure infrastructure through self-service interfaces. But these interfaces should embed organizational policies — security requirements, cost constraints, naming conventions — as defaults or automated checks, rather than relying on manual review.
Observability as a Shared Language
A shared observability stack (logging, metrics, tracing) does more than help debug incidents. It creates a common language for discussing system behaviour across teams. When everyone can look at the same dashboards and traces, cross-team debugging becomes collaborative rather than adversarial.
Distributed Leadership
Cordero emphasizes that effective platform engineering cannot be centrally controlled by a single team issuing mandates. Instead, it requires distributed leadership — distributing ownership, decision-making, and knowledge across the organization.
Platform as a Product, Not a Mandate
The platform team should treat its users (internal developers) as customers. This means:
- Understanding user needs through research, feedback loops, and empathy — not assumptions.
- Prioritizing based on impact rather than technical interest.
- Marketing and evangelizing the platform's capabilities so teams know what's available.
- Measuring adoption and satisfaction rather than just availability and uptime.
Communal Learning
When the platform team hoards knowledge, it becomes a bottleneck. Instead, platform engineering should foster communal learning:
- Share architectural decision records (ADRs) publicly.
- Run internal tech talks and workshops.
- Pair with product teams during onboarding.
- Rotate engineers between the platform team and product teams.
This distributes expertise across the organization and ensures the platform evolves in response to real, diverse needs rather than the platform team's assumptions.
Shared Responsibility for Outcomes
Reliability and developer experience are shared responsibilities, not the platform team's alone. Product teams must take ownership of their services' operational characteristics. The platform provides the tools and standards; the teams provide the discipline and context-specific knowledge.
Organizational Fit Over Best Practices
A recurring theme is the danger of cargo-culting platform patterns from other organizations. What works at Google or Netflix may not work at a 200-person startup. Effective platform engineering requires:
- Assessing your organization's unique complexity — team structures, communication patterns, technical maturity, product evolution trajectory.
- Starting small — solve concrete, high-impact problems before building a comprehensive platform.
- Iterating based on feedback — platforms should evolve incrementally, guided by user feedback and usage data, not top-down roadmaps.
The goal is not to build the most technically sophisticated platform, but to build the platform that best fits your organization's specific needs and constraints.
Conclusion
Platform engineering, at its best, is a practice of sociotechnical excellence. It recognizes that technical platforms exist within human organizations, and that optimizing one without the other leads to fragile, underutilized, or resented infrastructure. By embracing the pendulum of tension between developer experience and reliability, pursuing joint optimization, distributing leadership and knowledge, and tailoring solutions to organizational context, platform teams can create infrastructure that genuinely accelerates the entire organization.
Reference: Platform Engineering as a Practice of Sociotechnical Excellence