Building Better Platforms with Empathy: Case Studies and Counter-Examples

When it comes to platform development, achieving scale often involves absorbing excess cognitive burdens into the platform's framework. An important aspect of constructing these platforms lies in fostering empathy. Rather than viewing individuals only through the lens of their issues, it's imperative to recognize them as people. Focusing on more than just specific issues can narrow down solutions unnecessarily. But, taking time to listen and understand diverse challenges leads to better results.

At my QCon San Francisco 2023 presentation, I emphasized the importance of integrating empathy into platform development.

Drawing Lessons from a Costly Error

After securing stakeholder approval, we embarked on a project to extend a cloud-native platform (that we had originally built), leveraging the robust Netflix stack with its blue-green deployments and relevant tools. We set out with a goal to address current usability issues with the platform.

Confident in our understanding of the platform's needs, we dove into the development. However, as we began demoing the new functionality to users — who were different from the project's stakeholders — we encountered negative feedback. Despite repeated iterations and demonstrations, it became increasingly clear that a significant gap existed between user expectations and our development direction.

Eventually we realized that users would never adopt what we were building and the project was cancelled. A sizeable budget had been spent with no return. What had begun as a well-intentioned attempt to empower teams ended in disappointment, highlighting the contrast between our hypothesis and the users' reality.

In hindsight, we recognized the critical oversight of not considering user perspectives. Our assumption of alignment proved incorrect, highlighting the importance of genuine user engagement and feedback in guiding successful project outcomes.

Significance of Empathy

Let's distinguish between empathy and sympathy. Sympathy involves reacting to someone in distress without necessarily understanding their perspective. Empathy, on the other hand, means understanding experiences from another person's viewpoint.

It's crucial to differentiate empathy from sympathy, as sympathy merely involves acknowledging negative emotions or feeling distress when witnessing someone else's suffering. For instance, the image below might evoke empathy in individuals who have experience with server rooms, allowing them to understand what the person shown below is going through. Empathy extends beyond negative emotions; it can also involve sharing in someone else's excitement or joy.

Empathy has its do's and don'ts.

First, listen without immediately jumping to solutions — which is a challenge with many technical-minded individuals. Instead of assuming and solving, ask probing questions to understand the person's experience and needs better.

Practice active listening by asking open-ended questions that uncover core issues and pains. Embrace vulnerability by admitting what you don't know, rather than rushing to demonstrate capability. Avoid the urge to explain why someone's approach is wrong; this can make the person feel isolated rather than empathized. Similarly, refrain from minimizing concerns; comparing their experience won't foster empathy or understanding.

Why do we build platforms?

Organizations adopt platforms to streamline operations when expansion leads to complexity. DevOps culture encouraged engineers to take ownership, improving speed by removing bottlenecks from the other teams. However, as companies grow, the demands of security, compliance, performance, and other factors create a cognitive load.

Cognitive load is a topic studied in academic research. It investigates how the difficulty of a learning task affects people. The right balance of cognitive load helps a person better absorb new information in a learning environment. This idea has also been applied to understand workplace tasks. NASA has an interesting concept called mental workload, developed during the shuttle program. This concept builds upon the idea of cognitive load by adding in the impact of deadlines, environmental factors, and other stressors that we can sometimes face.

Cognitive load has three primary components. Intrinsic cognitive load describes the underlying complexity of the task at hand – like figuring out your route to the supermarket and the act of driving itself. Germane cognitive load represents the knowledge and skills you need for the task – having a driver's license and knowing how to operate a car. Finally, extraneous cognitive load encompasses distractions that hinder your focus – such as unexpected traffic or detours that force you to adjust your route.

At an enterprise level, when too many people are involved in too many processes, extraneous cognitive load increases exponentially. This leads to lower overall organizational efficiency. Platforms achieve scale by absorbing much of this extraneous cognitive load. They either directly capture work, eliminating the need for users to do it, or significantly simplify it through abstraction. For any remaining tasks that can't be fully eliminated, platforms strive to make them as easy as possible for users to interact with.

Building your platform as a product makes sense for several reasons that align with a customer-focused mindset. Products have customers, and customers have options. This differs from how we typically treat internal tools. However, we've seen situations where internal customers reject what's provided, opting to use their resources to purchase solutions elsewhere – giving rise to shadow IT.

Building a Platform That Delivers Results

By treating your platform as a product, you prioritize making it the best solution. This is crucial, as the alternative (users refusing to migrate or adopt your platform) is equally undesirable. A non-compelling platform can simply become another layer in the company's growing tech stack, failing to solve real user problems. It may linger without being officially canceled, ultimately contributing to the company's tech debt rather than providing value.

The old approach was highly transactional. Users would submit requests through a ticketing system – asking for a specific feature or a change to the build system. We'd either try to incorporate these requests into the platform directly or figure out ways to automate them to handle the volume. Unfortunately, this old method resulted in limited understanding and empathy due to its reactive nature.

Platform engineering centers around building for others, not yourself. This marks a fundamental mindset shift compared to traditional systems administration. Sysadmins and even DevOps engineers focused on maintaining and modifying the shared components of a system. In contrast, platform engineering teams build a self-service product for others to utilize. The new focus is on creating an appealing product, which requires understanding your users' needs. By employing empathy and stepping into your users' shoes, you'll be far more successful than simply offering solutions based on assumptions about their requirements.

Benefits

This approach offers significant benefits. By focusing on building what users actually need, based on their direct feedback, you optimize the use of company resources. For example, if you develop five features but only two are truly valuable to internal customers, the remaining three represent wasted effort and contribute to tech debt. However, if all five features are genuinely useful to engineering teams, you'll significantly boost their effectiveness. This approach leads to accelerated growth and, likely, much higher employee satisfaction.

Much of developer experience focuses on satisfaction, and for good reason. By understanding user needs, building solutions for them, and actively eliminating their pain points, you naturally create happier engineers. This sets up a virtuous cycle: start by identifying what users need and then build it – they will adopt it. This increases overall company efficiency and effectiveness, further increasing user satisfaction. The cycle continues. Alternatively, if you build something without this approach and expect adoption, the cycle stalls if users don't engage. You've inadvertently hindered the company's potential for greater efficiency and created a roadblock to this positive cycle.

Leveraging Empathy for Results

To use empathy when building platforms, you need to create a culture of empathy. Since we're dealing with human emotions, establishing a cultural foundation is crucial. This means actively encouraging everyone to practice listening – focusing on understanding others rather than immediately formulating a response. Additionally, it's important to get to know coworkers and customers as individuals. Building these connections makes it easier to step into their shoes, shadow them, and understand their experiences – all of which are essential for building with empathy.

From a product perspective, building a culture of empathy empowers you to have honest conversations with users about their true needs, going beyond mere requests. This starts with modeling the desired behavior yourself. By actively demonstrating this approach with both coworkers and customers, you set an example for others to follow. Remember, leadership can come from any level of the organization – you don't need a managerial title to showcase these principles.

Use Product Management practices to deeply understand your users, their pain points, and the solutions they need. These techniques are equally beneficial when building internal platforms. For example, surveys can be beneficial to acquire subjective data. To grasp someone's perspective, you need to understand how they feel about the system – not just measure deployment frequency or other objective metrics. Survey your users directly, asking questions like "Do you feel you're as effective as you could be?" This type of feedback is surprisingly valuable for platform development.

The DevEx framework also offers a powerful way to identify crucial improvement areas and ask the right questions about how your platform can address user pain points. This is because its elements – feedback loops, cognitive load, and flow state – are deeply intertwined. For example, if slow build times disrupt feedback loops, addressing that directly will help users stay in a flow state for longer. Similarly, if you streamline deployment options, reducing the complexity within AWS, you lower cognitive load and boost efficiency. The emphasis on flow state is vital – the longer users remain focused and productive, the more value they generate for the company.

I believe that any organization benefits greatly from having software engineers join the platform engineering team. This diversity of perspectives is crucial for ensuring the team builds the right solutions and truly satisfies its internal customers. At the same time, platform engineers should actively work alongside their customer teams – the developers – to gain a firsthand understanding of their day-to-day experience. This reciprocal approach fosters a deeper understanding of both sides.

Key Points

Empathy means seeing people first, not just problems. By connecting with the person, you open yourself to a wider range of solutions. Focusing solely on fixing a specific issue prematurely limits your options. Taking the time to actively listen and understand the person and their broader challenges will ultimately lead to much more effective solutions.

Always remember your target audience: you're not building for yourself. As a platform team crafting a product, you're building for your customers. Keeping this mindset at the forefront will guide you towards addressing their needs. Much of what we discussed in this article is actionable on a personal level – integrating product management techniques, etc. But if you're part of a platform team, you can start making a difference right away. Focus on active listening and resist offering immediate solutions.