One counter to this over 20 years in this game is there are plenty of people who confuse "having heated discussions" with being high functioning.
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.
> 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.
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.
> 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.
this is a good idea, as it allows those who aren't the "great orators of their time" some space to breath and think. Not everyone is a fast on their feet debater. Lots of quieter people have great ideas, but don't speak up because they don't have the best debate skills, but are great with making a bullet list of facts and data to back up their side, but are nervous in confrontations during a meeting.
That's excellent - many organizations write down very little, and certainly not meeting minutes / decision details, which only makes this problem worse.
> 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.
It's hard to do but my current boss is pretty good at that. It can require an amount of forced agreeableness and sometimes sidebars to get each party to fully spell out their line of thinking so the strongest voice doesn't simply win.
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.
> Prima donna developers who publicly call managers/teammates stupid in meetings ... (snip) ... telling newer team members to get a new job if they don't like how things are done.
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.
I ran a pretty high-functioning team of experienced C++ image processing pipeline programmers, for 25 years. We were part of a much larger, international (and interdisciplinary) team. We worked for one of the most renowned imaging companies in the world.
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.
25 years is a long time, I'm intrigued. Looking back, can you single out any specific rules, workflows or cultural reasons which made this possible? Also, how much fluctuation in team members did you experience?
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.
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).
Do you think that craftmanship and longevity, in terms of keeping these people on board, go hand-in-hand?
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.
> Do you think that craftmanship and longevity, in terms of keeping these people on board, go hand-in-hand?
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.
Thanks, that was insightful. Vision and mission can be a hard sell, depending on the company. Having some decades of engineering tradition certainly helps with that.
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.
Companies that show little loyalty should expect little loyalty. It seems to be a general business culture truth right now that loyalty is something that will be exploited rather than lauded. That's just my experience as someone who has been in 3 consecutive layoffs over the last few years and became a bit jaded/bitter before my current gig.
I think this article confuses an absence of "heated arguments" with a lack of constructive, critical discussions. I've found that in mature teams with high trust, people don't have heated arguments precisely because they are not afraid that their voices will be ignored. There is no need to become heated because you trust that the other people on the team will hear you out and consider your viewpoint.
>code that nobody questions usually crashes in production
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.
> …in mature teams with high trust, people don’t have heated arguments…
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 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.
From being in a company with places across all of Europe, I've also found that "heated" means very different things in different places. Like, I'm exaggerating a little bit, but the calm discussion where to get dinner in Spain can be a lot more energetic than a very heated discussion about a strategic problem between some Brits and Germans.
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.
Interesting take, and most probably you are right. But this requires at least two people with a above-the-average emotional intelligence. And in our trade, in my opinion and experience, it's not easy to find people that excel in both emotional and practical problem solving intelligences. So, having a profound technical discussion in a team without heating it up at least a bit, it's difficult. Now, it can heat up and then it can be like nothing really happened, because as time passes and people can reflect on it, they soon realize it was just a technical discussion; but in the heat of the moment if you have the ego strong enough to defend your position, most persons will heat up as well.
I find the heated discussions happen in teams where things actually matter. If arguments never get heated, its because everyone knows it doesn't matter in the first place and you can just get by with silently nodding.
Had multiple girlfriends for whom having regular fights was an essential part of a "healthy" relationship, e.g. told me clearly the relationship was dead if we didn't have any conflicts. I guess that's the same mindset ..
Ok, lets go with this, because empathy is hard, and it seems that most here have not experienced working on complex projects. I've personally experienced this.
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
Have you considered you internalised and normalised working in environments that are messed up 5 steps before the final problem? Crunch, angry managers, thinking "(they're) waiting for us to get our shit together" when planning/communication failed at higher level, "boss is begging us to submit the data" which has likely no impact on your speed of work, "and several hundred hours are now needing to be spent figuring out" is a thing that you have a process for and you know it can happen so the risk should be accounted for ahead of time and not surprising, "why they fucked up and why we suck" when things you know can fail do fail, "the ratings team now needs to go overtime" means more planning failure, etc.
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.
Nothing you describe is normal, healthy, worthy of emulation, or good.
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.
As the other poster said, this sounds more like a toxic work environment than like an environment were constructive (those are rarely heated) discussions take place that will actually improve a project. I mean maybe everyone was so busy shouting at each other that they forgot to actually properly plan and risk manage the project?
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?
Sounds like a LOT of wishful thinking. It doesn’t matter what your boss wants. They were living in a fantasy land where they imagined the project going differently.
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.
Edit: I noticed this comment was rather controversial and reread the article. The author is actually saying most people misunderstand psychological safety to be an environment where people don’t disagree. Their understanding of psychological safety however is correct. Not sure why the framing flipped my understanding in the first read.
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.
> Ideas get challenged based on what they are, not who said them
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.
> 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.
Its useful to identify what sort of team you are on. I've definitely been on teams that valued what I'd call "silent consensus" which really meant a small group had already met and made whatever self serving decision and when they met with the whole team to have a "first discussion" they expected zero extra inputs.
Sometimes the fastest way to win is to completely disengage. If these people are actually wrong all of the time, they will spiral even faster without your intervention.
Alternatively, use your opponent's momentum against them. Reorient your thinking and accelerate the destruction of their bad ideas by encouraging them.
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
Keep your head down or bail. Being right doesn't matter if you aren't calling the shots; you can't cash in those I-told-you-so points for anything.
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.
Well, if everyone you are encountering on the street is driving in the wrong direction, the probability that you are the wrong-way driver might be slightly increased. ;)
Once I was in a team that had built for themselves a bubble of happiness, because the CTO / second founder of the company was a toxic scumbag. At the time I thought it was the best team ever but the bubble was cracked in a very ugly way, revealing the horrific situation.
The truth on this is even simpler: the absence of a clear decision making hierarchy in big A "Agile" processes dooms every non operational task to at best mediocre outcomes. *
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.
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.
Sure, but I know what it means. Anecdotally, I've found for a lot of these borrowed phrases, unless the people I'm talking to are already familiar with family, I still have to explain what I'm talking about and how to apply it if I want to be understood.
I know, feel the same about codes of conduct. People who need those kinds of rules are the least likely to follow and most likely to weaponize them.
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?
One counter to this over 20 years in this game is there are plenty of people who confuse "having heated discussions" with being high functioning.
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.
> 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.
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.
> 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.
this is a good idea, as it allows those who aren't the "great orators of their time" some space to breath and think. Not everyone is a fast on their feet debater. Lots of quieter people have great ideas, but don't speak up because they don't have the best debate skills, but are great with making a bullet list of facts and data to back up their side, but are nervous in confrontations during a meeting.
Yeah there's not a huge overlap of great talkers and great thinkers, thats for sure
That's excellent - many organizations write down very little, and certainly not meeting minutes / decision details, which only makes this problem worse.
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.
It's hard to do but my current boss is pretty good at that. It can require an amount of forced agreeableness and sometimes sidebars to get each party to fully spell out their line of thinking so the strongest voice doesn't simply win.
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.
> Prima donna developers who publicly call managers/teammates stupid in meetings ... (snip) ... telling newer team members to get a new job if they don't like how things are done.
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.
I ran a pretty high-functioning team of experienced C++ image processing pipeline programmers, for 25 years. We were part of a much larger, international (and interdisciplinary) team. We worked for one of the most renowned imaging companies in the world.
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.
25 years is a long time, I'm intrigued. Looking back, can you single out any specific rules, workflows or cultural reasons which made this possible? Also, how much fluctuation in team members did you experience?
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.
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).
Do you think that craftmanship and longevity, in terms of keeping these people on board, go hand-in-hand?
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.
> Do you think that craftmanship and longevity, in terms of keeping these people on board, go hand-in-hand?
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.
Thanks, that was insightful. Vision and mission can be a hard sell, depending on the company. Having some decades of engineering tradition certainly helps with that.
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.
Companies that show little loyalty should expect little loyalty. It seems to be a general business culture truth right now that loyalty is something that will be exploited rather than lauded. That's just my experience as someone who has been in 3 consecutive layoffs over the last few years and became a bit jaded/bitter before my current gig.
You have now read this in Werner Herzogs voice, and from now on every divadev sounds like kinski to you.
I think this article confuses an absence of "heated arguments" with a lack of constructive, critical discussions. I've found that in mature teams with high trust, people don't have heated arguments precisely because they are not afraid that their voices will be ignored. There is no need to become heated because you trust that the other people on the team will hear you out and consider your viewpoint.
>code that nobody questions usually crashes in production
I don't understand what that means.
> I don't understand what that means.
Probably "code that nobody critiques will fail in production". That's not always true I guess.
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.
> …in mature teams with high trust, people don’t have heated arguments…
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 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 confuses an absence of "heated arguments" with a lack of constructive, critical discussions.
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."
>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.
From being in a company with places across all of Europe, I've also found that "heated" means very different things in different places. Like, I'm exaggerating a little bit, but the calm discussion where to get dinner in Spain can be a lot more energetic than a very heated discussion about a strategic problem between some Brits and Germans.
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.
Interesting take, and most probably you are right. But this requires at least two people with a above-the-average emotional intelligence. And in our trade, in my opinion and experience, it's not easy to find people that excel in both emotional and practical problem solving intelligences. So, having a profound technical discussion in a team without heating it up at least a bit, it's difficult. Now, it can heat up and then it can be like nothing really happened, because as time passes and people can reflect on it, they soon realize it was just a technical discussion; but in the heat of the moment if you have the ego strong enough to defend your position, most persons will heat up as well.
I find the heated discussions happen in teams where things actually matter. If arguments never get heated, its because everyone knows it doesn't matter in the first place and you can just get by with silently nodding.
The only two options you mention are "getting heated" and "silently nodding." Healthy teams exist between these two extremes.
Maybe, but if you're never getting heated, the work doesn't matter in the first place.
I genuinely don't know how to respond to that. The idea of connecting anger to the relevancy of one's work seems so strange to me.
Had multiple girlfriends for whom having regular fights was an essential part of a "healthy" relationship, e.g. told me clearly the relationship was dead if we didn't have any conflicts. I guess that's the same mindset ..
Ok, lets go with this, because empathy is hard, and it seems that most here have not experienced working on complex projects. I've personally experienced this.
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
Have you considered you internalised and normalised working in environments that are messed up 5 steps before the final problem? Crunch, angry managers, thinking "(they're) waiting for us to get our shit together" when planning/communication failed at higher level, "boss is begging us to submit the data" which has likely no impact on your speed of work, "and several hundred hours are now needing to be spent figuring out" is a thing that you have a process for and you know it can happen so the risk should be accounted for ahead of time and not surprising, "why they fucked up and why we suck" when things you know can fail do fail, "the ratings team now needs to go overtime" means more planning failure, etc.
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.
Nothing you describe is normal, healthy, worthy of emulation, or good.
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 seems that most here have not experienced working on complex projects
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.
As the other poster said, this sounds more like a toxic work environment than like an environment were constructive (those are rarely heated) discussions take place that will actually improve a project. I mean maybe everyone was so busy shouting at each other that they forgot to actually properly plan and risk manage the project?
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?
Sounds like a LOT of wishful thinking. It doesn’t matter what your boss wants. They were living in a fantasy land where they imagined the project going differently.
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.
> I don't understand what that means.
Shit code or architecture that other devs didn't call out.
Edit: I noticed this comment was rather controversial and reread the article. The author is actually saying most people misunderstand psychological safety to be an environment where people don’t disagree. Their understanding of psychological safety however is correct. Not sure why the framing flipped my understanding in the first read.
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.
Exactly - the teams where everyone agrees are generally the least safe.. thats why everyone just nods along to every word from the boss.
> Ideas get challenged based on what they are, not who said them
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.
[1] https://news.ycombinator.com/item?id=43652024
> 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.
Its useful to identify what sort of team you are on. I've definitely been on teams that valued what I'd call "silent consensus" which really meant a small group had already met and made whatever self serving decision and when they met with the whole team to have a "first discussion" they expected zero extra inputs.
One learns more from friendly critics than from uncritical friends.
This is true in any relationship. The goal is not “winning”, but making sure everyone’s needs are met.
How do people cope in teams where some or even most members are vocal but actually always completely wrong and you’re the only one seeing it?
Sometimes the fastest way to win is to completely disengage. If these people are actually wrong all of the time, they will spiral even faster without your intervention.
Alternatively, use your opponent's momentum against them. Reorient your thinking and accelerate the destruction of their bad ideas by encouraging them.
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
Keep your head down or bail. Being right doesn't matter if you aren't calling the shots; you can't cash in those I-told-you-so points for anything.
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.
Well, if everyone you are encountering on the street is driving in the wrong direction, the probability that you are the wrong-way driver might be slightly increased. ;)
Once I was in a team that had built for themselves a bubble of happiness, because the CTO / second founder of the company was a toxic scumbag. At the time I thought it was the best team ever but the bubble was cracked in a very ugly way, revealing the horrific situation.
The truth on this is even simpler: the absence of a clear decision making hierarchy in big A "Agile" processes dooms every non operational task to at best mediocre outcomes. *
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.
100%
"Psychological safety" sounds awfully creepy.
It's Therapy Speak for "pitching ideas and asking questions is encouraged, you will not be reamed or looked down on if some of those are bad."
This is a good idea.
Unfortunately, using therapist jargon in other contexts sounds very strange, shibolethy and throws people off.
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.
Sure, but I know what it means. Anecdotally, I've found for a lot of these borrowed phrases, unless the people I'm talking to are already familiar with family, I still have to explain what I'm talking about and how to apply it if I want to be understood.
And indeed, much irony.
I know, feel the same about codes of conduct. People who need those kinds of rules are the least likely to follow and most likely to weaponize them.
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?
The kind of thing an abuser would want to manage. Or those with good intentions. Hard to say!
I'm just here to do good stuff and not starve, man. Y'all doing too much.