Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We don't need a Tech Lead

vvgomes.com

Post reply on HN
Print view View original

41–50 of 116 posts

Re: We don't need a Tech Lead

#41

Post by bryanlarsen »

zaphar wrote: post #31
bryanlarsen wrote: post #16

Earlier quoted context omitted.

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.

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 tr…

> 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.

Re: We don't need a Tech Lead

#42

Post by NumberCruncher »

>> Well functioning teams in which people share responsibilities are not rare.

Setting up your team structure with the idea that it "might work out" because "it is not rare that it works out" is pure gambling. What is the definition of not rare anyhow? Probability > 0.02?

>> When a team is not functioning well, assigning a tech lead can potentially make it worse.

If you build your house with the idea of "planning for the best" because "it is not rare that it works out", calling a good architect after you realised that your house is collapsing "potantially makes it worse". That is because the architect potentially recommends you blowing the whole thing up and starting from scratch again.

Re: We don't need a Tech Lead

#43

Post by ep103 »

jcadam wrote: post #34

Most companies (and/or government agencies) in the real world aren't willing to pay for top-quality developers. Hopefully you can get lucky and end up with one strong software engineer on a team otherwise filled with marginally competent code monkeys. In those cases you absolutely want to place the top developer in charge (until he/she gets recruited away, that is), though if you have a strong dues-paying culture it…

This is the only thing I was thinking this entire article.

I'm a dev lead. If I had an entire team of my great engineers, my job would be easy. I'd simply delegate my duties to everyone else, and we'd all be nearly equal.

The reality is I have 2 junior people who need to be guidanced through everything. I have one moderately experienced guy who just wants to be left alone to solve bugs on his own, in quiet isolation. I have one moderately experienced guy, who's ambitious, but used to cut corners when he thought no one was paying attention. And I have one senior dev who is a great coder, and can take 1 or 2 juniors under his wing, but hates code architecture with a passion and just wants to make small ui features on the main website.

Who, exactly, then can I delegate everything to? Removing a tech lead would be disastrous.

I'm jealous of people who work in a shop where the teams are so well constructed, that they think you can get rid of the tech lead role.

I'm also willing to bet that those people either have amazing tech leads, and don't realize it, or have amazing managers one level higher, and simply haven't climbed high enough up the managerial ladder to see how lucky or how much work goes into that.

Re: We don't need a Tech Lead

#44

Post by bryanlarsen »

titzer wrote: post #35
bryanlarsen wrote: post #16

Earlier quoted context omitted.

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.

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?

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

Re: We don't need a Tech Lead

#45

Post by zaphar »

bryanlarsen wrote: post #41
zaphar wrote: post #31

Earlier quoted context omitted.

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 tr…

> 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…

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.

Re: We don't need a Tech Lead

#46

Post by [deleted] »

tomca32 wrote: post #3

In the teams without a tech lead that I have seen, people just defer to the most senior/confident developer in the team to resolve deadlocks and decide between some tougher choices. That person essentially becomes a tech lead without a title. Edit: I agree with the child comments. It makes things easier, less prone to miscommunication, and efficient to have an actual tech lead in the team.

[deleted]

Re: We don't need a Tech Lead

#47

Post by zaphar »

bryanlarsen wrote: post #44
titzer wrote: post #35

Earlier quoted context omitted.

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?

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

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.

Re: We don't need a Tech Lead

#48

Post by jerf »

zaphar wrote: post #38
jerf wrote: post #24

Earlier quoted context omitted.

"In the cases of a disagreement deadlock you need someone to break the deadlock." != "a team that is constantly looking for one person to call all the shots".

A good tech lead actively works to minimize occasions to exercise his role as deadlock breaker. But you can't eliminate that need. If you do then the first time you have a deadlock will be a disaster and you may find that a well functioning team has now turned in a massively dysfunctional one.

"In the cases of a disagreement deadlock you need someone to break the deadlock." != "You can eliminate the need for disagreement deadlocking."

Re: We don't need a Tech Lead

#49

Post by mnsc »

zaphar wrote: post #39
mnsc wrote: post #9

Earlier quoted context omitted.

For me the person taking the mediator role doesn't need to have "enough practical experience". The role of mediator could be someone not invested in on side of the deadlock that takes it upon them to lay out the pros and cons so that the people assuming the architect role discuss from the same premises. A mediator could also identify if there are outside demands that are uncertain that causes the deadlock. Then someo…

The risk you take on when the mediator role doesn't have practical experience is that no consensus will be reached. Or worse if that mediator is empowered to break a deadlock he'll do so badly because he doesn't have enough context to make a good decision and not enough time to come up to speed in order to make a good decision.

My point is that the mediator shouldn't make the decision that is not in the role. If the deadlock is concerning i.e. two competing architectural decisions the mediator should help the different people with architect roles engaged in the debate to decide how to move forward.

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?

Re: We don't need a Tech Lead

#50

Post by mnsc »

ep103 wrote: post #43
jcadam wrote: post #34

Most companies (and/or government agencies) in the real world aren't willing to pay for top-quality developers. Hopefully you can get lucky and end up with one strong software engineer on a team otherwise filled with marginally competent code monkeys. In those cases you absolutely want to place the top developer in charge (until he/she gets recruited away, that is), though if you have a strong dues-paying culture it…

This is the only thing I was thinking this entire article. I'm a dev lead. If I had an entire team of my great engineers, my job would be easy. I'd simply delegate my duties to everyone else, and we'd all be nearly equal. The reality is I have 2 junior people who need to be guidanced through everything. I have one moderately experienced guy who just wants to be left alone to solve bugs on his own, in quiet isolation.…

Hey, quit!
Post reply on HN