> Is anyone here deeply moved by how this argument is insightful and bring an angle to team building that wouldn't have been obvious otherwise ?
You'd think it's basic. But then you can read up on the history of checklists and how lives were saved by empowering nurses to point out that surgeons forgot some step.
Or Toyota empowering any worker to stop the production line if they suspect a defect.
Or any number of "we should treat other teams and people as worth listening to instead of dismissing them" which in IT seems like a really common problem between dev and test.
> But then, will they even listen to this author ?
People causing the issue will not. But their teams may learn that this is not normal and start enacting change themselves. Or at least do things differently in the future in their own projects.
> Who's raising their fist shouting that respectful disagreement with different perspectives has no place in their team ?
Nobody says this directly. (Just like almost nobody says "I discriminate against ...") But listen to how people internally refer to other teams, and ask yourself if they would consider/accept the outside perspective without a needless fight. Have you already met people who will in conversations say "those idiots in (other team)"?
› history of checklists and how lives were saved by empowering nurses to point out that surgeons forgot some step
It goes a lot beyond disagreeing at meetings though. There's a ton of research on the social dynamics leading to erroneous decisions, mostly steaming from too much power concentrated on one side.
On the nurse example, I assume we're talking about instruments left inside the patient's body for instance ? These kind of issues are not just solved with prep talking nurses into voicing their concerns, and include reworking procedures, building "rituals" and checklists as you mention. Nurses speaking up are part of a whole framework
Same way Toyota didn't just empower their employees, they famously setup a reporting system to give the employees an official path to offer their insights, paired with incentives and rewards.
›those idiots in (other team)"?
In my experience these people will still assert they are respectful, listen to constructive feedback and are open to any pertinent idea. And it might actually be true inside their team or towards a limited set of people.
The issues you point at are real and and sometimes widespread within an org, but it will usually be a lot more nuanced than how it's presented in the article, to the point where the advice doesn't really apply.
It's like asking people to not be racist. Most will balk at that characterization, and actually dealing with the issue will require a lot more workarounds but also properly identifying the exact problematic behavior, in a non cartoon villain way.
You'd think it's basic. But then you can read up on the history of checklists and how lives were saved by empowering nurses to point out that surgeons forgot some step.
Or Toyota empowering any worker to stop the production line if they suspect a defect.
Or any number of "we should treat other teams and people as worth listening to instead of dismissing them" which in IT seems like a really common problem between dev and test.
> But then, will they even listen to this author ?
People causing the issue will not. But their teams may learn that this is not normal and start enacting change themselves. Or at least do things differently in the future in their own projects.
> Who's raising their fist shouting that respectful disagreement with different perspectives has no place in their team ?
Nobody says this directly. (Just like almost nobody says "I discriminate against ...") But listen to how people internally refer to other teams, and ask yourself if they would consider/accept the outside perspective without a needless fight. Have you already met people who will in conversations say "those idiots in (other team)"?