Practical Magic: Improving Productivity and Happiness for Software Development Teams

Today we are open-sourcing the LinkedIn Developer Productivity & Happiness Framework (DPH Framework) - a collection of documents that describe the systems, processes, metrics, and feedback systems we use to understand our developers and their needs internally at LinkedIn. 

Now more than ever, developers are navigating so much change and new opportunity in this new era of Generative AI, so ensuring teams have the systems, processes, metrics and feedback systems to be successful is paramount. Our goal with this release was to offer an answer to one of the main questions we hear asked across the software industry, “How can I help my software development teams be more efficient, more effective, and happier?” We found that the best way to answer this question is through data, usually meaning metrics and feedback systems.

Over the last four years, LinkedIn has invested both time and resources to create a set of guidelines on how to design such a framework, starting from the high-level philosophy of how to think about the problem and getting down to specific best practices for implementers of data pipelines. We hope these materials can help you as you look to implement or improve productivity and happiness frameworks in your organizations, groups, or teams.

The framework starts off by describing the high-level philosophy we use to guide our work, called Goals, Signals, and Metrics. This describes how to solve one of the most difficult problems in this space, “How do I choose what to measure?” We then use this framework to describe the specific goals and signals that we selected.

Next, we discuss our Developer Personas, a system we developed for categorizing developers into different groups based on their workflows, and thinking about priorities separately for each of those groups. The documentation provides information on how you can design your own Developer Personas system. It also describes our concept of Persona Champions, who are volunteers from across the engineering organization who understand the workflows and pain points for these engineers and can share those insights for consideration and incorporation into the system.

We’ve also included some important principles that can help you avoid developing a system that will require tons of rework. We discuss the difference between “data” and “insights,” when you want to use quantitative (objective) data vs. qualitative (subjective) data, how to drive decisions (and provide the right data for your audience), and what data you should collect (including some thoughts about data schemas for engineering data).

When your data systems are in place, you’ll need to translate that data into concrete metrics, reports, and visualizations. We cover the key principles you’ll need to think about when designing any engineering-related metric and explain some of the common pitfalls in metric design. This includes understanding the potential problems of aggregating multiple metrics into a “score,” and the reasons why "volume of output" is not the best metric for judging the performance of individual software engineers.

To demonstrate how all of this works in practice, at the end we have a set of documents that detail a few specific metrics we have actually implemented at LinkedIn. It starts off by describing a few key concepts in developer productivity that are often thought about when we design metrics. We then provide detailed definitions of a few example metrics, covering both some company-wide developer productivity metrics, and a few metrics that are specific to an individual team. 

Finally, we round off the framework by explaining why we chose those metrics, with an in-depth answer for each metric in the set of example metrics. We also explain why we elected to not use some others.

We have made the DPH Framework open-source so that you can fork, modify, and re-use these documents however you wish inside of your own company, as long as you respect the Creative Commons license that is on the repository. 

We are also looking forward to community contributions that help move forward the state of the art in understanding software developers across the entire software industry. If there’s something missing in the documents that you’d like to see added, feel free to file an issue via our GitHub Issues tracker! If you just have questions or a discussion you’d like to have, participate in our GitHub Discussions.

And of course, if you want to contribute new text or improvements to the existing text, we welcome your contributions! Keep in mind that we hold this framework to a very high standard—we want it to be validated by real experience in high-level software development organizations, generally applicable across a wide range of software development environments, and that additional inputs are both interesting and accessible to a broader audience. If you think you have content that meets that bar and fits in with these documents, we would love to have your contribution! And honestly, even if you’re not sure, feel free to just send us a PR and find out!

We’re looking forward to what happens next!