3 Comments

This essay made me wonder of normalization of deviance in groups of people. There are certainly the effects of bad examples (learning to rubber stamping code, or closing unresolved tickets), but these are somewhat easy to detect and mitigate (at least as a manager who is paying attention).

I find that a tricker to situation to detect/diagnose is learned helplessness (and/or weaponized incompetence), because things are functioning on the surface: one person picks up the slack for another person. Again, even if you are paying attention as a manager, this isn’t always easy to spot: nothing is broken, nobody is complaining. Vacations taken by the person who “carries the water” can bring some light to the problem, but it takes a coincidence of vacation and an incident to shine the light at the problem at the team scale.

What really takes a lot of attention and luck to detect is when a whole team/org picks up the slack for another. Whole teams don’t go on extended vacations at once and the situation can be perpetuated for a very long time. Sometimes there is churn and burn out that can be a hint, but sometimes the team that picks up the slack just figures out how to be more effective or add automations to help things. At the same time, the dysfunctional team continues at shirk responsibility. More over, those teams start to invent unnecessary things to justify their existence.

I have seen the above as a problem between different software teams, and I find it hard to mitigate. One of the accepted tensions in the industry of this type that seems similar is the tension between software engineers and production engineers (or site reliability engineers). What is your experience with this? Have you seen it? How do you deal with it?

Expand full comment

Here's a 2 min audio version of "Normalization of deviance" from Wednesday Wisdom converted using recast app.

https://app.letsrecast.ai/r/bb5cb9e1-4331-42b9-b949-7a49eb280db1

Expand full comment

Stop calling me Shirley!

Expand full comment