Why Your 'Harmonious' Team Is Failing

> The problem is not that incontrovertible proof cannot be provided real time. Yielding evidence from complex, esoteric systems is always difficult and time-consuming.

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.

Agreed and in my experience most people claiming "strong opinions, loosely held" are actually "strong ideas, tightly held". Probably 9:1.

Dispassionate debate is a mark of grown ups, and we work with a lot of children in this industry.

> The problem is not that incontrovertible proof cannot be provided real time. Yielding evidence from complex, esoteric systems is always difficult and time-consuming.

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.

Yes, someone who truly wants greatness should be able to hear a poorly thought our argument, cognitively question the counter party to help them articulate exactly what they are thinking, or even articulate it better themself. Then you can weigh and measure competing arguments.

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.

Well, the biggest “secret,” was keeping people on board, for a long time. It was almost impossible to hire folks that could “hit the ground running,” as the tech was very proprietary, so investment in training was a big deal.

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).

On the first team where we did code reviews, I found in RCAs for the bad bugs that snuck in that there was a dearth of comments on the CR that introduced it.

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.

>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.

>Those teams weren’t actually harmonious—they were conflict-avoidant.

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.

In my eyes a critical discussion does not mean that the disagreements went underground. If the team is doing its best to resolve the issue, what else are you going to do? I certainly do not believe that yelling at each other is helpful.

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.

› 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.

Sometimes it blossoms into a shitstorm which can be used to justify excessive hiring where you get diluted even further. Never underestimate the dysfunction of Fortune500

It’s not so jargony, is it? You’ve heard the word psychology before, and everybody knows what safety is. You can’t handle the two concepts applied together?

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.