Head of Marketing
Developer experience surveys can unlock powerful insights on what is affecting developer productivity and how to improve. However, analyzing and interpreting results from surveys isn’t always a simple task, particularly in large engineering organizations with diverse teams and roles.
We interviewed Max Kanat-Alexander, who leads the Developer Insights team at LinkedIn, to learn about how his team approaches survey analysis and follow-up. LinkedIn has been conducting a quarterly DevEx survey for several years. In this article, Max explains how his team utilizes developer personas to better interpret and act upon survey results.
With that, it’s over to Max.
Infrastructure teams often make the mistake of building one-size-fits-all tooling for all software engineers. This occurs in part because they lack a strong understanding of their customers and inadvertently build what they think their customers need.
To prevent this at LinkedIn, we implemented a segmentation approach that categorizes the company’s developers into distinct groups. We call these groups “personas.” This method has proven highly valuable in our data analysis and decision-making processes.
At LinkedIn there are many kinds of developers, and each have different needs, usage patterns, and productivity issues. To segment our data, we started by developing an understanding of the largest, distinct cohorts of developers at the company. Then we segmented developers into cohorts based on their workflow. These were the groups we identified:
We then developed “personas” for each of these groups, which listed the tools they use for each phase of the development cycle.
We look for a developer from each of the personas to be a representative of that group. We call them the “persona owner”; for example, if you are the backend owner, you are actually a backend developer at LinkedIn. Persona owners are responsible for performing the analysis on their group from our quarterly DevEx surveys.
A persona owner’s job is to advocate to tool and infrastructure owners on behalf of their cohort. Here’s how this works:
Part of the reason we want persona owners to be members of their cohort is because when reviewing the data, they will have a better sense of what the feedback from developers means and which areas are especially painful. They also operate as the point-of-contact for engineers building the tools when they want more insights about the cohort.
This system — the Developer Personas and Persona Owners — has been extremely successful. With this model, we transformed the way infrastructure leaders think about internal users.
Without Developer Personas, it’d be all too tempting to take the largest group of developers and serve only them, typically backend engineers. However, smaller groups of developers are also key to the business. For example, the number of engineers doing Backend Java work is greater than the number of developers doing iOS work, but obviously our iOS platforms are very important for LinkedIn’s members and customers. We need to think about the priorities of serving iOS engineers separately from how many of them we have. We need to look at the pain points of all Developer Personas and consider how we’re going to prioritize our efforts, taking the business context into consideration as well.
Thanks to Max for sharing his experience. Infrastructure teams can fall into the trap of building tools before gaining a complete understanding of their customers. LinkedIn’s strategy of using personas and assigning persona owners can help leaders better analyze and act upon the results from their developer experience surveys.