I don't know that I fully agree with this. I think in even well functioning teams you need at least one person who is empowered to make the call. In the cases of a disagreement deadlock you need someone to break the deadlock. Whether that person is a called a Tech Lead or something else you still need them and they need authority and freedom to make the call.
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.
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.
I agree with you. As a "tech lead" myself, I find my biggest jobs are fostering communication between team members and clearing roadblocks. Those roadblocks could be making a design decision, clearing up requirements, getting support from external teams, etc. When every team member is responsible for clearing their own obstacles you find a lot less work gets done and often times the same problem gets solved multiple times by multiple team members.
That sounds like a project manager to me. I'm curious if you have anyone with that job title (and if so what they do) or if your "team lead" is acting as a de facto project manager to fill a void.
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.
Yes, there was a dedicated PM - she was essentially at the top of the food chain, running the steering committee meetings (both the core team and individual feature teams) and coordinating the effort with all the team leads/managers (hardware, software, QA, product release engineering, regulatory, source control management, requirements engineering, and technical documentation). As I stated, there some 30+ people involved in the project. So the team leads/managers would at times do PM-like activities, more or less working hand-in-hand with the PM to get things through the system, organized, scheduled, signed-off etc.
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.
One doesn't become a leader by just being called the lead. Some people have personal traits that make them assume a leader role more often then others.
In my experience, a team that is constantly looking for one person to call all the shots isn't very much empowered. If everyone can take responsibility to own up for the calls to make, you end up with a far more engaged team.
It requires a certain maturity but a motivated team should be able to grow into such a mode over a couple of weeks or month.
Experts will emerge on certain topics and the team will often look to them to weight in on certain topics. That will all come pretty naturally once a team has passed its initial formation phase.
"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.
> 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.
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.
>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.
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?
Agree with this. A few days after I started, the engineering manager (the guy who hired me) quit. After that, it was kind of a clusterfuck because the CEO refused to make any real decisions because he was afraid of upsetting any of the engineers. As a result, very few decisions got made, and any deadlocks resulted in hours of frustrating and anger on both sides. I tried to put my foot down on one of the projects that I owned and essentially said, "You put me in charge of this project, and this is how I want to do it," but the "committee" overrode my decisions and the CEO didn't back me up. A terrible way to run a team. I left a few months later.
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.
What I don't like about this kind of articles is the one-sided way they explain things. I would have like he investigate how the tech lead role could also be improved.
I think you voiced the deadlock issue pretty well.
I don't know that I fully agree with you. I've seen some "deadlock breaking" where necessary discussions were cut short by, like, 5 or 10 minutes and the resulting "compromise" architectural decisions ended up being disastrous.
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.
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 someone in the role as concierge could reach out and clear the uncertainty which would allow the team to unite on a sane technical choice going forward (in small increments).
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?
The same place you find two people who can by consensus arrive at the best decision moving forward. The point of breaking a deadlock isn't that you choose the best choice but that you are able to make a choice which is strictly better than making no choice.
Trusting that a pair of engineers will always come to an agreement to authoritatively decide the best way forward seems naive to me. Where are these magical people?
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.
Great. But we live in reality where lots of teams are not well functioning some or all of the time, and we still need to get things done even when we don't have the time, resources or influence to fix the team composition then and there.
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.
>Great. But we live in reality where lots of teams are not well functioning some or all of the time
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').
> 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
I wish I lived in your world, but clearly we live in very different worlds.
> 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
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.
>nobody feels empowered enough to call other people on their shortcomings
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.
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?
Yet in general, consensus is the guiding mode of operation for all teams. The core team has never overridden a team's decision against their will, and while such a thing is technically possible, it would be considered a catastrophic event, I'd imagine.
> A well functioning team makes all decisions by consensus, so there are no deadlocks.
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.
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 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.
> 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.
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.
The article pretty much ignores factors external to the development team. In my experience at a larger company, a key role of tech lead is as a central communication point for other teams / disciplines / projects. It becomes infeasible for every person working on a product to have to know exactly who to talk to for every question. Instead with leads, if I have a sw question, an electrical question, a service question, I know who to go to. This doesn't mean the lead has to know everything themselves. Can always refer me to the expert. But ideally the lead is also someone with above average communication skills.
>It becomes infeasible for every person working on a product to have to know exactly who to talk to for every question.
It is, however, perfectly feasible to ask such questions on a team chatroom. "Who knows about [x]?" is usually enough to get the right person to talk to and it means the lead doesn't keep getting interrupted.
A team chatroom... what a nice idea. This was a larger, more enterprise company. Enough said?
But seriously, I think the answer depends heavily on company and team size. The role I mention is a lot less critical for smaller teams or when there are minimal different stakeholders involved.
As a counterpoint to that maybe everyone on the team should know who the expert is in any particular area and EVERY member of the team should have adequate communication skills
This is wishful thinking at best, companies require practical thinking because reality is corporate suicide. Not everyone will have great communication skills - and as a team increases in size, this becomes increasingly difficult.
This isn't wishful thinking, I work with a 100% remote dev team and communication skills is one of the top things we screen for when interviewing. I assume other remote teams also value that skill.
Communication skills are certainly important. I believe we both agree communication both at an organizational level, as well at a personal level is important.
My point is that as an organization scales, you will have many teams, and teams of teams even. The wishful thinking is that you can disband this entire structure because 'we hire good communicators'.
I don't know what part of the industry you work in, but the idea that we would hire someone incapable of communication at the level of "you should ask Dave of Simon about that feature" seems nuts to me.
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 may be difficult to replace an entrenched, useless senior engineer with someone better.
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.
I'd like to hear more about the senior dev who hates code architecture. Do you have any examples? I still go back and forth on on the value of code architecture, and I think some examples might be enlightening.
Not a formal or philosophical thing, he's just used to feature development, and/or working on somewhat isolated things. Building out code on a project wide level, so it can have features built into it, is just a level larger than what he used to be comfortable with, I think. And also, framework building doesn't have ui design component, which is something he enjoys.
I'm in a similar situation as ep103 and it isn't always that easy to just quit. Lots of things keep a person where they are that are unique to their own world. Plus, at this point in my career, I'm getting to the point where I am that slightly out of touch dev manager who has to catch himself from saying things like "Back in my day..." Plus, where would I go? Certainly not to a great place like the author's location where everything is so good that they don't need tech leads like myself.
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.
I have worked in teams without a formal tech lead and yes, the most senior/confident developer would work like that (even without extra pay).
However, these teams also tended to be most consensus-driven. Decisions would take forever because there would be a tie and people would just put it aside, or they would avoid hurting other people's feelings directly (it often turned somewhat personal), etc. It was very inefficient.
Senior does not automatically imply confident. I'm most senior in my team but in certain areas I have to admit I'm not confident enough to make a sane choice. If a junior developer that is confident in a solution can't be able to lead in that decision, the team is dysfunctional as stated in the article.
It's not about a junior person leading in the decision, it is about deciding between competing solutions. As the senior person you should see the bigger picture beyond the current problem solution even if it's an area your unfamiliar with. The people proposing the solution need to convince you that their solution is the one to go with.
A good lead will listen to all sides, and explain how a decision is being made. The goal is that whatever decision occurs that everyone is okay with it, even if they disagree. This is where people skills (and engineering skills like cost, consistency, time) are just as important as technical skills.
Sounds like a "Tech Lead" that is a skilled mediator that gets the whole team onboard the right decision and at the same time a skilled coach that can explain the relevant part of the bigger picture to the juniors and how it relates to the decision at hand.
My takeaway from the article is that these two roles in a well functioning team can be two people and also different people depending on the problem.
Confidence also doesn't necessarily imply competence. Who hasn't been confident in some solution, which turned out to be a terrible idea due to factors that we did not account for that were beyond our knowledge and experience?
Sorry, but that's just not practical. Even github has managers now; you need someone to steer things in one direction and have the authority to decide if all discussions failed, so that the project can actually move forward.
Put many senior devs together and it's entirely possible that the project would be "very interesting" code wise but nothing would actually be of use to the customers in 1 year. Yo dawg, I saw you refactored my code so I refactored it again.
While this sounds good in theory (and I've been in teams that were very self-organizing and operated well without a formal tech lead), I feel that it omits some key aspects of real life. Let's look at the list towards the end, for example:
- When there are newcomers, we need a strong coach.
- When there are architectural challenges, we need an experienced architect.
- When there are internal conflicts, we need a mediator.
- When there are external blockers or lack of resources, we need a concierge.
- When we need to negotiate and integrate with other teams, we need a ambassador.
Ok, so the author marked those under "leadership". My experience with other developers is that there is a surprisingly large dev population who would absolutely abhorred if they had to touch any of those things (maybe apart from the architecture part). And in my experience, the effect doesn't grow smaller, and might even become more profound, with prolific devs who have tens of years of experience; they want to code because coding is what they love (this of course applies to more junior devs too).
So the point is not to elevate one individual to some golden standard know-and-do-it-all aka Tech Lead. The whole point, which the article actually does touch, is to have different roles between team members, so that ideally everyone can focus on the things they are passionate about. If more than one people feel that they want to take responsibility with the things mentioned in the above list, fine, the team can have many "tech leads".
Just make sure that if you omit the whole role that people are not burdened with responsibilities they are going to hate. Because that is something that can destroy even a good team pretty well.
Exactly. In most small companies, the above roles often is the tech lead role. In larger companies, it's quite common to find it broken up - separate architects, different levels of engineers where the higher levels are expected to help guide newcomers or juniors; people to interface with other teams etc. If they then have "tech leads" it usually tend to mean someone who plays some of the above roles within a larger team that may have separate people for some of the functions at a higher level.
And you're right - a lot of people don't want the above responsibilities. I've had teams where despite our best intentions in hiring from within when possible, all the engineers wanted to remain in pure engineering roles, so we had to go out and hire people to fill those roles as the team grew and I couldn't take on all of them myself any more.
Tech leads may not make sense for the author and some projects, but they absolutely make sense for other projects. This is why:
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.
I came out of lurker mode just to reply to this article.
I get the author's premise that capable developers don't necessarily need a lead. However, based on my experience, that is overly optimistic.
I've worked in large organizations for quite a while now and have run in to two specific situations where this mentality just doesn't work:
- Need for a tie-breaker. I've been in places where the Sr Devs on different projects/applications (myself as one of them) have all disagreed on the direction to take the roadmap. As a result, we ended up with four separate projects/applications going four separate ways. All because there wasn't one person to get everyone in line.
- Need for a tech lead to set the right direction. It's been a while since I have worked with a lot of talented, like-minded people that were all capable of making good technical decisions. For the past ten years, I have seen a huge trend to just finding the lowest cost resources. Granted, it has more to do with my situation, but that just goes to show that the author's position may be valid for him, it definitely does not apply to everyone.
I also believe in the following:
- The Mythical Man-Month where the best team structure is similar to an operating room where the surgeon has complete control of everything that happens. He has ultimate accountability and what he says goes.
- Also Peopleware where really good people are worth the money. If you don't get really good people, no matter how willing they are, they aren't going to make a solution as clean. And unfortunately, I'm in a world where we have decent developers who are always willing to jump on tasks, but they don't always make the best decisions. A tech lead would fix that.
Anyway, context is everything. What works for some might not work for others.
Isn't the underlying assumption here that the team members know everything they need to know to make a decision?
While that may be true for, say, algorithm selection, I would argue that, at least in larger organizations, there are overarching architecture or standards that need to be considered, and that it may be a waste for the individual team members to constantly keep track of.
We had a super-smart team come in a few years ago, and work very independently to come up with an awesome standalone solution that worked in no way, shape, or form with the millions of lines of installed code. There's an argument to be made that perhaps that's great and they were not constrained by legacy code, but decisions like that should be made purposefully, not based on how a few smart people who know almost nothing about the broader business or technology feel.
My opinion is if you don't need a tech lead, great. But, most teams do. Someone needs to be there making a final decision. Also, it depends on the company and the type of team. If it is a government organization and the majority of the development team are contractors, a tech lead is most definitely needed to advocate in the best interests of the government entity. In this scenario, the tech lead would need to be a government employee.
I also think it is hard enough to get the Tech Lead and Product Owner on the exact same page even with good requirements documents. If you give all team members the requirements and have them present them to each other in terms of vision and goal of the product, there is would be differences of understanding. I see the Tech Lead role as keeping everyone on the same vision and (in a lot of companies) organizing the team to be most effective.
Every team has a tech lead (or a most senior dev, or architect, or whatever) whether they formally assign one or not. Titles are nonense but so is the idea that roles don't exist.
Regardless of the title (or lack of title) of the person, there will always be a person or a small subset of people that make technical judgements, communictate with management and so on.
I completely agree with the article that coaching, architecture etc. are different tasks and should ideally be different people. The reality though seem to be that it's usually just many hats for one or very few people .
I've found that tech leads grow organically as a team grows. The go-to guy who knows the products and the tech, and to whom everyone go with questions, if they also have leadership skills and like to help other, ends up falling into that role almost by accident. Whether it becomes formalized or not depends on the organization. I don't think you need to inject a tech lead role onto a team that hasn't already informally started using one.
As a Tech Lead on my current project I see my role as that of the mediator many times. But something interesting I've found in my current role is that I have to extract opinions from my team. They are great developers but they are quiet so I have to pull them aside and get their feedback. I have to let them know why we are doing what we are doing.
I'd argue that a great Tech Lead (which I am not) encourages his team to work together better all while guiding them around common project pitfalls so that they don't make massive mistakes in direction. He also needs to be able to make every voice on his team heard. This has been really hard for me, and every time someone expresses an opinion contrary to mine I end up having to stop my knee jerk reaction to shoot them down. Because my team needs differing opinions.
I think my biggest personal win has been getting one of our quiet developers who doesn't have the best grasp of English to speak more and feel respected (I hope).
To be fully up front my team is 100% contract developers other than me, so I also have to let them know that I personally do not see them as contractors. They have just as much buy in to this project. If they don't like the design, I'll listen and we can discuss it as a team as long as there is a proposed alternative.
Nah, this is wrong. Management is a discipline in its own right, and teams function better with management. It's not a slight to say that teams need a lead, either. I'm sure that developers can self-organize and use their personal leadership skills to help guide the team, but that isn't optimal. In my experience (as a manager), here's why:
1. First and foremost, it takes time to lead. If I have a 6-8 person dev team, it's far less efficient to spread out the overhead to all of them rather than concentrating it in one person - the lead/manager/whatever.
2. Related to #1, what we really want is to let our best developers... develop. It's my job to keep them out of useless meetings and bureaucracy, and even the smallest of companies have bureaucracy. I deal with the roadblocks, you write code.
3. Management is a discipline in its own right. I have a technical background, but these days I should not ever be the best developer on the team. I have a different set of skills and my job is to use them to enable good devs.
By that same token, I would not expect any developer on my team to be the best manager. The only time I expect that is if the company thinks the best analyst/dev/whatever is logically who shuold be the manager, which is common, and incorrect. The manager is the best leader - if that's also the best dev, then go for it, but it is not automatic that best individual contributor = manager.
4. I've posted this before, but this bleeds into the idea of the "hands on" engineering manager/director. Terrible idea, for all of the reasons above. Pick one role and go with it - if you want a leader and a coach to develop your talent, then get a manager/director. If you want a senior engineer, hire that instead. Or both. But not the same person in both roles.
None of this is to minimize the ability for developers to lead. There are lots of smart developers out there who also have good leadership skills and have made the transition, but none of them are good manager simply because they were good engineers. Consider the reverse, you'd never assume someone can plug in as an engineer simply because they are a good manager, it's absurd. I think it's inefficient to have someone do both, as management and engineering skillsets don't overlap all that much. You need each other, I promise.
I think the distinction between manager and developer is an important one. Expecting a developer to become a high functioning manager is equally unrealistic to expect a technically minded manager to be able to make meaningful contributions to the code base.
I also fully agree that management is a discipline that is overlooked; often oddly by managers themselves. I attribute this phenomenon to my observation that many managers in startups growing into the role rather than coming from a formal MBA type background. I would go one step further and say that a manager doesn't necessarily have to be a leader either, with leadership being another unique discipline.
A lot of comments here cover similar ground by using similar titles for different roles, which is understandable as different organisations have different needs and may assign a title that is not the most appropriate.
The author basically makes the same argument by admitting that different scenarios require different skill sets such as mediation, architecture, advocation, etc. However, the author takes a idealistic view that admits ideally any competent team member should be able to step up to the role when required.
In my experience though, in an organisation that requires structure, predictability, and on a compensation level as well, dedicated titles are important. It becomes even more important depending on the broader organisation and national culture. For teams that come from countries with high power distance, the difference in having opinions come from a "team leader" versus a co-worker can be received quite differently.
Therefore, I think the article has been able to create such an active discussion is because of the circumstantial nature of an appropriate answer. Coincidentally such discussions are often a trigger for teams to wish that there were a leader who can make a decision and for others to fall in line so that everyone can get on with actual work.
Can anyone imagine building a house where the window and the door crafts-men would use different materials, techniques and tools in each of the different rooms? Or where they would gather in a scrum and discuss this until they have reached consensus?
In no other profession would anyone embark on a large scale project without proper technical coordination. And this technical coordination is backed up by codes - the kind of codes that are legally enforceable.
Somehow software and the people working in there is different. There is a lot of confusion about the responsibility of the individual and team across the development process as evidenced by the spectrum of team orgs and workflows. I suspect one driver is the large power any developers yields on the outcome with the lack of sufficiently tangible and immediate feedback. This naturally leads to a less than objective self assessment of all players. Another is the desire and often accepted excuse that it is a creative process. There are significant professional incentives for doing something new where other approaches may have been more effective.
This article starts with "We don't need a tech lead". Which may be true.
It then veers into "You don't need a tech lead". Which I don't think is true.
I am a greybeard by HN standards. I have worked on teams of highly competent developers where there was no tech lead. They failed badly - the lack of both the design consistency from a single source (a literal 'chief builder') and there being no final arbiter. Disagreements lingered to the extent of, in one case, man overboard. Turns out Architectural Consistency is important.
In my latter days I'm occasionally called upon to 'sort out' what's going wrong in particular businesses, often with developers at the 'less good' end of the spectrum. And I can say that in many of these cases the absence of (or, more usually, the lack of competence in) the technical lead is often the root cause of many of the project ills. It can be as if the entire product is cast adrift on whatever technology and technical debt built up from years past.
There are huge flocks of software engineering that barely know "the web is a thing", let alone how to move the herd in a consistent direction.
So if you have a team that's functional anarchy (or meritocracy, if you prefer) - great! Count yourself lucky.
This article is actually argung that instead of a team leader, we need both a mediator, and a healthy and productive software team. The later aren't that common in my experience, and I've found that those that do exist are typically formed around a strong senior developer, i.e. the team leader that this article argues against. Productive teams may not need a team leader forever, but I suspect they do need one in order to come about.
This only outlines how a Tech Lead should operate, promoting consensus and not being authoritarian. Decision making by a committee is a recipe for failure.
I work in a largish (~30) geographically distributed team, itself nested in a much larger product structure. At our scale, we simply cannot function without hierarchy. We have techleads, a program manager, a technical program manager, and other managers. We had to organize ourself into a handful of smaller teams (3-5) that each have tech lead and manager roles, sometimes the same person, but not always.
FTA:
> - When there are newcomers, we need a strong coach.
This tech onboarding doesn't have to be done by the tech lead necessarily. It's done by a mentor who works closest to the newcomer's starter project. The rest they absorb by osmosis and (shock) documentation.
> - When there are architectural challenges, we need an experienced architect.
This is the correct role of a techlead.
> - When there are internal conflicts, we need a mediator.
This is the role of a manager.
> - When there are external blockers or lack of resources, we need a concierge.
This is the role of a manager.
> - When we need to negotiate and integrate with other teams, we need a ambassador.
This is a project manager or general manager role. Tech leads are involved but may not be the primary drivers.
I don't think you can foster a culture of ownership and responsibility where developers are "protected" from decision-making and involvement in other activities. The code isn't written in a vacuum, but as a function of the larger functions of building a business and organization. Furthermore, for essential tasks like evaluating new team members, devs must be involved as they will often be the ones most affected by the eventual decisions.
I'll use a hackneyed sports metaphor b/c my creativity has atrophied over years of nothing but coding: on a basketball team, the shooting guard should definitely be taking a good percentage of jumpers and concentrate on delivering a high percentage of buckets, but they may also be a great passer, a leader in the locker room, mentor for younger players, etc (up to and including weighing in on personnel matters), if they have those capabilities and trust. Probably better than just shooting baskets in a gym their entire career, right?
What is your definition of a 'team', is it a 2 pizza scrum team, is it your PD organization? In the real world team members have varying levels of context & product understanding - a tech lead should be the person with a firm enough grasp of a functional area to help make a decision, and that person doesn't always need to be a member of the team, nor is it true that the tech lead needs to make the decision because normally decisions are a collection of trade-offs - and the role should be to guide the team to the correct one, i.e. we were thinking of doing this, response: if you do that did you think of this consequence, or perhaps you should consider doing this instead...
Here in the real world its various shades of gray on most of these points mentioned - if you don't have a lead role what do your junior engineers aspire to be the architect for which you have a handful of - or perhaps they're just looking for a job elsewhere.
This article seems to neglect the primary reason a trustworthy tech lead is a good idea: specialized knowledge. A company not needing people with specialized tech knowledge is like a company not needing specialized legal knowledge. You can get along with consultants and common sense in some contexts. In others, you absolutely can get screwed.
I'm a tech lead in a large, distributed application. I disagree somewhat, there's a bit of a unicorn reasoning. If teams don't work well, a tech lead's job is to revive culture and confidence which is going to be harder.
My day to day as tech lead is mostly looking at our board and seeing if people's work loads are just fine. Do I provide mentoring? Sure, when I need too. Do I provide architectural guidance? Sure, when we have big stories that require my review. Majority of my time is spent taking care of my team. Is my team doing well? Absolutely. We communicate well and aren't shy to help each other out. But being a tech lead my emphasis is quality and making sure that my team is on track with that.
>> 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.
Anecdote: I've been on more that one team where no leadership emerged, and in fact, leadership type behavior was passively resisted. The reasons for this were many, but essentially it was easier (and I suspect more fun) when individual contributors could do their own thing in their own way, without any concern for the impact on their team members or downstream consumers of the software (help desk, IT, etc.) After all, writing useful log messages, or following a coding convention, or writing an automated test are all tedious and not very interesting compared to coding. These teams (if they can be called that) produced software that had little to no overall design.
A tech lead is not supposed to be a mediator. He/she is supposed to lead and that means understanding the business, the product, and the priorities enough to communicate as simply and as directly as possible. It's not about whether or not you need a "tech lead", it's about whether or not you have anybody, and I mean anybody, that can fulfill those tasks. It might very well be two people, or a team that can drive specific targets, doesn't matter. A "tech lead" is just a title that further complicates matters.
This reads like a person was asked if Tech Leads were necessary, felt the answer was "no", found research to the contrary, and wrote their own counter-argument paper. Do I agree with the premise that tech leads aren't necessary if you have a functional, harmonious team? Sure. But I feel that this paper spent as much time as I did coming to that conclusion, and with just as little consideration of what a tech lead could potentially bring to a team - even one that already works well.
If all that matters is the single team and its work, and the members of the team are both completely committed to the project and technically capable then sure, go without some form of lead.
However in practice there are several very good reasons to have a tech lead. Personally I see that it aligns best to have the lead be your architect, who works across many teams, as they have the ability to most clearly identify when an issue can take a compromise or requires struggling ahead with.
I sometimes wonder, if some Potemkin Tech Lead- all fraud, but scaring the shit out of the big ones, would be good. Sort of challenger in the ring, who constantly keeps the tech giants fighting, afraid to loose there markets.
Of course, such a scam, to make it feel real, they would to have a product at some stage.
I'd even go further to say that yes, you absolutely need a techlead when working on a project that requires a certain domain expertise or the project in question needs to have a coherent technical vision. Otherwise even skilled and well-intentioned teams can pull in different directions and/or build something that is internally incoherent and fragile.
I would say a great reason to have a tech leader is to share the role of PM between the BA and the tech lead. This role can be rotated as far as I'm concerned. A lot of companies I see have far too many PMs overseeing too few projects.
Applying the raft protocol quorum on teams, the +1 can the tech lead. According to the Raft Protocol, A quorum is a majority of members from a peer set: for a set of size n, quorum requires at least (n/2)+1 members.
While I think democracy is the best way to preserve personal liberty, I do not believe it is the way visionary or ambitious plans are conceived and executed.
as a general rule statements asserting that one can do without what is often considered essential are supposed to take the form of "We don't need no stinking {{insert pertinent phrase}}"
Curious what anyone thinks of this theory: each tech team should have two managers. One manages the people and the other manages the projects/technology.
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.
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.