038: Holding Developers Accountable

Working Code

Recently on Facebook, Hal Helms —highly respected author, speaker, and computer programmer— shared some of his views on the use of "Sprints" to drive engineering work on a product team. In short, he despises the idea of asking engineers to commit to achieving a goal within an estimated time frame. He likens this to asking prisons to build their own gallows. Everyone is terrible at estimating everything. So when companies start to use each "estimate" as a "contract" with which to punish engineers for under-delivering after over-promising, all it does is set the entire team up for a toxic cycle of disappointment.

This is the full text of Hal's post:

"We have to be able to hold developers accountable."

A friend and I were discussing the idea of "sprints" — a system where developers commit to achieving certain results within a specified time frame — usually two weeks.

I hate and detest sprints. I despise asking developers to "commit" to achieving a goal within an estimated time frame. My friend disagrees. He's wrong.

The first flaw in this system is what Nobel Prize-winning psychologist Daniel Kahneman termed "The Estimation Fallacy". When people are asked how long a goal will take to achieve, they predictably and chronically underestimate the time. And this is true even when they have considerable experience in being wrong in their previous estimates.

A good estimate is one that's over half the time and under half the time. So, estimates are not really what developers are asked for. They're asked to commit to a date after which they can be held to blame if they have not achieved the goal. Every such "estimate" holds an implied threat. ' Asking developers to provide their own deadlines is a bit too much like asking prisoners to build their own gallows.

But let's say you have a taste for a bit of sadistic irony. It's still not a good idea — not if your goal is to actually increase the throughput of the system.

Developers are not, by lot, stupid. So while inexperienced developers may believe their own deadlines are realistic, those of us with more road behind us are not so quick to be led to slaughter.

If the boss demands a deadline that a more experienced developer thinks is probably five or six days, the deadline become two weeks — three if they can stretch it.

And when they actually complete the work ahead of time — well, would you be quick to voluntarily re-enter the arena only to place yourself at risk again any earlier than you have to?

It gets worse: you may know one part of the sprint goal while I know another, of which you're clueless. Can I help you? Sorry, I have my own deadline. How is this good for the developer, much less the organization?

And so I circle back to my conversation with my friend. "We have to be able to hold developers accountable." One needs to hold people accountable for things they don't want to do. Developers, on the other hand, like to develop. Most of the ones I know do it in their spare time as well as their work hours.

If I want you to do something you already want to do, what is the sense behind "holding you accountable"?

Eat this ice cream — and I'll need to see status reports of how much you've eaten, accompanied by proof that you're actually eating it (to make sure you don't just dispose of the ice cream).

I recently had a long discussion with a CEO who asked for what might be termed my "philosophy of management" when it comes to managing developers.

I told him it was really quite simple: give developers what they need and protect them from upper management.

CEOs don't produce software. CTOs don't. Product Managers don't. When upper management tries tricks like sprints to force their developers into deadlines — as if such a thing could be done by fiat — they effectively tell developers: we neither trust nor respect you.

I'm not sure what genius management consultant had the flash of insight that disempowering workers and placing obstacles in their way was a surefire way to get the most out of them.

Inspired by Hal's post, we wanted to talk about how we view—and experience—developer motivation; how we employ Sprints at our respective offices; and, what we think an organization should be doing to help drive a project to completion. There's the idealized approach that Hal puts forward:

Give developers what they need and protect them from upper management.

Amen! But, there's also the practicalities of running a business, building a road-map, organizing marketing campaigns, and keeping users interested and excited in your product. None of it is easy. But you can be sure that treating people with professional respect is certainly one of the necessary ingredients.

Notes & Links

• Daniel Kahneman: The Planning Fallacy

Follow the show! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. Or, leave us a message at [phone] (that's 512-253-CODE). New episodes drop weekly on Wednesday.

And, if you're feeling the love, support us on Patreon.

With audio editing and engineering by ZCross Media.