How LinkedIn analyzes developer survey data

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.

Developing developer personas 

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:

• Backend 
• Web
• iOS
• Android
• Data Scientists
• Machine Learning (ML) engineers
• SREs

Looking closer at the groups, the differences stood out. For example, our Backend developers wrote a lot of Java and mostly used IntelliJ. Our Web developers wrote mostly JavaScript or TypeScript and mostly used VS Code as their IDE. 

We then developed “personas” for each of these groups, which listed the tools they use for each phase of the development cycle.

Assigning “persona owners” to analyze survey results

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: 

• Persona owners are volunteers and it is worth noting that their role requires a fair amount of effort. We collaborate with the relevant managers to identify persona owners. Nearly all persona owners are senior engineers. In cases where a persona owner is already overloaded with work, we work closely with the relevant managers to reassign the role to someone else before the next survey. A dedicated Technical Program Manager (TPM) assists us in managing this process. 
• Every quarter the persona owners will get the survey data. They will do an analysis on the satisfaction scores and the free text feedback, and then produce an analysis. This analysis document is then presented to various executives and tech leads in charge of the relevant infrastructure for that persona. 

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.  

Why developer personas have been revolutionary at LinkedIn

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.