Why Your 'Harmonious' Team Is Failing
terriblesoftware.org
terriblesoftware.org
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.
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.
Often you want to do this simply to map out the min/max risk matrix to either side of a debate, so you can make informed decisions.
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.
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).
Focusing on retention somehow went out of fashion these days, it pains me how often I have to reiterate short vs long term costs. It's not all on the employer side though, loyalty seems a rare attribute today as well... I get many CVs of people who barely ever stayed a year at any one company. Doesn't mean they won't stay with us, but takes some convincing arguments on their side.
As an example, Hamamatsu Photonics has been in the optics field a long time, and is going hard on developing for quantum physics applications. It's refreshing, since pretty much every company in quantum computing is very young, so hasn't had the time to build that craftsman vibe yet. Of course, there are people who've been working on quantum information technologies for a few decades now.
I look forward to seeing this ethos developing in quantum, for sure.
In this case, yes. But that also depends on who you want to retain.
If you want to retain folks that treat their work seriously, and in a craftsmanlike manner, it's important to provide a structure that incubates and rewards that.
We've really reached a point, in tech, where we're in a "death spiral." Companies treat their employees like crap. They may pay them well, but they treat them terribly. This means no loyalty, so the employee feels no issue with leaving as soon as the grass looks greener elsewhere, and the management feels justified in looking at their employees as "disloyal," or even "dangerous." It's a classic negative feedback loop. Money is the only meaningful currency, so people flit around, jacking up their salary, and looking at each company as "just another job."
The people that need to start the change, are CEOs (and shareholders). It's difficult, because "blinking first," seems "wussy," and also, it's pretty much certain that employees would continue to act the way that they do now, for some time, until a new culture gets established. That time, may be enough time to kill the company, as their more rapacious competition eats their lunch.
I was lucky to join an old corporation that had a long-established tradition of retaining top talent. Not sure if you would be able to start a new one, with a similar ethos, these days.
>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.
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."
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.
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.
We have a project to develop a new engine, its teklaover budget, very late, and requires a ton more work and excuses are running thin.
My team is running barebones with 60-70 hour weeks trying to get the ratings done, the test team is waiting on us for the ratings to get their work done and THEIR manager is pissed because they're billing for time on their books waiting for us to get our shit together. There is no more room to delay the tests because another team also needs their project tested and has waited for the test team to free up.
Meanwhile, my bosses boss is pressuring my boss to submit what ratings data we have to get approved to start testing. The test teams boss is begging us to submit the data too so he doesn't have to bill time for being idle on standby.
Tired of fighting, we submit the ratings data and tests starts. And boom 2000 hours into testing the gearbox fails and blows out the back of the engine at 4am. The test facility is now inoperative until cleanup finishes and several hundred hours are now needing to be spent figuring out why a $3 million engine just blew itself up.
The cleanup team is now being paid a fuckton of overtime to clean up the mess, and an army of people are being summoned to provision a new test engine.
The test team now needs to spend extra time writing reports, the ratings team now needs to go overtime to detail why they fucked up and why we suck so much at our jobs, on top of their normal work, and the customer is super fucking pissed.
So yeah, there is no anger if stuff doesn't matter. When stuff does matter, anger happens. It's very easy to sit back and claim "no heated discussions" when it doesn't involve millions of dollars and hundreds of hours of other peoples time when its your team that caused the fuck up
This is toxic BS and mismanagement. It's people not accounting for and communicating risk properly. None of that anger and finger pointing makes this work faster or better. Everything here could happen exactly as it happened, but without anger, if people communicated risks properly and took the failure (which will happen) as part of the process, people would be less stressed about it, and maybe they'd make fewer mistakes too.
Maybe it was correct to progress without better data, or maybe the cost of doing that was too high. Either way, someone should've redone the schedule to match reality, so blocked teams don't get anxious. Then someone should've done the risk/benefit analysis and signed off on the "proceed with testing anyway, we are aware of and accept the risk" path, so nobody talks about fucking up, but concentrates on doing the best they can instead.
I've worked in large cross-company teams on extremely complex products with millions of LOC and thirty-year-old obsolete code handling millions of US$s of bank transactions. I've been in situations where people made mistakes, systems went down, and transactions were lost. I've been in incredibly stressful situations.
Do you know what would have made none of these situations better? Anger.
It sounds to me like lots of discussions should have been had before getting to this point? So sure at the point where you ended up, things get heated because everyone is overworked and frustrated and being pressured from all sides, but that's not really a function of a complex project, but more of a poorly managed/executed one?
The hubris in this sentence is chef's kiss. You have no idea.
> When stuff does matter, anger happens
No, anger is completely unnecessary. It's a poor way to act and communicate, often counter-productive and terrible for morale.
But with less jest - I think we have a very good discussion culture in the team at work. No one on the team is scared to disagree, or to point out that this doesn't seem to go towards a positive direction. It's just not a heated discussion.
At times during these planning sessions, we just sit in silent thought and maybe doodling something in Excalidraw or on paper for a few minutes until someone is like "I need more input on X", or "So I have a rough plan I think?" or "I think there is an issue with that idea", even if it's not clear why - if 2 or 3 people are vaguely not fine with something, it's probably a bad idea. And we've also started to learn each others tells if we're not happy.
Shit code or architecture that other devs didn't call out.
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.
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.
I'm just here to do good stuff and not starve, man. Y'all doing too much.
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.
And indeed, much irony.
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?