11 Comments

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 😆

Expand full comment

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?

Expand full comment

Damn. The modern version of the Simple Sabotage Field Manual.

I both love and hate it. must be a good one.

Expand full comment

It's a really complete list. Wonder if a subsequent post could focus on some solutions to reduce these problems.

Expand full comment

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.

Expand full comment

Wow.

Thank you.

Expand full comment

Love the list ... I work in a large, heavily matrixed software organization and these resonated so much it hurts.

Expand full comment

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.

Expand full comment

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

Expand full comment

Would Team Size (or something connected to ”communciation costs”) count?

Expand full comment

Should open industry eyes or may not for blind

Expand full comment