By Michael Coté, developer advocate VMware Tanzu

I'm still not entirely convinced that we've landed on a definition of "platform engineer." A few years ago, I felt like I turned a corner and all but ran into a big smoothie made of SRE, kubernetes, centralized developer tool groups, and Internal Developer Portals (IDP).  We're still tuning the ingredients as we drink the smoothie. Thankfully, for us crotchety DevOps people, DevOps is still a must-have for the smoothie. Despite the opaque mix, we at least know that a large part of platform engineering is focused on a streamlined and secure path to getting their software running in production.

When a platform engineering team is piecing together its own plans and priorities, a large bucket of work should be focused on the developer experience (DevEx) along that path to production. Platform teams play a major role in accelerating the software delivery cycle by making it easier for dev teams to deliver high quality software, securely, and maybe even have fun doing it.

We have a good idea of the benefits of focusing on DevEx: removing toil, reducing cognitive friction, and integrated security are just a few. Ultimately this leads to more frequent quality software releases, apps that help your business grow and function better, and talent retention. Establishing an ongoing process of intentionally working on DevEx helps put in place a shared culture in development. But how do we get there? Here's two things to start with: thinking about interfaces and capabilities and using a developer toil survey to focus on where to start and what to fix.

Go to where the developers are

First, the platform engineer group needs to go to where the developers are.

There's a concept in software design that's as worn-in as that outline of your phone on your jeans pocket: good user design goes where the user is. That is, instead of requiring a person to break out of their flow, open a new application, and switch context back and forth, you want to add your functionality where the person is already spending most of their time.

This is especially true when it comes to application developers. They spend much (most?) of their time in two places, their IDE and the command line. These are the two places that work is done: writing code, building it, testing it, configuration packaging, launching and deploying, and then testing it more in production. There are other activities, of course, but IDEs and the command line are probably the best places to start for platform engineers.

This principle plays out when you're figuring out what you want developers to use to interact with your platform. Should deploying an app be done in the IDP, on the command line, in the IDE, via a help desk ticket? We know a FAX is a bad idea...probably. If a developer has a question about how to configure load balancing, should they search on a wiki, write a question in a chat window, read a man page, or pick up a phone? Where do you troubleshoot problems in production? Manage the CI/CD pipeline? Is a spreadsheet an effective interface, a CLI tool, or maybe just throwing a paper airplane three desks over at Chris with the word "redeploy" written on the left wing?

Whitney Lee and Abby Bangser are giving a talk at Platform Engineering day that puts forth a framing for all of this: which interface should you use for each capability? The platform engineering team draws up a list of capabilities like the ones above and also a list of possible interfaces. This can be taken to an absurd length - like with a FAX machine! - but at least thinking through some of the silly, and not so silly, combinations even over tacos can be helpful. You'll build up (1) a sense for where the draw the line between interfaces and capabilities, and, (2) start building up the intuition of when an interface is a good match for a capability. With that skill and intuition, platform teams can start thinking about where to locate interfaces for platform users.

For example, usually, an obvious one is that debugging should happen in the IDE. Another example that sends clammy fear all the way down to people's toes is asking which interface to use for developer support. Ticketing systems are comfortable, predictable, and make for a good buffer. They also have a cynical side: a fantastic paper-trail that's useful in the blame-storming fights that erupt in bureaucratic and pathological organizations. But are help desks the best interface to use?

Many platform people I talk with, like teams at Mercedes and Garmin, say that chat is actually great (be it Slack, Matter, Teams, or what-have-you). This is because developers are often already in chat, using it as a primary channel of communication. It also removes the at-arms-length shield of a ticketing system. Finally, using chat builds up an internal community that starts to aid with support. Just as we see on the internet, once you build up a community around an open source project, many questions are answered by developers in that community, rather than relying only on the creators of that project

Ask the developers

I don't know if you've ever talked with application developers, but as a former application developer I can tell you that we excel at one thing, even more than at coding: giving feedback and analysis on operational improvements to achieve better outcomes. You know, complaining. Take a two hour lunch with some developers and you'll get a list of areas for improvement to rival any handful of management consulting summer interns.
 

The good way to figure out how to help developers is to ask them what problems they're having. To make that less open-ended, you should run regular survey. We published one of the surveys we use, the developer toil survey, to do just that recently.

The developer toil survey has 36 questions that cover everything from belief in organization strategy, the effectiveness of developer tools, committing code, production support, and more. Most of the questions are answered on a Likert scale (the "strongly agree," "agree," etc. five point scale). This means that you can get a quick prioritization by sorting the results. Sophisticated product managers might want to add a human feel to that sorting, of course.

By sending out this survey, platform engineers first gather a list of improvements to make. By sending it out regularly - perhaps every quarter - the platform team can get a sense of progress. Is the platform team making things better?

There's a danger with just relying on surveys, however. Developers are, after all, just people and they suffer from all the usual cognitive and just run-of-the-mill biases. For example, they might succumb to recency bias and just complain about the last problem they encountered, losing track of the relative scale of the problem. They might also have the usual desire to use new technologies regardless, fully willing to put in the time to switch over to those new technologies, taking on the risk of moving from what works to something new.

While the developer toil survey is a good start and can help you keep track of developer sentiment and happiness, automating the tracking of what developers are struggling with is also important. Things like the DORA and SPACE metrics have some ideas to offer here, though they can be difficult to implement. That focus is likely important as recent work on developer productivity metrics has been arguing.

Platform Design

When that platform engineering smoothie was thrown together, someone in the night kitchen thankfully threw in a handful of platform-as-a-product thinking. To me, this is the most impactful evolution in platform thinking in recent years: product managing the platform for application developers.

The next step in evolving how we build platforms for application developers is paying just as much attention to design: iterating through different approaches to improving developer experience. This means thinking through the capabilities developers need, what interfaces developers will use, and starting with simply asking them what they need help with.

To me, the most important aspect of a "platform" is that it product managed rather than just "delivered." Traditional IT management focuses on delivering services and guaranteeing uptime and performance. These are, of course, required for any services you rely on. The goal of a platform team, however, is to give developers tools and processes that make the developer's work better. They treat developers as customers and, thus, find out the problems their customers have and how they can best solve them. Empowering developers with feedback loops, focusing on reducing friction along the path to production, and embracing a product management philosophy are great ways to start your next platform design and boot-strap what you're building to help out application developers.

I spend a lot of time talking about this with IT practitioners and leaders. Here is a list of some of my talks if you want to learn more about successful modernization efforts, product thinking, cultural transformation, and leadership patterns.

##

ABOUT THE AUTHOR

Michael is a developer advocate at VMware Tanzu where he spends most of his time talking to organizations about their modernization efforts and improving their app dev and delivery process. A former industry analyst, Michael was an early DevOps advocate and popular guest speaker.