Some Principles From Real World Internal Developer Platform Engineering • Russ Miles • GOTO 2024

In his talk, Russ Miles presents a deeply humanistic approach to building internal developer platforms (IDPs), framed by two pivotal stories from his career and personal life. He argues that the goal of platform engineering is not merely to provide technology, but to cultivate a “habitat” where developers can do their best work. This philosophy, which he terms “compassionate technical product stewardship,” prioritizes the developer’s experience, stories, and sense of empowerment above all else.

The Platform as a Ski Resort

Miles introduces a powerful metaphor to describe the purpose of an IDP. In the early stages, an organization’s technical landscape is like a wild, dangerous mountain. Developers, eager to innovate (“go skiing”), often get lost or injured, requiring expensive “search and rescue” operations from the platform team. This is a reactive, inefficient state.

The goal is to transform this mountain into a well-designed ski resort. This involves:

• Creating clear paths and slopes: Providing well-defined, easy-to-use “golden paths” for common tasks.
• Establishing guardrails and boundaries: Making it clear where it’s safe to operate and where the dangers lie (e.g., distinguishing “on-piste” from “off-piste”).
• Providing facilities: Offering tools, documentation, and support that are easily accessible.
• Enabling safe creativity: Giving developers the confidence to try new things within a secure and reliable environment, from beginner slopes to “double black diamond” challenges.

This metaphor serves as a vehicle to communicate the platform’s value and strategy, helping to define what is part of the product and what remains untamed wilderness.

From Product Owner to Compassionate Steward

Through a moving personal story of his battle with cancer, Miles deconstructs his own motivations, concluding that his passion isn’t for the technology, the product, or the business impact in isolation. Instead, it’s for the people using the platform and the stories they can tell about their work.

This led him to reframe his role from a “product owner” to a “product steward.” A steward’s primary responsibility is to curate a socio-technical habitat that lifts people up. The success of this habitat is measured by the quality of the developers’ experiences and their ability to create great work.

A Hierarchy of Needs for a Developer Habitat

To structure this thinking, Miles adapts Maslow’s hierarchy of needs to platform engineering. For a platform to be successful, it must satisfy a series of needs for its users:

1. Identifiable: The platform must first exist as a recognizable, coherent product. If developers cannot see the “ski slope,” the product doesn’t exist.
2. Reliable & Secure: It must provide a foundation of reliability, security, and compliance, giving users confidence.
3. Freedom to Create: The platform should balance standardization with the flexibility for teams to innovate and solve problems in their own way.
4. Freedom of Quality: Teams should be empowered to decide the appropriate level of quality and scalability for their specific product, rather than being forced into a one-size-fits-all model.
5. Freedom to Contribute: The platform should be built with “boring,” understandable technology, allowing users to inspect the code, understand how it works, and contribute back, ensuring their skills remain relevant.
6. Freedom of Expression: Developers should be able to share their work and successes with other teams, fostering a culture of learning and collaboration.

The Practice of Stewardship: Doubt, OODA Loops, and Empathy

Miles outlines a practical approach to implementing this philosophy, emphasizing that in a complex socio-technical environment, you cannot know the answers upfront.

• Start with Doubt: He references Descartes’ full, often-forgotten quote, “I doubt, therefore I think, therefore I am.” A product steward must begin with doubt, recognizing they are not the expert on anyone else’s experience.
• Focus on OODA Loops: Rather than focusing on APIs or abstractions, the goal is to improve the user’s decision-making cycles (Observe, Orient, Decide, Act). The platform’s true experience is defined by the OODA loops it enables and enhances.
• Follow the Signals: To understand user needs, a steward must follow the cognitive load, follow the chaos (support queues are “gold mines”), and remember there are no “stupid users”—only feedback on the platform’s design.
• Prioritize Stories Over Metrics: While measurements are useful, they can be dehumanizing. The most profound insights come from the stories of the people using the platform. True empathy and understanding are built through direct connection—pairing with developers, sitting in on their stand-ups, and experiencing their pain firsthand.

Finally, Miles explains the titular principle, “Don’t feed the pigeons,” as a reminder to be intentional. While listening to all user feedback, a steward must actively choose not to reinforce or standardize behaviors that go against the platform’s principles, ensuring the habitat evolves in a healthy direction.

• Tags:
• Product Management
• Platform Engineering
• Internal Developer Platform
• Socio-Technical Systems
• DevEx
• OODA Loop
• Compassionate Coding