On-demand webinar: Everything (we think) you need to know about sampling + distributed tracing

Watch now


It’s Not Technical Skill That Matters Most for Platform Teams — It’s Empathy

James Burns

by James Burns

Explore more Observability Blogs

James Burns

by James Burns


Looking for Something?

No results for 'undefined'

Sometimes platform teams get created as a place to dump all the toil. Other times they’re created to collect systems expertise. However, the true purpose of a platform team is to increase development velocity and improve the developer experience

Still, even platform teams created for this purpose can lose their way: 

  • Their first answer to every request ends up being “No”. 
  • They make systems that are easy for them not necessarily easy for developers. 
  • They postpone fixes that are causing confusion or pain because of other projects they care about more.

How can you keep this from happening with your platform team

We’ll share five specific ways to build empathy with the developer experience, and make sure your platform team is becoming (or staying) the business multiplier it should be.

Each Platform Engineer Should Create and Deploy a New Service

Easy creation of services is an essential developer activity, either to hold new functionality, split old functionality into new units, or merge functionality together. If it’s hard to create new services, to integrate old services with new services, or to understand different services the same way, then either developers will take a long time even time they want to start working on something, or, more likely, they’ll lump stuff together in whatever services they already have to avoid the pain of creating a new one.

To build empathy for the developer experience, each platform engineer, at least once a quarter, should create a new service the official way. This means without using special platform permissions, backchannel or self-approval, using the commonly agreed on timelines for actions that aren’t in their control. 

If this feels like it takes a long time, or if they feel tempted to create lumpy services as part of the platform day to day, then this should be a platform priority.

Be a Junior Developer For a Day

Junior developers are the backbone and future of most development organizations. The time it takes for a junior developer to understand how a requested change relates to a service, make the change, test it, have it reviewed, and deploy it is the basic cycle of developer velocity.

To build empathy for the developer experience, each platform engineer, at least every month, should sit with a junior developer for a day so that they can understand how hard it is to get context in a service, make changes and understand the impact of those changes for testing, and see what happens in production and the level of risk, real and perceived, for deploying changes. If it takes a long time to get context, or a long time to run tests, or deploying to production is high risk (or perceived to be), then those should be platform priorities.

Shadow First Oncall for a Week

The effectiveness of first oncall is often directly related to the customer experience of a business, but also developers’ ability to understand systems (which change quickly).

To build empathy for the oncall portion of the developer experience, each platform engineer, at least every quarter, should spend a week shadowing first oncall for a business-critical service. If oncall is getting many pages that are false positives, generated either by the platform or by custom alerting, then there’s platform work to do to have measurable health indicators (by default). If oncall is getting many pages that are real outages, then there’s platform work to do to make changes more safe and visible. If oncall takes a long time to find the correct telemetry about the scope of a failure, or if the telemetry is unreliable, or if change is not visible in telemetry, those are all sources for platform work.

Be Director for a Day

Directors have unique perspectives on how business velocity is being impacted by developer velocity, as they’re responsible for coordinating the efforts of engineering teams to accomplish business goals.

To build empathy with how business value is recognized and how organizational decisions are impacted by platform work, at least twice a year, each platform engineer should spend the day observing a director of engineering (or equivalent’s) information about developers, developer experience, and the impact of the business. 

If there are substantial difficulties understanding developer velocity, when and how customer-facing features are made available, or the quality of the customer experience, there are opportunities for the platform to surface better executive-facing reports.

Become Product Manager for a Day

Product managers are responsible for representing customer interests in prioritizing products and features. In many companies, they also engage in discussions about technical tradeoffs with engineering and/or operations.

To build understanding of and empathy toward product management, at least a day a quarter each platform engineer should spend the day observing how platform choices and their impact on developers affect product priorities. If product management is hesitant to get new features in front of customers due to perceived risk of an outage or negative experience, or if there are trade-offs being made in priorities because of difficulty developing new features, these are opportunities to prioritize platform work.


Maintaining a focused and strong platform team requires a deep understanding of the team’s value and impact on the wider organization. By spending time with key stakeholders in development, incident response, management, and product,  the platform team can deeply and personally understand why they’re working on features and fixes that empower the business.

Interested in joining our team? See our open positions here.

Explore more Observability Blogs