Developer productivity is so August 2023. Enter Developer Counter-Productivity. Productive developers spend more of their time and energy on high-leverage activities. Counter-productive developers spend more time and energy on low or negative-leverage activities. This skew is often only marginally within their control (and sometimes completely out of their control). It explains why the same developers in a different environment can be so much more (or less) productive.
I'm always amazed by how you can articulate these kind of fuzzy, abstract stuff into clear and concrete writing. Somehow it felt you can see into my brain then noting down the things flying around 😆
Most of those show that hitting the "sweet spot" of high productivity is a challenge: Most of them show that too little or too much of just about anything is a waste. But how does one find that optimal "middle ground"? How does one know if what we're doing now is "too little" or "too much" of something?
That's a heck of a list. One observation though - it's surprising to me that leaders tend to zero in on developer productivity only - as if this is the only function in the organisation that more needs to be squeezed out of. With a few exceptions, this list could apply to any role in an organisation. We all suffer from very similar low or negative-leverage activities.
This is an excellent break down of counter-productivity and I love the example quotes. Thank you for making this!
My top highlights are under: non-value-adding administrative and compliance work, ineffective planning, consensus seeking and decision-making drag, workarounds, inefficient onboarding, and tooling challenges.
I think this is a must-read for all managers of software-related groups. It also could imply an occasional retro to monitor the status of each — so upper management understands the counter-productivity.
“The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”
I'm always amazed by how you can articulate these kind of fuzzy, abstract stuff into clear and concrete writing. Somehow it felt you can see into my brain then noting down the things flying around 😆
Most of those show that hitting the "sweet spot" of high productivity is a challenge: Most of them show that too little or too much of just about anything is a waste. But how does one find that optimal "middle ground"? How does one know if what we're doing now is "too little" or "too much" of something?
Damn. The modern version of the Simple Sabotage Field Manual.
I both love and hate it. must be a good one.
It's a really complete list. Wonder if a subsequent post could focus on some solutions to reduce these problems.
That's a heck of a list. One observation though - it's surprising to me that leaders tend to zero in on developer productivity only - as if this is the only function in the organisation that more needs to be squeezed out of. With a few exceptions, this list could apply to any role in an organisation. We all suffer from very similar low or negative-leverage activities.
Wow.
Thank you.
Love the list ... I work in a large, heavily matrixed software organization and these resonated so much it hurts.
This is an excellent break down of counter-productivity and I love the example quotes. Thank you for making this!
My top highlights are under: non-value-adding administrative and compliance work, ineffective planning, consensus seeking and decision-making drag, workarounds, inefficient onboarding, and tooling challenges.
I think this is a must-read for all managers of software-related groups. It also could imply an occasional retro to monitor the status of each — so upper management understands the counter-productivity.
This topic has gotten significant attention over the past ~30 years. Many studies, papers, etc.
https://resources.sei.cmu.edu/library/author.cfm?authorID=4473
https://en.m.wikipedia.org/wiki/Personal_software_process
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5283
—
“The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”
Fred Brooks
Would Team Size (or something connected to ”communciation costs”) count?
Should open industry eyes or may not for blind