Lightstep from ServiceNow Logo

Products

Solutions

Documentation

Resources

Lightstep from ServiceNow Logo
< all blogs

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

Sometimes platform teamsplatform 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 teamplatform 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.

Conclusion

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 herehere.

November 17, 2019
5 min read
Observability

Share this article

About the author

James Burns

How to Operate Cloud Native Applications at Scale

Jason Bloomberg | May 15, 2023

Intellyx explores the challenges of operating cloud-native applications at scale – in many cases, massive, dynamic scale across geographies and hybrid environments.

Learn moreLearn more

2022 in review

Andrew Gardner | Jan 30, 2023

Andrew Gardner looks back at Lightstep's product evolution and what's in store for 2023.

Learn moreLearn more

The origin of cloud native observability

Jason English | Jan 23, 2023

Almost every company that depends on digital capabilities is betting on cloud native development and observability. Jason English, Principal Analyst at Intellyx, looks at the origins of both and their growing role in operational efficiency.

Learn moreLearn more
THE CLOUD-NATIVE RELIABILITY PLATFORM

Lightstep sounds like a lovely idea

Monitoring and observability for the world’s most reliable systems