We don't need a Tech Lead

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.

1) Development teams have churn, the tech lead onboards new members and gets them aimed(and kept) in the proper direction.

2) The tech leads decides on technology when developer A and developer B are deadlocked over MySQL vs Postgres, or any other stack choice.

3) The tech lead is the one accountable for failures. Once the people above the tech lead have titles like CIO, CTO, CEO and the like - they expect and demand a single point of contact as their visibility into the development process. The tech lead is this person, and should be "professional" enough to interface with the exec-types, as well as have the communication savvy to translate technical issues into management issues.

Finally, an example of when a tech lead is wanted: Image your development team is 8 people, working on a full stack web application. Another department wants to use this web application's authentication capabilities in their own project. Do you want that other project's 4 developers talking to every single one of your 8 developers about how that should be done? That's 32 individual conversations, with 32 different ideas and opinions about how to do it. You want their tech lead to talk to your tech lead, and a reasonable decision made and enforced. You don't want 32 meetings with no outcome.

The author's experience sounds(at least to me) like small teams and small company structures. While that may work well without a tech lead, once departments and companies become large - positions like tech lead really begin to make sense.

edit: added example and hopefully removed typos

Most teams I have worked on have a manager who used to be an engineer. In terms of direction setting, a final authority amd so forth, it is their call. They talk to their management and other teams and tell us what to work on, but are not involved in the technical day to day and are not micromanaging the details. So I might do the Android client, X does the web API which uses JSON, Y is the DBA designing the database schema, Z does iOS and so forth. It is not ruderless as they can make the final decision.

With a team lead, you have one person on the team doing work who is also doling out work. It can lead to all of the problems mentioned in the arricle.

Also - small, underfunded companies usually can not get a good experienced programmer or administrator. So the hires are the inexperienced types who could probably use a team lead. But the companies are too small to have one. By the time someone has a resume to be good enough to join a company which can afford a larger tech team with a manager, an experienced lead and several somewhat experienced programmers - the need for a lead is much less. Besides, people are naturally going to defer somewhat to a more experienced engineer who has been at the company longer.

I think the bottleneck and bus factor points are key. The tendency would be for the lead to own the most high-visible, business impacting piece of the code base, and dole out less attractive and impactful pieces to others. It can waste time as well - they can assign work but are too busy to really go over it, then after a week you show them what you did, but they did not mention they like things done with MVC, or TDD, or whatever, so then you have to spend another week doing it over. As the article says, they're overloaded and often enough away from the team. Instead of having four or five autonomonous engineers going at full blast, you have one overloaded engineer who hogs more of the critical, business visible code than they can handle, and the other engineer whose time it is to waste. Who are usually not much less experienced than the lead.

The flip side to "design by committee" is that one person is designing every thing! That person is too overloaded to design everything as needed, so you have the non-leads writing code for a week, that will be thrown away until the lead has time to come back around and decide how your project will be designed.

An ex-engineer manager does not have their hand in day to day, and many of these conflicts go away, whereas the needed leadership is there if necessary. I'm surprised people feel otherwise. The alternative to design by committee is often everyone waiting on the one overloaded person who has to design the whole system.