Building empathy and understanding for product developers help platform teams figure out where to draw the boundaries of their scope to provide better support, Erin Doyle mentioned in her talk about empathy-driven platforms at InfoQ Dev Summit Boston.
DevOps came about out of the frustration we were all experiencing from the way things were, where both developers and operations administrators were fed up with how slow and bureaucratic every little thing had become, Doyle explained:
As cloud services emerged and more tooling and automation options became available, concerns related to dedicated IT operations roles could be offloaded. Developers could do it themselves instead of filing a ticket and waiting for someone else to do it. Operations administrators could broaden their domains of responsibility and consolidate them into a single collaborative team, rather than managing multiple disparate teams with misaligned goals.
Responsibility was shifted to development teams, expecting them to manage both coding and infrastructure. Doyle mentioned that this created cognitive overload, leading to issues like inconsistent decisions, poor cost management, underused or misconfigured infrastructure, and security and compliance gaps.
Platform teams can offload the growing cognitive load from development teams, allowing them to focus on building capable and robust applications. To build empathy for product developers, platform engineers should be encouraged to work on tasks that involve software engineering, Doyle explained:
They will directly experience the pain developers are dealing with every day, the time it takes to get the app running after a fresh checkout, the “it works on my machine” issues, slow feedback loops, technical debt, etc.
To get a better understanding of a team’s context, platform engineers can temporarily or permanently be placed on a development team to help accomplish platform-related tasks, Doyle said. They will get a firsthand view of the team’s priorities, deadlines, struggles, and pain points.
Another approach is to have a specific platform engineer dotted-line to a product team. The platform engineer is still a full-time member of the platform team, but whenever the product team needs platform assistance, they have an assigned person they can always go to and can build rapport with over time, Doyle suggested.
Platform engineers should also foster an environment of psychological safety. A powerful way to help others around you feel more comfortable is by being open and honest about your thoughts, your ideas, your feelings, what you don’t know, where you need help, your failures or mistakes, and what you’ve learned, Doyle explained:
By modeling vulnerability, especially the more senior you are, the more you show that you’re comfortable sharing these things with others without fear of judgment or repercussions, the more comfortable others may be for sharing as well.
Doyle suggested adopting a habit of working out loud, and sharing publicly your progress. As you work the given task, you can essentially talk out loud and log your thoughts, your theories, the actions you’ve taken, the results you got, and all of that as you go.
Platform teams should have a high customer service attitude and availability, Doyle said. The platform team should always prioritize being available to the customers, and they should view product developers as their customers, she concluded.
InfoQ interviewed Erin Doyle about empathy-driven platform approaches.
InfoQ: What are some challenges or drawbacks of putting platform team members in development teams?
Erin Doyle: There’s the risk of the platform engineer being seen as extra headcount and being pressured to take on product work. Teams may also become overly reliant on the embedded engineer, making it difficult to end the engagement.
Maintaining the connection and context with both the platform team and the development team can be difficult. It may require more meetings and Slack channels which could be overwhelming for the embedded engineer.
While this approach can be really helpful, it should be pursued with care to address these potential challenges.
InfoQ: What benefits have you seen from building empathy and increasing psychological safety?
Doyle: When a platform team has empathy for their product developer customers, they are able to adjust their scope of work and shift to supporting and enabling those developers more effectively. When the platform team understands what developers are struggling with, they can build better-fit solutions and lift some cognitive load off of development teams.
When psychological safety has been fostered between development and platform teams, it lowers the barriers that get in the way of collaboration between these teams. It makes it easier for developers to ask for the help they need from the platform team.
Working together instead of in silos enables developer productivity and more robust and resilient architectures and applications running on the platform.
InfoQ: What can organizations do to support developers’ learning and growth for self-sufficiency?
Doyle: Building a culture of learning and sharing that is supported from all levels goes a long way! Developers need breathing room to learn, experiment, discover, and build skills. And then with that, the psychological safety to share what they’ve learned, when something didn’t work as expected, and to ask questions.
The learning and growth can really be amplified when we can bootstrap each other from our individual knowledge. A platform team can do a lot to support this, though. By sharing learnings through documentation, Lunch and Learns, videos, and Slack threads, they can impart a lot of their knowledge and tips and tricks that may be common knowledge for them, but may be difficult for developers to have the time and bandwidth to gain on their own.
