The Platform Empathy Gap
Reasons for the gap and things you can do about it.
Let’s talk about a thing I have noticed at a number of engineering organizations throughout the years that I like to call the platform empathy gap. I have been on both sides of the gap, so maybe that gives me some perspective to talk about it.
What is a platform team?
At a moderately sized software company there comes a time when specialization is needed and there is a division between engineers working on the “front end” and the “platform”.
I would consider a platform team any team whose product doesn’t directly reach an end user, whether this is infrastructure, SRE, observability or an actual “software platform” team in a code base. Different companies tackle these teams in different ways (DevOps, platform, SRE, infrastructure, etc, etc) but there is typically some split between “font end” (not necessarily just “web”) and “platform”.
What is the empathy gap?
In my experience there is often an empathy gap on platform teams. In other words, the platform teams seem to have a subtly negative view of the “front end” teams and how they use the platform. This can manifest in a variety of ways:
Platform “products” that don’t solve the problems they are intended to solve.
Documentation and communication that seem disconnected from the way the platform is used (or a lack of documentation and training).
Hostility between certain platform teams and front end teams (lack of communication, infighting, etc).
Front end teams building tools to solve problems the platform teams are supposed to work on.
In the extreme example, large platform projects that ultimately fail and fall back to the “old way”.
If you’re in a relatively large engineering organization I would guess you’ve seen some version of this yourself at some point. So why does this gap exist?
Reasons for the Empathy Gap
Let’s talk through some reasons this gap exists. It turns out there are quite a few.
Engineering is not the customer.
In my experience this is by far the biggest reason an empathy gap exists. One core tenant of any engineering team should be that it has a customer, measures the experience of that customer, and improves those measurements over time.
Often times, in the platform space, the other engineering teams are not treated like customers of the platform, even though this is the primary reason for the platform itself.
Not enough product managers.
Because platform teams are not external customer facing they are not always thought of as having customers at all. This means the product team is much less inclined to dedicate resources to the area. Product is typically incentivized to solve problems for external customers.
This is an unfortunate mistake because one of the skills a PM brings to the table is a focus on identifying customer problems, measuring them, and advocating for them with engineering. This is no less true for internal customers than external ones. Without a PM you risk identifying the wrong problems or not measuring them at all.
Another issue in the platform space is that it takes more specific technical skill to be a PM in the platform area. You need to understand the engineering system and its problems in order to be able to identify and measure customer needs. Not every PM can, or wants, to do this.
The janitor and not the architect.
As a friend of mine used to say while while we were on a contract job in Washington, DC: “We are the janitors, and no one wants to be the janitor.”
Many platform teams spring up from a maintenance necessity. Perhaps at first you had 3 web servers and it was easy to directly log in and hack on the deployment tool. Now you’ve experienced growth and you have 5,000. A platform team gets formed and its original mission is “help us keep up with these web servers”.
In this scenario the team mission is communicated as the “janitor” and not the “architect”.
When I was a teenager growing up in the suburbs, one of the chores I was supposed to do was mowing the lawn. Did I do a great job or did I try to get it done as fast as possible? You can probably guess the answer. Now that I own my own home I take a lot more time to edge the driveway and make sure I don’t miss a spot.
A platform team needs to be able to own the house, not just mow the lawn.
Self selection.
A platform engineer and a customer facing engineer are often very different personas of engineers. This can sometimes lead to a homogenous culture on each of these types of teams and it can manifest in two ways…
If I care about customers I need to work on a front end team.
If your platform teams don’t have a customer focused mentality then engineers who want to be close to customers and solve their problems will naturally gravitate to front facing roles. Inevitably this will mean those less inclined to reach out to customers to solve their problems will gravitate toward the platform teams. Ideally, on any engineering team you need a mix of both personalities.
The smart people work in platform.
I have also seen a subtle cultural vibe with some platform teams that were thought of as solving the “hard problems” and that engineers on the front end were just pushing javascript and HTML around. People on the platform teams got recognized for “big projects” at promo time and were seen as better engineers.
The problem with this type of mentality is it creates an arrogance on the platform side. The message from a failed platform project to the front end teams is “you’re holding it wrong” not “we didn’t anticipate your needs”.
There are smart people on both of these types of teams and acknowledging their work and rewarding it is important in order to keep a good balance.
The reporting chain is too far away to be aligned.
Sometimes there is a structural problem with your engineering organization. The platform teams report all the way up to a VP that owns “platform” and the front end teams report all the way up to a VP that owns a “customer thing”. All of the organizational planning (OKRs, quarterly plans, etc) needs to make it all the way up to the head of engineering before plans between customer facing and platform teams can be aligned! Of course there will be a gap if the team planning processes are so far disconnected from each other.
Sometimes this also means the platform teams don’t actually use their own tools and spend a lot of time working in a bubble, without engaging with their customer.
The platform team doesn’t have enough people.
This is a reason for the empathy gap I have heard often. When platform projects fail, this tends to be the reason most often cited for their failure (not an empathy gap, bad design, etc).
In truth, I don’t think this is typically a problem — or at least, no more of a problem than throughout the rest of the company. Most software engineering teams feel like they don’t have enough people to accomplish a given job most of the time. When you hear this from a platform team I think it is worth digging deeper for other reasons (like the ones above).
Lots of problems. What about solutions?
Some of the problems I outlined above are hard to solve. They require hiring decisions or engineering reorganization.
Still, if you are a platform team there are quite a few small things you can do about these types of empathy gaps even if you’re not planning on hiring more platform PMs.
Smaller pilot projects with front end teams.
I have seen a lot of platform projects start with an idea and quickly expand into a redefinition of the entire surface area at the company. Sometimes this can be the nature of a platform. Still…
Whenever you take on a new project as a platform team you should have already identified a “customer” team and a plan to work with them on whatever solution you are proposing. They should be using your new platform feature as soon as it is “beta” and “small” and they should be giving frequent feedback.
Maybe most importantly, you shouldn’t have a reluctant customer. The team you’re working with should be advocating for your solution. If they aren’t, and you’re dragging them along, this is a sign that you’re not connected to the customer.
Measure your customer experience.
Making sure that the measurement of success of any new platform project includes the customer experience is paramount. Sometimes these measurements can be survey feedback and sometimes these might be actual platform metrics that represent how things are working for customer teams.
Seek out your customers instead of running office hours.
Here is a spicy hot take… office hours are a form of arrogance.
Running an “office hours” meeting says to your customers “my time is more valuable than your time so you need to meet with me only during a specified block of time and only when there are a bunch of other customers present”.
There is no doubt that platform teams are often inundated by a large number of requests from their customers, but creating a useful ticketing and triage system as well as a dedicated person to handle interrupts every week instead of doing their normal work is a better way to engage than office hours.
What you should do, instead of office hours (or in addition to office hours), is seek out your most noisy and “annoying” customers. Schedule some reoccurring time with them to get the list of their pain points and write them down. Do it on their terms and you will get a lot more honest and open feedback. This may also be an opportunity to plan a pilot project with them.
Ask instead of tell.
I have seen a lot of examples of platform teams “telling” their customers the right way to do things, rather than asking them how they are doing things and why.
Before you reach for a piece of literature like the SRE book or Building Microservices make sure you talk to your customers about why they aren’t doing the thing you think they should.
Most of the decisions I see made on software teams are not decisions made because the engineers are unintelligent, or even ignorant of the possible solutions, they are decisions made because of the everyday realities on the team. Understanding, and then solving those problems alongside the team, is the best way to be effective.
Theory based discussions almost always create more empathy gaps than they solve.
Meet with your counterparts.
Nothings solves an empathy problem more than regular face to face meetings with a counterpart manager or engineer. Get coffee or talk on zoom, even it’s about nothing. Remembering there is a human on the other side of a project is an important part of the equation.
Narrowing the Empathy Gap
Platform teams have a hugely important role to fill in the engineering organization. They are often the teams that enable other teams to move with more speed and safety. They can also quickly become disconnected from their customers.
Identifying the reasons for an empathy gap, and solving them, helps everyone on the engineering team become more effective at solving problems for your external customers.