The important non-technical items in running a successful platform team

Introduction

After the last five years of running two different platform teams, one at Mission Lane and one at Capital One, a variety of soft skills and non-technical items are critical to a platform team’s success. Platform teams can work on various technology. Both of mine heavily utilized containerization and Kubernetes (k8s), but this isn’t required. A platform team is any team building abstraction layers over core infrastructure for others to interact with. These teams are force multipliers, allowing your product teams to focus on delivering business value.

These platform teams don’t contribute direct value to the business, but they fundamentally enable your developer teams to move faster, lower the cognitive load, and help prevent configuration or infrastructure issues from permeating an entire organization. A well-functioning platform team will enable product teams and developers to move far faster, more efficiently, and more reliably and securely.

To make a platform team successful, there are some critically important soft skills and non-technical items that are needed. First, running empathy interviews. Second, publishing your accomplishments. Third, rotating embeds for platform team members. Fourth, onboarding sessions for developers.

Empathy Interviews with Developers

Empathy interviews are a method for product teams and businesses to gather deep, critical feedback unbiasedly from customers.

Empathy interviews usually are one-on-one conversations that use open-ended questions to elicit stories about specific experiences that help uncover unacknowledged needs. (1)

For a platform team, developers are your customers, and uncovering their unacknowledged needs –the unknown unknowns– is vital to achieving success as a platform team. At both Mission Lane and Capital One, our platform teams ran empathy interviews with developers. Here are some examples of questions we would ask:

• Tell me about the last time you tried to deploy your application. What tools did you use? Did you run into any problems?
• Tell me about the last time you were alerted about a problem with your service. How were you notified? Were you notified quickly enough? Did you have enough information to start resolving the issue from the notification? Walk me through the troubleshooting process.
• What’s your best/worst experience with the developer platform? Tell me about a time when it was hard to interact with the developer platform. Why was it hard?
• Is there a tool a former company had that you wish you had here? Tell me why. What made that tool useful?

Remember, empathy interviews help you uncover unknown problems, not discuss solutions. While you can ask if people have a preferred solution, don’t spend too much time on it. Ensure that developers feel safe and respected. Consider the power dynamics of the person conducting the interviews.

Publishing Your Accomplishments

At Mission Lane, the platform teams were blessed to work with an amazing Technical Product Manager (TPM). One of the underrated things they did was to send out an amazing newsletter every two weeks. This wasn’t just a list of things the platform team did, but notable achievements/projects, upcoming action items, new cool features or tools that teams could use, and useful/general articles from the internet.

It was normally 2–3 pages long, contained information from all the platform teams, and was a great method to communicate asynchronously with the development teams, management, and product owners. This little newsletter, which took an hour or two to put together, did an incredible amount of good PR, getting teams to volunteer for POCs and buy in for big projects. Including more than just accomplishments gave teams a reason to read and interact with the newsletter.

Your version of this doesn’t have to be a newsletter. It could be any asynchronous communication that allows people to read it and contains all the relevant information, but a newsletter is the easiest method we’ve found. Don’t forget to name it something silly. It’s the little touches that matter on things like this.

At Capital One, we did something similar. Every week we would put together a list of things we would accomplish next week, what we had done this week, and what upcoming things we needed help with from the teams. This ended up as a published document in Confluence. While this worked, the newsletter form was much more effective.

Rotating Embeds with Product Teams

There tends to be two models for a platform team. In the first, you use a Cloud Center of Excellence (CCE). In the second, you embed a platform engineer on each product team long term. There’s a few others discussed here, but these are the two primary models. CCEs are great at publishing standards, getting centralized tooling, and ensuring organizational changes. However, because of varying levels of engineering maturity on each product team, a CCE has difficulty providing specific and catered help. Embedding a platform team member in product teams leads to learned helplessness, shifting all platform work to the embed and a perpetual throwing over the wall.

However, combining CCE and rotating short-term embeds allows for the best of both worlds. The benefits of a CCE/Central Platform Team working on the platform are well discussed in other articles. But a rotating embed is like a secret cheat code to build goodwill, improve engineering quality, and roll out mass changes/procedural changes. By taking 30–50% of the platform team every quarter and running one-month embeds with different product teams, you will get to most product teams quickly.

Here’s how we structured embeds at Mission Lane:

• Every product team got an annual embed (different platform engineer each time)
• The embed lasts for 3–4 weeks max
• Had a clear list of action items that we wanted to check/improve for each team to ensure a consistent quality
• Ensure the platform team member gets invited to all the team ceremonies
• Talk to the tech leads prior to embed to get items they think the team needs help with or to learn
• Written debrief at the end by the platform engineer, focusing on problems or pain points that developers expressed or the engineer observed

These embeds provided massive value to the product teams and provided a ton of interpersonal connections that allowed the platform and developers to work well together.

Onboarding Session for New Developers

Onboarding is one of the most critical times for a new developer. It sets the entire tone for a developer’s tenure. First impressions are important! And teaching developers the expectations around the developer platform, reliability, observability, etc., and how to use it is important! Gergely Orosz over at the Pragmatic Engineer has a great article covering the importance of onboarding. Adding a section to the organization developer onboarding covering the platform setup and configuration is critical.

At Capital One, our platform team was involved in onboarding new team members. We structured our platform onboarding as follows:

• Platform architecture from the developer’s point of view
• PR to Prod
• Observability

Each took about 15 minutes and left plenty of time for Q&A at the end.

This method meant that developers had a common understanding and language for the platform and had a basis for coming and asking questions in the future. Get feedback at the end of the onboarding session. Check-in after three to six months with developers to see what things they wished you would have covered. This will allow you to refine your onboarding process over time and determine what is needed to build a common language. This is critically important. As you get bigger, engineers will come from a variety of backgrounds and experiences that will require you to build a common language and mental model of the platform.

Conclusion

There’s a variety of soft skills and non-technical actions that can make or break a platform team. And besides a base level of technical skills, soft skills will be way more important to the overall success of the platform team. The ones that I’ve found to be most critical are:

1. Performing empathy interviews. Find the unknown unknowns. Find the problems you didn’t know about.
2. Publishing accomplishments and upcoming items. Let others know what the team has accomplished, and give them a reason to read about them!
3. Using rotating embed on product teams. This provides the long-term relationships and 1:1 training critical to improving the engineering quality.
4. Platform-focused onboarding sessions. Onboarding is the first time engineers interact with your platform! Teach them about it! Don’t rely on others to do so.

The Soft Side of Platform Teams was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.