That is - I've been on lots of low functioning teams riven with conflict. Prima donna developers who publicly call managers/teammates stupid in meetings. Managers giving negative feedback in public instead of in private. Stubborn veteran team members telling newer team members to get a new job if they don't like how things are done.
One pattern I've seen in lower functioning teams with lots of conflict is some members being very well spoken, typically more classically trained like a philosophy background, probably a past debate club type kid. "Strong opinions, loosely held" type behavior where bad ideas were passionately argued by the more eloquent & aggressive team member until everyone else was exhausted and just let it run.
The kind of guys that would steamroll the rest of the team as a bunch of idiots for not agreeing with him, but flip to a charismatic "ah good point" when incontrovertible proof of their idea not being correct was presented. The problem is you can't provide incontrovertible proof in real time in most cases, and lots of managers confuse their passion/certitude for correctness.
So high functioning teams can have heated arguments & difficult people, but heated arguments do not in themselves lead to high functioning teams.
> The kind of guys that would steamroll the rest of the team as a bunch of idiots for not agreeing with him, but flip to a charismatic "ah good point" when incontrovertible proof of their idea not being correct was presented. The problem is you can't provide incontrovertible proof in real time in most cases, and lots of managers confuse their passion/certitude for correctness.
The problem is not that incontrovertible proof cannot be provided real time. Yielding evidence from complex, esoteric systems is always difficult and time-consuming.
The problem is the well-spoken people in the above example are not well-listening. Hearing a poorly-worded argument whose conceptual outlines might be worth considering is an important skill. Ignoring an argument because it is not eloquently delivered is hubris.
Because such people do not listen well, they cannot claim to have “Strong opinions, loosely held”. Requiring hard-to-yield evidence before changing one’s mind is “Strong opinions, tightly held”.
In the end, heated arguments are usually an indicator of dysfunction, even in high functioning teams. Teams are usually better off having honest, dispassionate debate.
This is why we've started to write down larger decisions, the reasons and spots of uncertainty for these decisions in a central, public place. I'm jokingly referring to this as our growing constitution of tech.
I think this is right, because some of these decisions are not entirely comfortable, but a lot of bright people have thought about this over time and this compromise is what we figured is the most effective and workable one.
I'm entirely willing to up-end one of these decisions, but only if something strong comes up that hasn't been discussed in the past many times. But, our reasoning is here, and everyone can take all time they need to make a case why it's wrong, or some case needs further consideration and detail.
Dispassionate debate is a mark of grown ups, and we work with a lot of children in this industry.
Most of the heated discussions that I saw in low performing teams was because of that specific aspect.
Being more specific: if we have 3 people with different levels of knowledge, most of the time if the person that has more in depth knowledge and sense of craft will take the heated position.
A high-functioning team is going to have at least one person who does this. For a perpetually high functioning team this is going to be second nature.
I think the author covers that point to some extent:
> The focus stays on the problem: “This approach might not scale” instead of “Your idea sucks.”
As soon as you deviate from that focus, the discussion becomes toxic.
Some of the folks we dealt with, were the top people in their field, and not everyone was especially good at getting along with others.
Everyone thought they had The Answer, and everyone was totally passionate about doing their best work.
Needless to say, we often had heated discussions.
For the most part, we did excellent work (not always, but team infighting was not the reason for issues).
My personal experience, is that creative, passionate, high-talent teams can be pretty messy, and managing them, is tricky.
I'm currently managing multiple teams, some of which are experiencing challenges with clashes between top talent. I'm sure there is no magical bullet, but still very interested in anecdotal data on this.
When they finally wrapped up our team, the person with the least tenure, had been there a decade.
Keeping people for a long time, is a big topic, on its own.
Also, everyone believed in The Mission. Inspiring talented, smart people, is not easy. It requires a great deal of Integrity and Humility, on the part of the management. That’s rare as hen’s teeth, these days.
It’s an old-fashioned Japanese “craftsman” company, with a 100-year-plus history of making some of the best optical equipment in the world, so there was a lot of inspiration (and very difficult minds to change, which could be a challenge).
>code that nobody questions usually crashes in production
I don't understand what that means.
Probably "code that nobody critiques will fail in production". That's not always true I guess.
But usually the severity was more correlated with a lack of comments on the tests. Giant holes in test cases meant giant bugs. So don’t call a PR ready to land until you’ve gotten a few substantive critiques. Because the absence of evidence is not evidence of absence.
For the bugs I introduced (I am highly bug-averse) it was either zero comments on tests, or bugs introduced by the CR process - changes I was coerced into making that I felt were wrong. And I can’t say which sort of subconscious resistance was at work there. Self sabotage for making changes I don’t want to, or my sixth sense for robust code telling me the suggestion is an antipattern. Probably both.
What I learned from that last, which I confirmed in subsequent years, was that as a team you should only tolerate major pushback on a CR/PR at the beginning of the review process. Anyone who jumps in late with Needs Work demands, especially after a round of feedback changes has already landed, has lost their right to participate in the review. Because as a PR drags on, everyone gets tired of looking at it and has a less critical eye for spotting bugs that have been introduced by committee. It quickly becomes better odds that the original bugs the early reviewers did not catch are less dangerous than the ones that will be introduced by work-hardening the PR.
It’s the same mechanic that makes pushing code or a deployment after 4pm a bad idea. Confirmation bias is greatly amplified by a desire to be somewhere else.
This dynamic flourishes when the stakes and/or uncertainty are low enough.
High stakes and high uncertainty means everyone’s pushing their intuition and their reasoning as far as they can. They’re at their limit of what can be communicated efficiently. This results in an uneven distribution of communication bandwidth across the edges in the team network. Accountability induces leadership and competing views are ascendant and in decline.
I think it’s reasonable to wonder that, if the temperature never rises about room temperature, the team might not be fully challenging itself.
I suspect this only seems reasonable if you've never experienced a healthy work environment. I probably would have agreed with you when I was in my twenties, working at a startup with another bunch of twenty-year-old guys and a CEO who was in over his head. It wasn't unusual for the whole company to yell at each other in a meeting room. The stakes seemed high then, but they seem ridiculous in hindsight, as does my own behavior.
Thirty years later, the stakes are much higher, and the temperate is much lower. This is precisely because we can't afford this behavior, and we can't afford to deal with people who can't control themselves and behave professionally in high-pressure situations.
Doesn't the article refute exactly this point of view? In "The hidden cost of “nice” teams" section:
"Those teams weren’t actually harmonious—they were conflict-avoidant. The disagreements still existed; they just went underground."
In my experience, this is not true because, in high-trust teams, there is "harmonious conflict." People offer criticism without getting heated.
Getting heated often results from a strong opinion combined with a lack of faith that other people are genuinely considering your opinion. People who get heated feel they have to be forceful to convince others to listen. Knowing your opinion will be hard and carefully considered, you don't need to get heated.
A toxic consensus culture usually does not even allow for a serious, critical discussion, but dissenters are just ignored or verbally patted on the head.
Shit code or architecture that other devs didn't call out.
This article completely misunderstand psychological safety even after including the definition. “Nice” teams are not psychologically safe. If everyone is nodding along they do not feel safe.
Conflict and safety are not at odds with each other. The whole point of psychological safety is that everyone feels safe enough to get into productive conflict.
Not all conflict or agreement is productive. The point of the work around psychological safety is to build a team where people agree and disagree willingly because they feel safe to do so.
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 ?
It's not just that single quote, the whole article felt like a Don Quixote battling the windmills that keep silencing the wise engineers bearing their valid criticism as a spear. Or perhaps it was aimed at dictator types of figures who reign fear on their troups ? But then, will they even listen to this author ?
> My best engineering teams were never the quiet ones—they were the ones where technical debates got spirited, where different perspectives were welcomed, and where we could disagree while still respecting each other.
Who's raising their fist shouting that respectful disagreement with different perspectives has no place in their team ?
--
The previous piece discussed here [1] was definitely more interesting and bringing more to the table as a thought piece.
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)"?
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.
Alternatively, use your opponent's momentum against them. Reorient your thinking and accelerate the destruction of their bad ideas by encouraging them.
Sometimes a project gets funded by someone who wants the team to look and act a certain way and actual productivity doesn't even factor in. You're not 'right' if you've fundamentally misunderstood what you're doing there in the first place. Either take their money and play along or leave. That's the call you can make.
One of the key benefits of hierarchical decision making is that people have the opportunity to privately challenge opinions, which can lead to radical levelling up of everyone involved. Since the introduction of infantile nonsense like "sprint planning poker" everything descends to being an argument, facepalming defeatism, or fake niceness while everyone hopes everyone else does the bare minimum to keep things going while we all smile about it.
* My more managerial friends and colleagues claim this is a feature, not a bug, in that they prefer predictable mediocrity over unpredictable success.
This is a good idea.
Unfortunately, using therapist jargon in other contexts sounds very strange, shibolethy and throws people off.
If so, what would you say in its place? It’s hard to write an article about a concept if you have to say "pitching ideas and asking questions is encouraged, you will not be reamed or looked down on if some of those are bad" every paragraph.
The irony of tech people complaining about jargon.
But I think we can agree it's a good thing to feel assured that having different opinions and occasionally being wrong is not going to be a problem, that this is something that could potentially affect the team in positive ways?
I'm just here to do good stuff and not starve, man. Y'all doing too much.
