|
I'm surprised to see how many people think a tech lead is a good idea. 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. |