[bryanlarsen]

A well functioning team makes all decisions by consensus, so there are no deadlocks.

There are certainly disagreements, but they are hashed out in a timely fashion in well functioning teams. That doesn't mean necessarily that everybody completely agrees with everything, but it does mean that members recognize when to defer rather than stall.

If you have deadlocks, it's not a well functioning team.

[vidarh]

Great. But we live in reality where lots of teams are not well functioning some or all of the time, and we still need to get things done even when we don't have the time, resources or influence to fix the team composition then and there.

EDIT: I'd also argue that in most well functioning team few decisions needs to be taken by the team, because the team members know their role well enough and trusts the others to do the same that everyone is empowered to take decisions. Unfortunately again, we live in the real world where decision making is often needed exactly because a lot of the time there are team members we can't let run rampant and make their own decisions. Or have too much influence.

[crdoconnor]

>Great. But we live in reality where lots of teams are not well functioning some or all of the time

Managers abusing their power causes way more dysfunction than a lack of authority ever does.

>Unfortunately again, we live in the real world where decision making is often needed exactly because a lot of the time there are team members we can't let run rampant and make their own decisions.

That isn't what managing by consensus means. In the real world bad eggs don't "run rampant", they are reined in by peer pressure, and poor developers very often recognize that they are poor developers (except when they are designated as leaders, in which case they usually do 'run rampant').

[vidarh]

> In the real world bad eggs don't "run rampant", they are reined in by peer pressure, and poor developers very often recognize that they are poor developers

I wish I lived in your world, but clearly we live in very different worlds.

[crdoconnor]

Which developer ran rampant in your world who wasn't either in authority or favored by somebody who was?

[crpatino]

> That isn't what managing by consensus means. In the real world bad eggs don't "run rampant", they are reined in by peer pressure, and poor developers very often recognize that they are poor developers

This does not conform to my experience at all. Once you have assembled a team of solid B+ players (not great guys, but get the job done more often than not) they will laser focus in the sole B- guy in the team and designate him the "village idiot". Then, every questionable practice that is marginially better than the most visible shortcomings of the village idiot will be fair play.

The thing is, every B+ player has defects, but everyone is defective in their own particular way. But since the effects in the project are cumulative, and nobody feels empowered enough to call other people on their shortcomings they will end up building a C- product that all love to hate.

Bring in an A+ team lead or two, empower them to enforce high standards on everybody, and every other team member will either leave or grow into their A- full potential.

[crdoconnor]

>nobody feels empowered enough to call other people on their shortcomings

I've done exactly that as a non-team lead and a team lead. It doesn't require authority it just requires tact.

>Bring in an A+ team lead

Not that simple. Businesses that bring in "A+" leads often misrecognize confidence and bluster for ability and bring in overconfident B- leads who fuck up everything, including the work of developers beneath them who are better than them.

[titzer]

Of the systems I have worked on, I cannot imagine any of them working well having been designed by consensus, no matter how skilled the team members. A techlead role is that of an architect; come up with the overall design to make it logical, consistent, coherent. You definitely wouldn't want a programming language that was designed by a committee, or would you?

[bryanlarsen]

My favourite programming language, Rust, is designed by committee.

[zaphar]

According to the Rust team page Rust has not just one "Tech Lead" but 6 who have the responsibility of

    overall direction of the project, subteam leadership, 
    cross-cutting concerns

Which to means if a deadlock happens on a subteam these six will be breaking it.

[steveklabnik]

Yet in general, consensus is the guiding mode of operation for all teams. The core team has never overridden a team's decision against their will, and while such a thing is technically possible, it would be considered a catastrophic event, I'd imagine.

(Source: I am one of those 8 (not six))

[clairity]

> A well functioning team makes all decisions by consensus, so there are no deadlocks.

no, a well-functioning team empowers and trusts each member to make good decisions independently. those teams also foster psychological safety so that team members don't feel timid for fear of making a mistake. often there is an orchestrator who guides the team by making the more strategic decisions.

a good basketball team exemplifies this. on the san antonio spurs, tony parker, their point guard, makes strategic decisions but every player makes many independent decisions that help the team win together. you can tell they trust each others' decisions and they support esch other through mistakes.

[zaphar]

By your definition no team is well-functioning all the time. There will always be a point where there is a deadlock. And if no one on the team has been empowered by the organization to break that deadlock then it will fall to some one who is not familiar with the problem and lacks context. This is fundamental to working on a team and it is why almost universally every team in any context has a "leader".

While it's true that for the most part a well functioning team will hash them out without a Tech Lead having to break a deadlock. It's also true that a deadlock is nearly inevitable at some time in the teams future.

[bryanlarsen]

> There will always be a point where there is a deadlock.

I've been on teams where this has never been the case. There are temporary deadlocks and disagreements, sure. But they always resolve via consensus somehow. Good leadership, horse trading, more investigation, experiments. Heck I even remember an incident where we resolved a disagreement with a coin flip. We realized we were bike shedding and just ended it.

The point is that if you resolve a deadlock but after the deadlock there is still somebody that is dissatisfied with the outcome, you don't have a well functioning team.

[zaphar]

Anecdotes are always a terrible way to prove a point. I suspect that your examples are probably the kind that prove the rule. You may have been on teams where deadlocks didn't happen for your tenure. But did they happen before or after your tenure? A tech lead is like health insurance. It's not there for when you aren't sick. It's there for when you are. and it's usually too late to get it when you are already sick.

[douche]

If all decisions have to be made by consensus, you're probably not making optimal decisions.