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.