Case in point - I've been in a situation as detailed toward the end of the article where all the devs on the team were feature leads, except we still had a designated overall lead. Just 4 devs on the team, all of us were very sr (principal or sr. principal devs). But the overall number of stakeholders in the product were probably well over 30 people, so it was still a big coordination effort.
It was for a fairly large legacy enterprise healthcare product ($200M per annum revenue). Each big feature had its own core team with other stakeholders in the company -- usually these meetings would be with a half dozen other people. The main core team for the overall product had about 20 members. Each feature had its own requirements/design documents (usually 30+ pages each). The main requirements/design docs would sorta be like a high-level index linking to these sub documents.
It was a waterfall process of course, and once the designs were mostly there the entire team would work on all the features together. The team lead would assign what people would be working on at any given time, but beyond that the feature leads would break down and delegate the overall work based on who was working on their feature. Typically each feature would be worked on by 2 people at a time and sometimes 3.
The team lead wasn't actually the strongest dev, he just had the best 'leadership skills'. He was the one our manager trusted most and generally spoke to about overall project health and deadlines. He was the one who cleared pathways with other teams/resources (ie. ensured QA was on target to line up an availability window, how many engineers they could provide, etc).
I don't see any points in the article that really argue against having a designated lead, and I think it's always a weird idea that a team lead (note I don't say 'tech' lead) is seen as anything but a manager who still codes. It's not an architect, the strongest dev, etc. It's a person with a best management/leadership skills with perhaps a solid high-level grasp of the domain. In a small team/product yes it can just be just the strongest dev, naturally rising up. But in these situations I've seen usually the key is there are not too many overall stakeholders... say a team of 2-3 devs with less than 10 people involved overall.
If you don't have a dedicated project manager (which I suspect is the case), I'm also curious if you think your team lead is overworked. Maybe your team doesn't need full-time project management so it's more efficient to have this person split their energy between that and engineering, or maybe not and you'd be better off having someone who can specialize in that role.
BTW, I imagine you're mostly keying off the comment "He was the one who cleared pathways with other teams/resources (ie. ensured QA was on target to line up an availability window, how many engineers they could provide, etc)." That isn't an entirely true statement -- the PM would be the one to get this set in stone and pull rank if needed, esp. working with PMs for other projects or upper management. But as a team lead myself on another (albeit smaller) project, for instance, I would constantly be moving around the company talking with the other leads/managers to do exploratory work on where people were at even before the core team kicked off, building bridges so to speak. And between the core team meetings the unexpected would happen. Sometimes that would be a discussion with other leads, sometimes it would make more sense to bring it up with the PM, but generally speaking her plate was pretty full so I would take as much off of it as I could.
The team lead wasn't in particular overworked, he just spent the majority of his time in management type activities, perhaps about 1/3 of his time actually designing/coding/creating documentation.
97% of the time consensus driven decision making means no deadlock and the other 3% of the time you can put decisions to a vote.
I've seen more value destroyed by a team lead inappropriately setting the wrong agenda than I have by team members not knowing when to shut up.
If anything I've found that there's often too much consensus (people who just go with the flow rather than voicing an opinion).
That's now how deadlocks work. You can't just vote your way out of them, if you could, you wouldn't be in a deadlock to begin with. You'd just be at the point where a decision needs to be made.
> If anything I've found that there's often too much consensus (people who just go with the flow rather than voicing an opinion).
That's a separate problem. A healthy and functional team needs to be able to trust one another's opinions and provide an environment where everyone feels comfortable speaking their minds. If you don't have those the value of intrateam communication is comically low.
I've seen a number of different scenarios:
1) Consensus after a short discussion (vast majority of cases).
2) Consensus after a drawn out discussion (occasional, usually the discussion is valuable even if it takes a while).
3) Consensus after a drawn out discussion with one or two holdouts who agree to go with the majority opinion under protest (not common).
4) A drawn out discussion where it becomes clear that further discussion is fruitless and a (close) vote makes the decision (very, very rare but it has happened).
I'd say that that most of the time the decisions made in one of these 4 scenarios are better than the decisions made unilaterally by a team lead.
Whatever you're referring to as 'deadlock' I'm not sure I've ever seen it - as a team lead or otherwise. What is it?
So yes, I agree. Even if you don't have a manager, there must be a decision maker that has the authority and freedom to make those decisions, even if they don't directly manage the others.
I think you voiced the deadlock issue pretty well.
I've also seen team leads set agendas and drive discussion in such a way as to bury important issues that would otherwise come out while wasting time on minutiae.
In contrast I've never really seen one of these fabled technical arguments over tabs vs. spaces that lasted 4 hours and wasted everybody's time. If nothing else, sheer boredom prevents discussions from going on longer than they have to.
Trusting that a single Tech Lead always will have the right context to authoritatively decide the best way forward seems naive to me. Where is this magical person?
and a "decider" is definitely needed.
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.
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.
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').
I wish I lived in your world, but clearly we live in very different worlds.
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.
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.
overall direction of the project, subteam leadership,
cross-cutting concerns
(Source: I am one of those 8 (not six))
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.
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.
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.
Maybe his Mediator can be that person but if you give the Mediator the power to break these deadlocks then you need to ensure that he has enough practical experience to make sane choices. And if you have a Mediator with the authority to break a deadlock and the experience to do so with mostly correct decisions you have what most people call a Tech Lead.