Busy isn’t the Point
In Software Engineering, Quality of Outcome and Impact > Effort and Output
Recently I was asked “How do you know if your engineers are taking naps after lunch on company time?”. Just the question stopped me in my tracks.
The question implied how would you prevent naps? How would you stop these wastrels draining the company Keep of its gold? How could you ensure you were squeezing every last dime out of their days?
I don’t. I don’t know if my engineers take a nap and, more directly, I don’t care. Perhaps more interestingly though, why don’t I care, when clearly this CTO did?
Because I don’t care as much about effort and output as I do outcome and impact. High performing teams under me care about the latter more than they care about the former. While effort and output matter, they matter a whole lot less than outcomes and impact.
Focussing more on software engineering outcomes and impact leads me to sincerely hope that people do have a kip after lunch if they need it. Our work is mostly in our heads after all, and I’d like that environment to be as refreshed as possible.
Busy developers are maxed out, tuckered out, and burning out.
The more I thought about it, the broader the realisation became. I don’t want busy developers at all. Controversial I know, but I really don’t. Busy developers are maxed out, tuckered out, and burning out. When mistakes happen these blameless participants are ignorantly labelled as the root cause.
Not on my watch.
This post today on LinkedIn hit the nail on the head. Great software development and engineering comes from a great culture but you can’t engineer the culture itself. What you measure, incentivise and reward do that for you.
In many respects this also overlaps with the excellent recent response from Kent Beck and Gergely Orosz on how to measure developer productivity:
In my experience, measuring early effort and outputs leads to arguments for efficiency. More focus on measuring outcomes and impact, albeit really hard, leads to “Who cares how busy we are, look what we did!!”. The later in the workflow you measure, the more positive the incentives seem to be.
Incentives and measurement shape behaviour. Everyone I’ve ever met in software engineering and development wants to do the job well, they just differ on what that means.
In great tech organisations I’ve been part of it means outcomes and impact matter much more than effort and output. It matters if you’re busy or not, but perhaps not for the reasons you think1. What matters more is the quality and continuous delivery output and impact. Work (activity) and work (outcome/impact) you can be proud.
A sensible eye towards not exhausting yourself or others is important to the work. Burnout is real, criminally ruins people, and is expensive all round.