Platform Engineering: From Theory to Practice • Liz Fong-Jones & Lesley Cordero

The emergence of platform engineering can be seen as an evolution from DevOps, much like Site Reliability Engineering (SRE) was. It acts as a unifying domain, bringing together disciplines like reliability, security, UX, and accessibility. Rather than having separate “ambassadors” from each discipline approaching developers independently, platform engineering aims to create a single, cohesive developer experience with sensible defaults. This movement stems from the realization that simply creating a “DevOps engineer” title or strictly adopting Google’s original SRE model often fails to solve the core problem of enhancing developer productivity and empowering engineers to do more with less duplicated effort.

Building Effective Platforms: Principles and Practices

A successful platform engineering culture is built on several key sociotechnical principles:

• Psychological Safety: Essential for the experimentation and learning that underpins SRE and platform engineering. Teams need the safety to take risks, try new approaches, and fail without fear of blame, which is crucial for innovation and improvement.
• Evidence-Based Prioritization: When deciding between feature work and platform maintenance, teams should rely on evidence. This can be gathered through developer surveys asking qualitative questions like, “How did your last on-call shift feel?” This data helps platform teams understand developer pain points and prioritize work that delivers the most impact, ensuring they don’t over- or under-invest in any single area. As an organization grows, this allows teams to proactively address scaling challenges before they become critical problems.
• Observability as a Foundation: Observability provides the critical feedback loop for building an accurate mental model of a system. When a discrepancy exists between a design document and a trace, the trace is the source of truth.

The goal of observability is to give you and your systems a feedback loop so that you have a good mental model of what the system is doing.

For new engineers, exploring a service’s API endpoints through an observability tool is often a more effective way to understand its actual behavior than reading code or potentially outdated documentation.

• Automated and Accurate Documentation: Misleading documentation is worse than no documentation at all because it leads to incorrect mental models. A powerful platform practice is to automate the generation of documentation directly from code comments and other artifacts, ensuring it remains up-to-date and reliable.
• Platform as a Service, Not a Mandate: Platform teams succeed when they provide genuine value that developers want to use, not when they enforce a monopoly. The goal is to help other engineers do their jobs more effectively. A top-down, mandated approach often leads to resentment and the rise of “Shadow IT” or “Shadow Ops,” where teams build their own solutions to get around the central platform.

The Open Source Ecosystem

Platform engineering is deeply intertwined with the open source ecosystem. A common misconception is conflating Kubernetes with a developer platform.

Kubernetes is not a developer platform. Kubernetes is a platform for building a developer platform.

We cannot expect every software developer to learn how to write Kubernetes manifests. This creates layers of abstraction—from the end-user to the application developer, to the platform engineer using Kubernetes, to the Kubernetes contributors themselves.

The sustainability of this ecosystem faces several challenges:

1. Corporate Influence: When the lead contributors to a project work for a single employer, it creates risks related to sudden strategy shifts or layoffs.
2. Funding Maintenance: There is often a focus on funding new features rather than the long-term, less glamorous work of maintenance and security patching. This can lead to maintainer burnout.
3. Cultural Norms: To function effectively, engineers must understand the maintainer’s perspective to write better bug reports and interact respectfully, fostering a healthier culture.

OpenTelemetry serves as a successful model for open source collaboration. Its success is driven by strongly aligned incentives between observability vendors (who want to deduplicate SDK development efforts), library authors (who want to build in a single telemetry standard), and end-users.

Career Development and Team Dynamics

The conversation also touched on the career paths and team structures that support a healthy engineering organization.

• The Engineer-Manager Pendulum: The decision to switch between an individual contributor (IC) and a manager role is strategic, based on the needs of the organization and the individual’s career goals. Experience as a manager provides invaluable insight into organizational psychology, which is beneficial even after returning to an IC role, particularly for tech leads who must mentor teammates and navigate team dynamics.
• Innovative Onboarding: One effective onboarding strategy is to have the second-most-recent group of new hires present the platform architecture overview to the newest recruits. This creates a “living oral story” of the system, preventing reliance on a single tenured expert and reinforcing learning for the presenters.
• The Importance of “Chopping Wood”: Senior leaders and architects must earn the trust of the engineering team. This involves not only proposing new ideas but also contributing directly to the codebase by fixing bugs, improving performance (e.g., reducing build times), or paying down technical debt. This demonstrates a commitment to the team’s daily work and ensures that leadership remains grounded in the technical reality.

• Tags:
• Open Source
• Devops
• Platform Engineering
• Developer Productivity
• Feature
• Observability
• SRE
• Sociotechnical Systems