Platform Engineering: A Deep Dive Conversation • Russ Miles & Kevlin Henney
In this interview from GOTO Copenhagen 2024, Russ Miles, interviewed by Kevlin Henney, explores a human-centric approach to platform engineering, encapsulated by the phrase "Don't feed the pigeons." He advocates for focusing on desired behavioral changes and empowering creative work over doubling down on existing, suboptimal tools and processes. The discussion delves into using OODA loops, creating a developer "habitat," and the critical role of empathy and storytelling in understanding and improving complex sociotechnical systems.
The Philosophy: Don’t Feed the Pigeons
The central theme of the talk is captured by the phrase “Don’t feed the pigeons,” a piece of advice from a former boss. It serves as a metaphor for not reinforcing or building solutions around behaviors and tools that you ultimately want to move away from, even if users are asking for them.
Russ Miles gives a concrete example where developers pleaded, “please don’t take Terraform away from me.” Instead of simply building better tooling around Terraform, his team dug deeper. The real fear wasn’t about the tool itself, but about career progression and skills becoming obsolete. The underlying story was a desire to not be locked into a proprietary system that would devalue their experience elsewhere.
The solution was to abstract the direct interface away from Terraform, reducing cognitive load, while keeping it accessible through an inner open-source model. This addressed the developers’ core anxieties without “feeding the pigeon” of complex, direct Terraform management. This highlights a fundamental principle: user requests are often solutions that mask a deeper, unarticulated problem.
A Human-Centric Approach to Platform Engineering
Platform engineering is often approached from a purely technological perspective, focusing on tools, APIs, and infrastructure. Miles argues for a different starting point: What is the behavioral change we are looking for?
Instead of starting with tech, he focuses on the people and the “habitat” the platform creates for them. Drawing a parallel to architecture, a platform shouldn’t just be a structure of services and APIs; it should be a space where developers can live, work, and be creative. The goal is to create a safe, confident environment where developers can take risks.
This requires building a foundation of trust. The lower levels of a platform’s hierarchy of needs—security and reliability—are “table stakes.” When a platform team asks developers to give up direct control, they are asking for trust. Violating that trust is catastrophic.
Empowering People with OODA Loops
To understand and design the interactions between people and the platform, Miles uses John Boyd’s OODA loop model (Observe, Orient, Decide, Act). The core question is: What are the loops that help the people using the platform make better decisions and perform better actions?
This framework helps to give meaning to the often-vague two-way arrows in architectural diagrams that connect a human to a system. Instead of seeing people as external actors interacting with a system, the focus shifts to designing the system to improve their decision-making cycles.
An example provided was the discovery of an “organizational bug” where product owners were mandated to spend 25% of their time on technical tasks because they were perceived as not understanding technical priorities. The platform team’s job then became to build OODA loops for the product owners. The goal was not to make them technical experts, but to provide them with the right information and context to:
- Understand the resiliency and security characteristics of their product.
- Engage in meaningful conversations about trade-offs with engineering teams.
- Feel empowered and “smarter” in technical discussions, rather than alienated.
The Power of Stories and Qualitative Understanding
Miles emphasizes that in complex sociotechnical systems, quantitative data and metrics are insufficient. The real insights lie in stories. To truly understand the user’s world, you must listen to their experiences.
- Eliciting Stories: The best way to understand needs is to sit down with people and hear their stories. Personas are useful abstractions, but nothing beats a conversation with a real person with a name, a history, and a set of daily frustrations.
- Wardley Mapping with a Person as an Anchor: When creating Wardley Maps, anchoring the map to a specific person (e.g., “What does Donna need?”) creates a much richer and more accurate picture of needs and dependencies than a generic user role.
- Complexity Theory: In complex domains, you cannot engineer a perfect solution from the outside. Instead, you should look to influence the system by asking, “What would better look like?” The answer, drawing from Dave Snowden’s work, is often: more stories like this, and fewer stories like that.
Soft Skills are the Hard Skills
The skills required to do this work—active listening, empathy, compassion—are often mislabeled as “soft.” They are, in fact, incredibly difficult and critical for success. Miles draws on his volunteer experience as a crisis hotline listener, where the core job is to create a space to purposefully understand another person’s world without judgment or baggage.
The metaphor for empathy is “climbing down into the hole” with someone, sitting with them, and understanding their frustration from their perspective. This process builds the rapport and trust that are essential for any product, especially a platform that developers depend on. As a product steward, your values and how you operate represent the product itself.