Resilient Developer Productivity

I attended the LeadDev Conference in London back in June, and true to form it’s taken me the better part of half a year to reflect and write anything up based on the experience… 🐢

That said, better late than never. The purpose of this article isn’t to sum up my experience of the whole conference, but to highlight one of the talks that stood out to me: that given by Cat Hicks, PhD, titled ‘Where we’re going wrong with developer productivity’.

Cat’s talk is available to watch in its entirety here, for those who attended the conference

As you might infer from the title, Cat’s talk is centred around common misunderstandings of productivity; she talks specifically about developer productivity, but I think some of the tropes she highlights are pervasive not only in the software industry but also across the rest of the working world.

It’s worth acknowledging the perennial relevance of this topic, given that this talk was delivered before that infamous McKinsey article dropped in August, briefly setting the world of engineering management alight with righteous indignation at the idea of an “end-to-end view of software developer productivity” that measured neither outcomes nor impact, and made very little attempt to engage with the fundamental role of culture and organisation in driving productivity.

For a decent rebuttal of the McKinsey framework, see Gergely Orosz and Kent Beck’s August issue of the Pragmatic Engineer newsletter

Cat’s talk does touch on measuring productivity, but it’s also about the type of productivity we want to be nurturing. She distinguishes between what she calls brittle productivity and resilient productivity, with the key differentiator between the two being sustainability through developer thriving (a word that Cat likes a lot, as do I).

One thing that resilient productivity requires is a clear and shared definition of success, without which it’s easy to fall back on some common, but unhelpful, heuristics of what it means to be productive and successful:

1. Productivity is hard (i.e., if it hurts and requires massive effort, then it must be productive — power through the pain to find success)
2. Productivity is never stopping (i.e., the crunch is your friend — work longer hours, produce more lines of code and you will have been more productive)
3. Productivity is lonely (i.e., you are most productive working on your own — forget the wider impact of your work or your place in the team, just grind out the features you’re asked to and that is your success)

Reliance on these heuristics will generally result in the aforementioned brittle productivity. The problem with brittle productivity is that it will produce results and appear successful, which makes it very difficult to spot that something is wrong and can lead to exacerbation of the problem by ‘successful’ teams being given more work due to their ‘success’. It’s only when something breaks (or half the team quits due to burnout 🤯) that you realise you’ve got a problem on your hands. ‘No productivity’ is far easier to spot!

You can also encounter problems with undervaluing the ‘quiet lynchpins’: developers who don’t appear to contribute much on paper (e.g., low numbers of PRs completed, lines of code written (ick), features delivered etc.), but are foundational through their ability to help others on the team, whether by technical expertise or the experience to ask just the right incisive questions at the right moments. When these people are let go or moved to other projects as a result of their ‘lack of productivity’, the ability of other team members to deliver work plummets and productivity takes a massive hit. Their hidden contribution was spread across the output of the team as a whole, and that contribution is now gone.

By contrast, resilient productivity is sustainable as it doesn’t rely on the sort of posturing, ‘looking busy’ or tendency to hide authentic thoughts or feelings that comes from a brittle environment — it embraces the concept of developer thriving, of which a huge part is the ability to bring one’s whole self to work and feel a sense of belonging and unique contribution (it stands to reason that this produces better work — without spending half your energy on the ‘work facade’, you’re instead able to devote that energy to the work that matters).

This thriving strongly predicts productivity. The evidence suggests that it is highly unlikely that you will find a team that is thriving and isn’t also productive, and that this holds for teams of all sizes (i.e., it scales well, unlike brittle productivity where risk scales proportionally to output!).

So the question would then be: ‘how can I assess how well my team are thriving?’. Through Cat’s research, she has identified the following four factors that give a good indication as to how well individuals, and the teams they form, are thriving:

1. Agency (can people speak up if they disagree? Are they listened to? Are they creators and not just consumers of information and decisions?)
2. Learning Culture (are mistakes seen as inevitable and necessary? Can people share their mistakes and knowledge?)
3. Motivation & Self-Efficacy (do people believe they can overcome unexpected difficulties? Do they see the purpose in their work?)
4. Support & Belonging (do people believe that they belong on the team for who they are, over and above simply what they produce? Do they reach out for help, and in turn do others reach out to them?)

Interesting sidenote: the elements of thriving are more to do with psychology than technical expertise or level of experience. Most sports teams have a dedicated psychologist, but when was the last time you saw a team of developers with one?

The factors of thriving shouldn’t be controversial. Still, without a definition of success that considers developer thriving and resilience, it’s not hard to see how they can be thrown out or tactically skirted around when push comes to shove (as it does, all the time, every day).

For engineering managers, all of this has an implication on where we should be looking if a team is failing to deliver.

Instead of reaching immediately for the ‘easy’ metrics and blaming people for not contributing enough in the way of PRs, lines of code (ick), features etc., we ought to be asking these sorts of questions:

• Is the project timeline appropriate?
• Are there unclear or badly defined project requirements?
• Does the team lack the right technical skillsets for the project?
• Is there dysfunctional communication between teams or within the team?
• Are developers burnt out?
• Is there a lack of available technological resources?

Good managers blame processes, not people. Sometimes it is the right move to temporarily call a halt on a project in order to address areas, such as the above, that are hurting developer thriving. Grinding through regardless is not a sustainable long-term strategy, since by hurting developer thriving you’re hurting resilient productivity.

Developer thriving also relies on people feeling that their work is seen and valued at the right level. This means that their manager and teammates don’t only see a simplified metric such as number of PRs completed, but are able to see how things were done in a way that gives an opportunity to provide meaningful praise or critique, and/or provide a learning experience through the suggestion of other, equally valid approaches. In short — it’s a great and motivating thing to have one’s effort appreciated.

Note: this doesn’t mean seeing everything a person produces… 1. Ain’t nobody got time for that and 2. No-one wants to feel watched 24/7.

I really liked Cat’s talk, not only because it rang so true but also because it was backed by a significant body of research. These metrics for resilient productivity and developer thriving have come from the statistical analysis of in-depth interviews with 1282 developers and 465 engineering managers across a wide range of industries and many different sizes of teams. Her insights also tally with the wider body of evidence that has repeatedly demonstrated the impact of culture and organisation on developer productivity.

Plus, at the end of the day, there’s nothing like the endorphin hit that a lil bit of thrivin’ gets ya.