Recap: Applying LinkedIn’s Developer Productivity Happiness (DPH) Framework

I recently attended a webinar featuring the architects of LinkedIn's internal developer experience framework, the Developer Productivity and Happiness (DPH) Framework. In the session, the DPH authors introduced the framework itself and shared insights and challenges they faced while rolling out the changes at LinkedIn. It was an insightful discussion, and while the specific topic of interest is related to the developer experience domain and LinkedIn's particular framework of application, I found many of the key points and lessons learned to be broadly applicable to those looking to affect organizational change in the platform engineering space generally.

Has a metric ever actually uncovered an unknown unknown?

The speakers noted that when talking to executives about developer productivity, business leaders often want to see 10x-level change — not simply a "boost" in productivity. However, identifying opportunities of this magnitude is difficult. Much like in the world of system infrastructure, seeking optimization at this scale is unlikely to be realized through incremental change; more often than not, a more fundamental re-architecture of the system, or how things are done, is needed. Yet, this is unlikely to be revealed through a single metric.

If you live in the wrong world, don't try to incrementally make the wrong world a better place.

While metrics may lead you to the problems that need fixing, they may not offer a solution on their own. There is still a good chance that you will need to reason through how the system itself will need to change, given the reality the metric data is presenting while also taking other business factors into account.

Drowning in data

A problem familiar to many an observability practitioner, sometimes there can simply be too much of a good thing. The ability to collect an ever-increasing number of metrics has never been easier as the technology landscape expands to include new tooling and instrumentation frameworks. As such, when collecting new metric data the question may need to shift from "How can we?" to "Why should we?"

A few tips from the session to help guide this decision-making:

• Consider your audience — who will be using this data, and will they have the power to affect it?
• Can you take action based on the metric?
• What should happen if the value goes up or down?

While the conversation in the webinar was related to developer experience metrics and resulting behavior or organizational changes, I found myself thinking about monitor design, and how many of these questions are also a good starting-point for thinking about moving from cause- to symptom-based alerting models.

Measuring impact vs output

While tempting, it is very important that developer experience and productivity metrics not be tied to a person's performance. Doing so simply results in gaming the system and other perverse incentives. While output metrics like lines of code checked-in or number of PRs submitted may superficially seem like reasonable methods of quantifiably measuring performance, they don't measure business impact — nor are they designed to.

This discussion reminded me again of the difference between cause- and symptom-based alerting and "critical path" coverage. To determine how well-monitored a system is, it doesn't matter how many monitors there are. What matters, at the most basic level, is whether you will know if conditions are affecting the customer experience. It may be that a single symptom-based monitor would be more effective at achieving that goal than 100 cause-based monitors.

To that end, focus instead on measuring for the desired outcome.

If you build it...

Sometimes the hardest part of rolling out a new framework is... actually getting people to use it. Unfortunately, the "if you build it, they will come" truism usually isn't, and they don't. This part of the discussion definitely hit close to the heart. I've tried (and often failed) at driving new observability adoption initiatives, and encountered this same problem when applying this mindset. But, the speakers in the session offered a few good suggestions for making a better adoption case:

• Convince yourself first — what is the story that you would tell, and that you actually believe, for why it is important to adopt [x]?
• Do your own research — can you find a "smoking gun" in the data that bolsters your argument?
• Look beyond quantitative data — sometimes qualitative data can include more compelling use case examples.

Believe people and believe numbers

If you're interested in learning more about the DPH framework, it is available on Github. If you found this post interesting, I'd highly recommend checking out the discussion for yourself — a recording is available on the DX website.