I have been thinking about whether we need a tech lead role for sometime. But now, I have come to a conclusion that tech lead role is unnecessary. Let me list my reasons, why I feel that way.
- Instead of a tech lead , we need a person to act as tech facilitator. This role should be rotated among the team members in weekly basis or biweekly basis. The main responsibility for Tech facilitator will be to resolve some technical conflicts within team by facilitating a discussion where advantages and disadvantages of all approaches are discussed and decision is made.
- I strongly believe the person with a strong technical expertise will be recognized by the team itself. We do not need to appoint a tech lead. Team members will go to a person who they trust as expertise in that technology. So there is no need for a technical lead role.
So instead of we pushing a person as a Tech lead to a team, I think we should let the team organize itself.
7 comments:
>> This role should be rotated among the team members in weekly basis or biweekly basis.
I think your first instinct was correct, don't have it at all. Don't even have the facilitator.
Different people of different backgrounds will be better at leading the resolution of certain technical challenges. For example, I'm often the most experienced person regarding persistence layers and database topics. But if a JavaScript problem came up, I wouldn't want to be holding the "Tech Facilitator Conch" that week.
It's not that I wouldn't want to learn through a trial by fire (sometimes the best way). But sometimes I'd rather learn from a person who knew what they were doing. Or, I'd like to choose to tackle a problem for the sake of learning by choice, being up front about my lack of experience and with the support of my team.
So, instead of assigning this role on a weekly basis, simply create a task for solving the problem and assign ownership to a specific person on the team -- just like any other card on the wall. Why should it be different from any other task?
I think you're right, but don't get too creative with the solution... ;-)
That said, I think it's important to *be able* to identify someone as the technical lead for externally facing concerns. For example, when your client comes to you and asks to speak to the technical lead, there should be someone who has the responsibility of "Default Tech Lead". This is where you need consistency strictly for the sake of perceived organization within your project. This should not necessarily be the most technically capable person in the room, but rather the person who's best able to communicate the technology to the client.
Cheers,
Clinton
>> Different people of different backgrounds will be better at leading the resolution of certain technical challenges
That is exactly my point. I don't think we need to assign someone for that. I am sure team will recognize that person.
About consistency, again it is up to the team and the situation they are in. We do not need to assign someone for that
I absolutely agree that a semi-permanent technical lead role is not a good an idea, and rotating the role is much better. But I think you go too far.
First, Clinton's right that external groups are going to need consistency from discussion to discussion. It's dangerous to have different people deal with different external groups, since invariably (1) person A and person B will disagree about something but forget to discuss enough to find out, resulting in conflicting/confusing messages for the outside world, and (2) discussions will cross over from one external group to another.
On a previous project, the tech lead was almost entirely focused on interaction with external technical groups. There we rotated the role with each production release, which helped keep anyone from getting too far removed from the code and feeling like a middle-manager, while allowing the rest of the dev team to be insulated from political issues so they could focus on delivery. Often the tech lead was available to participate in internal technical discussions, but the team was perfectly capable of moving forward without the lead when production or political issues arose.
As to your point that the team will naturally figure out who's strong in what, I agree in an ideal situation where the team is slowly built up one careful hire at a time. But when the team is quickly formed and consists of developers who may never have met before, figuring out who should be consulted about what can take time, and often the project can't afford the chaos that can ensue until everyone susses out everyone else's strengths.
Also keep in mind that some of what a tech lead does is pretty onerous (at least to any good dev who's got coding to do). It's not just a matter of knowing who's best at what: it's also about deciding who gets to be interrupted for yet another discussion with [insert meeting-happy non-team-member here] instead of getting to deliver working software.
I agree with both points 100%. Yes, you definitely need somebody to act as tech facilitator from time to time, and yes, rotating would be great. In this case, everybody would have a chance to participate very actively in the overall team dynamic (not just coding) and most importantly, everybody would be extremely committed to the success of team.
I can’t agree more with the second point as well.
I don’t think that there should be one person (tech lead) to talk to external groups. I have seen this too many times and it is definitely not working. Why? Because this person has to make many decisions (technical or others) that directly affect the team in one way or another. This usually backfires from a team being not 100% committed to total disagreements and open accusations for wrong decisions.
Keep the good stuff man :-)
I think it depends on the demographics of the team. I am usually part of a team where 80% of the team consists of developers with just 2-3 years of experience. In such teams, there is an obvious need for a "lead" who can give technical direction to the team. Usually such teams are lead by a jack-of-all-trades project lead/tech lead person but that's another story.
Rotation, while a nice idea on paper, never works because the team will get confused if you change the role too often.
As for the team recognizing someone as the lead, again, it depends on the group dynamics. In a high-stake industry like IT, political issues play a very important role. After working for several years in so called "flat" organizations, I feel that teams usually perform better when some hierarchies are clearly defined at the onset.
Self-organising does not equal democratic. Sometimes a decision needs to be made. If that can't be reached by a (very) brief amount of consensus-reaching or consent-giving, then someone must arbitrate. Even if the decision is wrong, it'll be right enough to start with.
Circular discussions are better held at the bar, not on the project time.
It sounds as though you're talking about a set/static type of team, rather than a team dedicated to a specific project. And in that case, a "technical lead" shouldn't be necessary at all. Essentially, the manager of the team (for anything major) would be the facilitor.
However for mid to large size projects, a technical lead may be necessary. Especially when dealing with cross-functional teams, perhaps located in different locations, etc. And this role should NOT be rotated on the individual project. You risk consistency, momentum on the project. Rotating this responsibility as new projects come up, though, would be fine as it helps broaden each individual's skillset.
Post a Comment