My Foreword to “Frictionless”

I'm at lunch with a bunch of senior technology managers, and one is regaling the table with his latest initiative to improve his software development teams. He's launching a metrics program that will tell him which teams and staff members are the most productive so that he can promote those and fire the worst. This is a professional setting, so I'm trying my best not to roll my eyes. Attempting to get a word in edgeways, I ask what metrics he's using, and follow up by asking him if he's trying to consider business outcomes, at least to correlate them to his measurements. Sadly I'm not getting anywhere, it's hard to convince someone to look for their keys in the bushes instead of under the lamp post.

Almost every engineering manager I've met wants to make their team more productive, but almost every developer I've met wants to be more effective at what they do. But lunches like that easily lead developers to the cynicism that talking about productivity is about making simplistic measurements which forget the invincible power of Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure”.

But occasionally I run into folks who study developer productivity without falling into magical thinking - such as Nicole and Abi.

The key to this book is that they don't think in terms of how to whip people into greater productivity, but how to find the sources of friction that slow them down. Friction is when I have to submit a pull request that sits for a couple of days while I forget about the code, or spend two days wrangling some infrastructure that ought to be a simple API call. Smoothing away these points of friction is the essence of improving Developer Experience - and thus speeding up getting useful software into the hands of its users.

They describe effective developer experience in terms of three elements: feedback loops, flow state, and cognitive load. We can only find out whether we are on the right path by getting rapid feedback. The longer the delay between that blue dot moving on my phone-map, the longer I walk in the wrong direction before realizing my mistake. If our feedback is rapid, we can remain in the second element, a flow state, where we can smoothly and rapidly get things done, improving our products and our motivation. Flow also depends on our ability to understand what we need to do, which means we must be wary of being overwhelmed by cognitive load, whether it comes in the form of poorly structured code, flaky tests, or interruptions that break our flow.

Focusing on developer experience is about finding what gets in the way of these three elements. Improving developer experience leads to better outcomes for the business. Those lost hours wrangling with infrastructure is money wasted on developers' salary, and revenue lost because the software took longer to get into production.

The bulk of this book is how to develop a program to find these friction points, figuring out which bits are causing the most trouble - and fixing them. It involves metrics, but used to gain a greater understanding of developer experience. While commit frequency is a simple number that's easy to capture, it can only tell part of the story. Well-chosen developer surveys open up an oft-ignored perspective, interviewing developers adds vital context to the numbers. It's tricky to correlate these to the bottom line, but if we can, these metrics can guide us to a more effective operation.

While Goodhart's Law remains my favorite saying about measurement, a recent one that I like is:

An incomplete measurement is better than no measurement, if you treat it as a clue instead of judgment.

-- Jessica Kerr

This is a guide book to finding clues.

---