TNS
VOXPOP
Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
0%
At work, but not for production apps
0%
I don’t use WebAssembly but expect to when the technology matures
0%
I have no plans to use WebAssembly
0%
No plans and I get mad whenever I see the buzzword
0%
DevOps / Software Development

LinkedIn Shares Its Developer Productivity Framework

LinkedIn's new open source software development framework mixes hard data with the importance of the human element.
Jan 8th, 2024 10:54am by
Featued image for: LinkedIn Shares Its Developer Productivity Framework
Photo by Mimi Thian on Unsplash.   

Between remote work, the Great Resignation, AI coding assistants and almost a quarter of a million layoffs in the technology industry in 2023, developer productivity continues to be a thorny topic.

Finding the frustrations and bottlenecks that slow down developers, improving the developer experience, and making sure devs have the right access and tools to work through the ever-present backlog — all of this ought to help organizations and developers alike. This year, Atlassian reported good results from telling its developers to spend 10% of their time “improving the things that make their day job suck”.

But measuring developer productivity isn’t as straightforward as it sounds. Done wrong, it can feel like intrusive micromanagement — potentially adding to developer burnout rates that have barely fallen since the height of the pandemic. Or the process ends up getting gamed and maybe even harming overall code quality.

Some productivity issues, like slow development infrastructure or speccing powerful enough machines to run demanding developer tools, are best handled centrally; issues around release speed, code quality or collaboration are probably something to tackle with the specific team. But how do you find what’s holding back developers and check whether changing things ends up making them better or worse?

LinkedIn hopes the Developer Productivity and Happiness (DPH) Framework it has just open sourced might help. The framework describes the guidelines LinkedIn uses to build the system it uses to understand its developers, the success (or otherwise) of engineering work, and what to focus efforts on (like its Developer Insights Hub).

Max Kanat-Alexander, one of the technical leads for developer productivity and happiness at LinkedIn, explained how it works to The New Stack. “When you talk to engineering executives, very often they will tell you ‘I really want to help people be more productive, but I don’t know where to start. I don’t know where the problem is, I don’t know where my investment will pay off the most’. And it’s really having data and feedback that lets you do that.”

Kanat-Alexander was previously the technical lead for code health at Google, and chief architect of the Bugzilla project before that, so he’s been working on developer productivity for almost two decades. In the last few years, interest in using data and feedback to improve developer productivity and happiness has increased significantly across the software industry, he told us. “This whole subject of data and feedback has really just taken wing.”

Find Your Own Metrics

It’s tempting to pick lists of metrics to track from frameworks like DORA (the DevOps Research and Assessment research group) and SPACE (work done at GitHub and Microsoft that extends DORA from the initial, very functional metrics to include satisfaction and well-being; performance; activity; communication and collaboration; and efficiency and flow). DORA has expanded enormously from the initial four metrics (deployment frequency, lead time for changes, change failure rate and time to restore service) and SPACE has a matrix of possible metrics — but it’s a mistake to treat those like a menu.

“Most of the time the most effective and successful metrics are going to be very specific to a team and their situation,” Kanat-Alexander warned.

“Trying to find a single set of cookie cutter metrics almost always falls flat in terms of their effectiveness at moving productivity for the organization and really making things better for developers.”

“What people need is a way to define their own metrics: they need to understand how to come up with metrics.” That’s what the DPH Framework tries to help with.

Image via LinkedIn; Teams at LinkedIn track a mix of metrics that are used across the company and some specific to them: the DPH Framework is a guide to finding what those might look like for your own team.

There are obviously useful metrics in frameworks like DORA and SPACE but they may be at such a high level that you need to implement metrics and gather other data to make them useful for your own situation.

Take the end-to-end time to deliver a change, which sounds like a good thing to track. “That might show changes at a very, very macro level in a very large company. But to know what drives those changes, you’d have to have a lot more information and you also have to have a very deep understanding of developer productivity.” And even with all that information, it might not be clear that the work a developer did made a difference to that final figure, while a more specific metric could be more informative.

“You might be able to have another metric that’s very clear, that shows some improvement that’s very related to the specific work that you’re doing, and really demonstrates the value of the work that you’re doing to the business and also allows you to understand where the biggest pain points are so that you know that you’re doing the most impactful work you possibly can.”

Similarly, the response time for code review can be a useful metric, and it’s one that closely tracks the size of code changes: “The relationship is super linear to size,” Kanat-Alexander pointed out; “it becomes much harder to get fast responses as changes become larger”. If you decide to track review response time to improve review throughput, you might need to split it by language or by framework or by ecosystem – but it’s more important to know what you’re optimizing for and why because encouraging smaller code changes can improve software velocity; it can also be an easy metric to game.

“You have to have the data and you have to look at the data and then you have to talk to developers and ask ‘Is this a problem? Are slow review times a thing you care about? Is there something wrong with the review tool that’s a blocker today?’. If you haven’t told us that it’s a problem and we give you a solution, will you appreciate it? Will you even use the solution?”

“First find out from your developers what they think the problem is, and then instrument that area.”

Although the framework includes examples of some of the metrics LinkedIn itself uses, they’re purposely left that till the end of the discussion, which starts with the Goals-Signals-Metrics approach used to choose those metrics.

“Goals are actually the most important and those are the things that are much easier to align up and down the org chart, because you can always ask why. For any goal you have, you say: why is that my goal? And if you keep playing that game, like a two-year-old who just keeps saying ‘why why why’, eventually you will get to the company’s mission.”

For organizations and managers, the right metrics can help understand what needs changing, especially when there are limited resources, he noted. “What do we do, what’s impeding developers the most, and what if I can only assign a limited number of people to do that work? What would be the most effective work to do?”

Avoid vanity metrics that won’t help you make decisions with the data you collect – which is, after all, the reason for collecting data in the first place. The organization has to be willing to use the metrics to make systemic changes, rather than trying to use them for individual performance reviews. “You always have to have metrics that you’re willing to be bad because that’s when you learn that there [are] problems and that’s when they’re effective,” Kanat-Alexander pointed out.

“The great news about bad news is it’s your best opportunity. It’s a thing that you can change and you can do something about.”

Happy Developers, Happy Business

Don’t be surprised that the framework doesn’t just talk about productivity. “Happiness is a really important signal for leaders to pay attention to. People sometimes think this is some sort of touchy-feely thing where you want people to be happy and they’re saying ‘I don’t need people to be happy. I just need people to do work.’ If you look into the research, it is very difficult to separate productivity and happiness. They’re very tied together.”

“It’s really never ‘how do I, by myself, code faster?’ It’s really how do we as a team, or an organization or a business, move as quickly as we can with the highest quality that we can and also keep everybody happy. Because happy people are productive, productive people are happy, happy people produce better products.”

“Everybody feels better almost always means the company is more effective at accomplishing its goals.”

Thinking about happiness alongside productivity also helps solve the problem of connecting what can be abstract metrics to the problems developers have that stop them from being productive, he suggested.

“A lot of the time what you see is that somebody thinks some metric represents productivity, but the developer doesn’t think that doing that thing represents them being productive, [or] represents their impact, or […] producing value. Happiness gives you that insight of, ‘Hey, you missed something’; maybe you’re measuring the wrong thing.’ And very often, the happiness signal is actually the broader and more encompassing signal than the quantitative productivity signals.”

The human element matters because software engineering, especially in a large organization, is best thought of as a team sport; and the issues developers run into are human issues as well as technical issues. That might be that the goals for the team aren’t clear, or the way the organization is structured isn’t efficient. “Maybe they’re involved in a lot of alignment meetings or they don’t have a clear planning process; and that ends up taking up a lot of the time that could otherwise be going to software development.”

Whether or not you believe that every company is now a software company, you might discover that poor developer productivity is actually exposing bigger underlying problems for the organization. “Theoretically, that data can absolutely help you make more intelligent decisions about how to focus your organization.”

But the framework also encourages everyone to be pragmatic. If people tell you that having the data isn’t actually going to make any difference to their behavior, you know that’s a metric that isn’t worth collecting and an analysis that isn’t worth doing.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.