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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
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?
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.
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}}"
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.
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.
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.
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.
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.
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.
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'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.
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.
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.
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'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.
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'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.
>> 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.
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.
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.
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.
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.
115 comments
[ 5.2 ms ] story [ 220 ms ] threadMaybe 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.
I think you voiced the deadlock issue pretty well.
and a "decider" is definitely needed.
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?
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.
I've seen more value destroyed by a team lead inappropriately setting the wrong agenda than I have by team members not knowing when to shut up.
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 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.
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?
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.
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.
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').
I wish I lived in your world, but clearly we live in very different worlds.
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.
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.
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.
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.
(Source: I am one of those 8 (not six))
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
But I for one, suggest that 'coherence' is an important thing and someone needs to 'lead' that.
Feasibly, it could be an 'architect' or someone in that role, meaning that 'theoretically' you don't need a 'tech lead'.
But I'd suggest in reality, someone should be the 'lead' in one way shape or form.
Maybe they can soften the role and get the devs to understand that it's more of a 'principal' than a 'boss' type thing.
LOL you lucky SOB
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.
- 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.
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.
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 .
FTA:
> So, do we really need a tech lead? - Maybe yes when the conditions are not ideal.
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.
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'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.
You can learn the tech side. You can't learn to like your team, be a good person, or enjoy helping people.
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.
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.
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.
Of course, such a scam, to make it feel real, they would to have a product at some stage.
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.