We don't need a Tech Lead(vvgomes.com) |
We don't need a Tech Lead(vvgomes.com) |
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.
Of course, such a scam, to make it feel real, they would to have a product at some stage.
FTA:
> So, do we really need a tech lead? - Maybe yes when the conditions are not ideal.
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.
1. People who are tech leads feel that there is a need for tech leads. 1. People who are not tech leads feel that there is no need for tech leads.
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.
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.
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.
I think you voiced the deadlock issue pretty well.
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.
and a "decider" is definitely needed.
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
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.
edit: added example and hopefully removed typos
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.
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 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.
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.
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.
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.
But it is unusual.
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.
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'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?
It's nice to have a meritocracy, and when you can have a college of fair altruistic equals, it's great.
When you don't have that and need to get things done, get a dictator or a surgeon.
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.
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.
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.
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.
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.
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.
Are you literally saying that larger companies need managers for their dev teams because they're too enterprise to use slack?
FWIW I've used both in larger companies and smaller companies.
>But seriously, I think the answer depends heavily on company and team size.
I don't think it does. Slack chatrooms and email lists scale.
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.
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.
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?
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'.
overall direction of the project, subteam leadership,
cross-cutting concerns
(Source: I am one of those 8 (not six))
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?
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.