I don't know that I fully agree with this. I think in even well functioning teams you need at least one person who is empowered to make the call. In the cases of a disagreement deadlock you need someone to break the deadlock. Whether that person is a called a Tech Lead or something else you still need them and they need authority and freedom to make the call.
Maybe his Mediator can be that person but if you give the Mediator the power to break these deadlocks then you need to ensure that he has enough practical experience to make sane choices. And if you have a Mediator with the authority to break a deadlock and the experience to do so with mostly correct decisions you have what most people call a Tech Lead.
Case in point - I've been in a situation as detailed toward the end of the article where all the devs on the team were feature leads, except we still had a designated overall lead. Just 4 devs on the team, all of us were very sr (principal or sr. principal devs). But the overall number of stakeholders in the product were probably well over 30 people, so it was still a big coordination effort.
It was for a fairly large legacy enterprise healthcare product ($200M per annum revenue). Each big feature had its own core team with other stakeholders in the company -- usually these meetings would be with a half dozen other people. The main core team for the overall product had about 20 members. Each feature had its own requirements/design documents (usually 30+ pages each). The main requirements/design docs would sorta be like a high-level index linking to these sub documents.
It was a waterfall process of course, and once the designs were mostly there the entire team would work on all the features together. The team lead would assign what people would be working on at any given time, but beyond that the feature leads would break down and delegate the overall work based on who was working on their feature. Typically each feature would be worked on by 2 people at a time and sometimes 3.
The team lead wasn't actually the strongest dev, he just had the best 'leadership skills'. He was the one our manager trusted most and generally spoke to about overall project health and deadlines. He was the one who cleared pathways with other teams/resources (ie. ensured QA was on target to line up an availability window, how many engineers they could provide, etc).
I don't see any points in the article that really argue against having a designated lead, and I think it's always a weird idea that a team lead (note I don't say 'tech' lead) is seen as anything but a manager who still codes. It's not an architect, the strongest dev, etc. It's a person with a best management/leadership skills with perhaps a solid high-level grasp of the domain. In a small team/product yes it can just be just the strongest dev, naturally rising up. But in these situations I've seen usually the key is there are not too many overall stakeholders... say a team of 2-3 devs with less than 10 people involved overall.
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.
Agree with this. A few days after I started, the engineering manager (the guy who hired me) quit. After that, it was kind of a clusterfuck because the CEO refused to make any real decisions because he was afraid of upsetting any of the engineers. As a result, very few decisions got made, and any deadlocks resulted in hours of frustrating and anger on both sides. I tried to put my foot down on one of the projects that I owned and essentially said, "You put me in charge of this project, and this is how I want to do it," but the "committee" overrode my decisions and the CEO didn't back me up. A terrible way to run a team. I left a few months later.
So yes, I agree. Even if you don't have a manager, there must be a decision maker that has the authority and freedom to make those decisions, even if they don't directly manage the others.
What I don't like about this kind of articles is the one-sided way they explain things. I would have like he investigate how the tech lead role could also be improved.
I think you voiced the deadlock issue pretty well.
I don't know that I fully agree with you. I've seen some "deadlock breaking" where necessary discussions were cut short by, like, 5 or 10 minutes and the resulting "compromise" architectural decisions ended up being disastrous.
I've also seen team leads set agendas and drive discussion in such a way as to bury important issues that would otherwise come out while wasting time on minutiae.
In contrast I've never really seen one of these fabled technical arguments over tabs vs. spaces that lasted 4 hours and wasted everybody's time. If nothing else, sheer boredom prevents discussions from going on longer than they have to.
For me the person taking the mediator role doesn't need to have "enough practical experience". The role of mediator could be someone not invested in on side of the deadlock that takes it upon them to lay out the pros and cons so that the people assuming the architect role discuss from the same premises. A mediator could also identify if there are outside demands that are uncertain that causes the deadlock. Then someone in the role as concierge could reach out and clear the uncertainty which would allow the team to unite on a sane technical choice going forward (in small increments).
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.
The article pretty much ignores factors external to the development team. In my experience at a larger company, a key role of tech lead is as a central communication point for other teams / disciplines / projects. It becomes infeasible for every person working on a product to have to know exactly who to talk to for every question. Instead with leads, if I have a sw question, an electrical question, a service question, I know who to go to. This doesn't mean the lead has to know everything themselves. Can always refer me to the expert. But ideally the lead is also someone with above average communication skills.
>It becomes infeasible for every person working on a product to have to know exactly who to talk to for every question.
It is, however, perfectly feasible to ask such questions on a team chatroom. "Who knows about [x]?" is usually enough to get the right person to talk to and it means the lead doesn't keep getting interrupted.
As a counterpoint to that maybe everyone on the team should know who the expert is in any particular area and EVERY member of the team should have adequate communication skills
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.
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.
Sorry, but that's just not practical. Even github has managers now; you need someone to steer things in one direction and have the authority to decide if all discussions failed, so that the project can actually move forward.
Put many senior devs together and it's entirely possible that the project would be "very interesting" code wise but nothing would actually be of use to the customers in 1 year. Yo dawg, I saw you refactored my code so I refactored it again.
While this sounds good in theory (and I've been in teams that were very self-organizing and operated well without a formal tech lead), I feel that it omits some key aspects of real life. Let's look at the list towards the end, for example:
- When there are newcomers, we need a strong coach.
- When there are architectural challenges, we need an experienced architect.
- When there are internal conflicts, we need a mediator.
- When there are external blockers or lack of resources, we need a concierge.
- When we need to negotiate and integrate with other teams, we need a ambassador.
Ok, so the author marked those under "leadership". My experience with other developers is that there is a surprisingly large dev population who would absolutely abhorred if they had to touch any of those things (maybe apart from the architecture part). And in my experience, the effect doesn't grow smaller, and might even become more profound, with prolific devs who have tens of years of experience; they want to code because coding is what they love (this of course applies to more junior devs too).
So the point is not to elevate one individual to some golden standard know-and-do-it-all aka Tech Lead. The whole point, which the article actually does touch, is to have different roles between team members, so that ideally everyone can focus on the things they are passionate about. If more than one people feel that they want to take responsibility with the things mentioned in the above list, fine, the team can have many "tech leads".
Just make sure that if you omit the whole role that people are not burdened with responsibilities they are going to hate. Because that is something that can destroy even a good team pretty well.
Exactly. In most small companies, the above roles often is the tech lead role. In larger companies, it's quite common to find it broken up - separate architects, different levels of engineers where the higher levels are expected to help guide newcomers or juniors; people to interface with other teams etc. If they then have "tech leads" it usually tend to mean someone who plays some of the above roles within a larger team that may have separate people for some of the functions at a higher level.
And you're right - a lot of people don't want the above responsibilities. I've had teams where despite our best intentions in hiring from within when possible, all the engineers wanted to remain in pure engineering roles, so we had to go out and hire people to fill those roles as the team grew and I couldn't take on all of them myself any more.
Tech leads may not make sense for the author and some projects, but they absolutely make sense for other projects. This is why:
1) Development teams have churn, the tech lead onboards new members and gets them aimed(and kept) in the proper direction.
2) The tech leads decides on technology when developer A and developer B are deadlocked over MySQL vs Postgres, or any other stack choice.
3) The tech lead is the one accountable for failures. Once the people above the tech lead have titles like CIO, CTO, CEO and the like - they expect and demand a single point of contact as their visibility into the development process. The tech lead is this person, and should be "professional" enough to interface with the exec-types, as well as have the communication savvy to translate technical issues into management issues.
Finally, an example of when a tech lead is wanted: Image your development team is 8 people, working on a full stack web application. Another department wants to use this web application's authentication capabilities in their own project. Do you want that other project's 4 developers talking to every single one of your 8 developers about how that should be done? That's 32 individual conversations, with 32 different ideas and opinions about how to do it. You want their tech lead to talk to your tech lead, and a reasonable decision made and enforced. You don't want 32 meetings with no outcome.
The author's experience sounds(at least to me) like small teams and small company structures. While that may work well without a tech lead, once departments and companies become large - positions like tech lead really begin to make sense.
I came out of lurker mode just to reply to this article.
I get the author's premise that capable developers don't necessarily need a lead. However, based on my experience, that is overly optimistic.
I've worked in large organizations for quite a while now and have run in to two specific situations where this mentality just doesn't work:
- Need for a tie-breaker. I've been in places where the Sr Devs on different projects/applications (myself as one of them) have all disagreed on the direction to take the roadmap. As a result, we ended up with four separate projects/applications going four separate ways. All because there wasn't one person to get everyone in line.
- Need for a tech lead to set the right direction. It's been a while since I have worked with a lot of talented, like-minded people that were all capable of making good technical decisions. For the past ten years, I have seen a huge trend to just finding the lowest cost resources. Granted, it has more to do with my situation, but that just goes to show that the author's position may be valid for him, it definitely does not apply to everyone.
I also believe in the following:
- The Mythical Man-Month where the best team structure is similar to an operating room where the surgeon has complete control of everything that happens. He has ultimate accountability and what he says goes.
- Also Peopleware where really good people are worth the money. If you don't get really good people, no matter how willing they are, they aren't going to make a solution as clean. And unfortunately, I'm in a world where we have decent developers who are always willing to jump on tasks, but they don't always make the best decisions. A tech lead would fix that.
Anyway, context is everything. What works for some might not work for others.
Isn't the underlying assumption here that the team members know everything they need to know to make a decision?
While that may be true for, say, algorithm selection, I would argue that, at least in larger organizations, there are overarching architecture or standards that need to be considered, and that it may be a waste for the individual team members to constantly keep track of.
We had a super-smart team come in a few years ago, and work very independently to come up with an awesome standalone solution that worked in no way, shape, or form with the millions of lines of installed code. There's an argument to be made that perhaps that's great and they were not constrained by legacy code, but decisions like that should be made purposefully, not based on how a few smart people who know almost nothing about the broader business or technology feel.
My opinion is if you don't need a tech lead, great. But, most teams do. Someone needs to be there making a final decision. Also, it depends on the company and the type of team. If it is a government organization and the majority of the development team are contractors, a tech lead is most definitely needed to advocate in the best interests of the government entity. In this scenario, the tech lead would need to be a government employee.
I also think it is hard enough to get the Tech Lead and Product Owner on the exact same page even with good requirements documents. If you give all team members the requirements and have them present them to each other in terms of vision and goal of the product, there is would be differences of understanding. I see the Tech Lead role as keeping everyone on the same vision and (in a lot of companies) organizing the team to be most effective.
Every team has a tech lead (or a most senior dev, or architect, or whatever) whether they formally assign one or not. Titles are nonense but so is the idea that roles don't exist.
Regardless of the title (or lack of title) of the person, there will always be a person or a small subset of people that make technical judgements, communictate with management and so on.
I completely agree with the article that coaching, architecture etc. are different tasks and should ideally be different people. The reality though seem to be that it's usually just many hats for one or very few people .
I've found that tech leads grow organically as a team grows. The go-to guy who knows the products and the tech, and to whom everyone go with questions, if they also have leadership skills and like to help other, ends up falling into that role almost by accident. Whether it becomes formalized or not depends on the organization. I don't think you need to inject a tech lead role onto a team that hasn't already informally started using one.
As a Tech Lead on my current project I see my role as that of the mediator many times. But something interesting I've found in my current role is that I have to extract opinions from my team. They are great developers but they are quiet so I have to pull them aside and get their feedback. I have to let them know why we are doing what we are doing.
I'd argue that a great Tech Lead (which I am not) encourages his team to work together better all while guiding them around common project pitfalls so that they don't make massive mistakes in direction. He also needs to be able to make every voice on his team heard. This has been really hard for me, and every time someone expresses an opinion contrary to mine I end up having to stop my knee jerk reaction to shoot them down. Because my team needs differing opinions.
I think my biggest personal win has been getting one of our quiet developers who doesn't have the best grasp of English to speak more and feel respected (I hope).
To be fully up front my team is 100% contract developers other than me, so I also have to let them know that I personally do not see them as contractors. They have just as much buy in to this project. If they don't like the design, I'll listen and we can discuss it as a team as long as there is a proposed alternative.
Nah, this is wrong. Management is a discipline in its own right, and teams function better with management. It's not a slight to say that teams need a lead, either. I'm sure that developers can self-organize and use their personal leadership skills to help guide the team, but that isn't optimal. In my experience (as a manager), here's why:
1. First and foremost, it takes time to lead. If I have a 6-8 person dev team, it's far less efficient to spread out the overhead to all of them rather than concentrating it in one person - the lead/manager/whatever.
2. Related to #1, what we really want is to let our best developers... develop. It's my job to keep them out of useless meetings and bureaucracy, and even the smallest of companies have bureaucracy. I deal with the roadblocks, you write code.
3. Management is a discipline in its own right. I have a technical background, but these days I should not ever be the best developer on the team. I have a different set of skills and my job is to use them to enable good devs.
By that same token, I would not expect any developer on my team to be the best manager. The only time I expect that is if the company thinks the best analyst/dev/whatever is logically who shuold be the manager, which is common, and incorrect. The manager is the best leader - if that's also the best dev, then go for it, but it is not automatic that best individual contributor = manager.
4. I've posted this before, but this bleeds into the idea of the "hands on" engineering manager/director. Terrible idea, for all of the reasons above. Pick one role and go with it - if you want a leader and a coach to develop your talent, then get a manager/director. If you want a senior engineer, hire that instead. Or both. But not the same person in both roles.
None of this is to minimize the ability for developers to lead. There are lots of smart developers out there who also have good leadership skills and have made the transition, but none of them are good manager simply because they were good engineers. Consider the reverse, you'd never assume someone can plug in as an engineer simply because they are a good manager, it's absurd. I think it's inefficient to have someone do both, as management and engineering skillsets don't overlap all that much. You need each other, I promise.
I think the distinction between manager and developer is an important one. Expecting a developer to become a high functioning manager is equally unrealistic to expect a technically minded manager to be able to make meaningful contributions to the code base.
I also fully agree that management is a discipline that is overlooked; often oddly by managers themselves. I attribute this phenomenon to my observation that many managers in startups growing into the role rather than coming from a formal MBA type background. I would go one step further and say that a manager doesn't necessarily have to be a leader either, with leadership being another unique discipline.
A lot of comments here cover similar ground by using similar titles for different roles, which is understandable as different organisations have different needs and may assign a title that is not the most appropriate.
The author basically makes the same argument by admitting that different scenarios require different skill sets such as mediation, architecture, advocation, etc. However, the author takes a idealistic view that admits ideally any competent team member should be able to step up to the role when required.
In my experience though, in an organisation that requires structure, predictability, and on a compensation level as well, dedicated titles are important. It becomes even more important depending on the broader organisation and national culture. For teams that come from countries with high power distance, the difference in having opinions come from a "team leader" versus a co-worker can be received quite differently.
Therefore, I think the article has been able to create such an active discussion is because of the circumstantial nature of an appropriate answer. Coincidentally such discussions are often a trigger for teams to wish that there were a leader who can make a decision and for others to fall in line so that everyone can get on with actual work.
Can anyone imagine building a house where the window and the door crafts-men would use different materials, techniques and tools in each of the different rooms? Or where they would gather in a scrum and discuss this until they have reached consensus?
In no other profession would anyone embark on a large scale project without proper technical coordination. And this technical coordination is backed up by codes - the kind of codes that are legally enforceable.
Somehow software and the people working in there is different. There is a lot of confusion about the responsibility of the individual and team across the development process as evidenced by the spectrum of team orgs and workflows. I suspect one driver is the large power any developers yields on the outcome with the lack of sufficiently tangible and immediate feedback. This naturally leads to a less than objective self assessment of all players. Another is the desire and often accepted excuse that it is a creative process. There are significant professional incentives for doing something new where other approaches may have been more effective.
This article starts with "We don't need a tech lead". Which may be true.
It then veers into "You don't need a tech lead". Which I don't think is true.
I am a greybeard by HN standards. I have worked on teams of highly competent developers where there was no tech lead. They failed badly - the lack of both the design consistency from a single source (a literal 'chief builder') and there being no final arbiter. Disagreements lingered to the extent of, in one case, man overboard. Turns out Architectural Consistency is important.
In my latter days I'm occasionally called upon to 'sort out' what's going wrong in particular businesses, often with developers at the 'less good' end of the spectrum. And I can say that in many of these cases the absence of (or, more usually, the lack of competence in) the technical lead is often the root cause of many of the project ills. It can be as if the entire product is cast adrift on whatever technology and technical debt built up from years past.
There are huge flocks of software engineering that barely know "the web is a thing", let alone how to move the herd in a consistent direction.
So if you have a team that's functional anarchy (or meritocracy, if you prefer) - great! Count yourself lucky.
This article is actually argung that instead of a team leader, we need both a mediator, and a healthy and productive software team. The later aren't that common in my experience, and I've found that those that do exist are typically formed around a strong senior developer, i.e. the team leader that this article argues against. Productive teams may not need a team leader forever, but I suspect they do need one in order to come about.
This only outlines how a Tech Lead should operate, promoting consensus and not being authoritarian. Decision making by a committee is a recipe for failure.
I work in a largish (~30) geographically distributed team, itself nested in a much larger product structure. At our scale, we simply cannot function without hierarchy. We have techleads, a program manager, a technical program manager, and other managers. We had to organize ourself into a handful of smaller teams (3-5) that each have tech lead and manager roles, sometimes the same person, but not always.
FTA:
> - When there are newcomers, we need a strong coach.
This tech onboarding doesn't have to be done by the tech lead necessarily. It's done by a mentor who works closest to the newcomer's starter project. The rest they absorb by osmosis and (shock) documentation.
> - When there are architectural challenges, we need an experienced architect.
This is the correct role of a techlead.
> - When there are internal conflicts, we need a mediator.
This is the role of a manager.
> - When there are external blockers or lack of resources, we need a concierge.
This is the role of a manager.
> - When we need to negotiate and integrate with other teams, we need a ambassador.
This is a project manager or general manager role. Tech leads are involved but may not be the primary drivers.
I don't think you can foster a culture of ownership and responsibility where developers are "protected" from decision-making and involvement in other activities. The code isn't written in a vacuum, but as a function of the larger functions of building a business and organization. Furthermore, for essential tasks like evaluating new team members, devs must be involved as they will often be the ones most affected by the eventual decisions.
I'll use a hackneyed sports metaphor b/c my creativity has atrophied over years of nothing but coding: on a basketball team, the shooting guard should definitely be taking a good percentage of jumpers and concentrate on delivering a high percentage of buckets, but they may also be a great passer, a leader in the locker room, mentor for younger players, etc (up to and including weighing in on personnel matters), if they have those capabilities and trust. Probably better than just shooting baskets in a gym their entire career, right?
What is your definition of a 'team', is it a 2 pizza scrum team, is it your PD organization? In the real world team members have varying levels of context & product understanding - a tech lead should be the person with a firm enough grasp of a functional area to help make a decision, and that person doesn't always need to be a member of the team, nor is it true that the tech lead needs to make the decision because normally decisions are a collection of trade-offs - and the role should be to guide the team to the correct one, i.e. we were thinking of doing this, response: if you do that did you think of this consequence, or perhaps you should consider doing this instead...
Here in the real world its various shades of gray on most of these points mentioned - if you don't have a lead role what do your junior engineers aspire to be the architect for which you have a handful of - or perhaps they're just looking for a job elsewhere.
This article seems to neglect the primary reason a trustworthy tech lead is a good idea: specialized knowledge. A company not needing people with specialized tech knowledge is like a company not needing specialized legal knowledge. You can get along with consultants and common sense in some contexts. In others, you absolutely can get screwed.
I'm a tech lead in a large, distributed application. I disagree somewhat, there's a bit of a unicorn reasoning. If teams don't work well, a tech lead's job is to revive culture and confidence which is going to be harder.
My day to day as tech lead is mostly looking at our board and seeing if people's work loads are just fine. Do I provide mentoring? Sure, when I need too. Do I provide architectural guidance? Sure, when we have big stories that require my review. Majority of my time is spent taking care of my team. Is my team doing well? Absolutely. We communicate well and aren't shy to help each other out. But being a tech lead my emphasis is quality and making sure that my team is on track with that.
>> Well functioning teams in which people share responsibilities are not rare.
Setting up your team structure with the idea that it "might work out" because "it is not rare that it works out" is pure gambling. What is the definition of not rare anyhow? Probability > 0.02?
>> When a team is not functioning well, assigning a tech lead can potentially make it worse.
If you build your house with the idea of "planning for the best" because "it is not rare that it works out", calling a good architect after you realised that your house is collapsing "potantially makes it worse". That is because the architect potentially recommends you blowing the whole thing up and starting from scratch again.
Anecdote: I've been on more that one team where no leadership emerged, and in fact, leadership type behavior was passively resisted. The reasons for this were many, but essentially it was easier (and I suspect more fun) when individual contributors could do their own thing in their own way, without any concern for the impact on their team members or downstream consumers of the software (help desk, IT, etc.) After all, writing useful log messages, or following a coding convention, or writing an automated test are all tedious and not very interesting compared to coding. These teams (if they can be called that) produced software that had little to no overall design.
A tech lead is not supposed to be a mediator. He/she is supposed to lead and that means understanding the business, the product, and the priorities enough to communicate as simply and as directly as possible. It's not about whether or not you need a "tech lead", it's about whether or not you have anybody, and I mean anybody, that can fulfill those tasks. It might very well be two people, or a team that can drive specific targets, doesn't matter. A "tech lead" is just a title that further complicates matters.
This reads like a person was asked if Tech Leads were necessary, felt the answer was "no", found research to the contrary, and wrote their own counter-argument paper. Do I agree with the premise that tech leads aren't necessary if you have a functional, harmonious team? Sure. But I feel that this paper spent as much time as I did coming to that conclusion, and with just as little consideration of what a tech lead could potentially bring to a team - even one that already works well.
If all that matters is the single team and its work, and the members of the team are both completely committed to the project and technically capable then sure, go without some form of lead.
However in practice there are several very good reasons to have a tech lead. Personally I see that it aligns best to have the lead be your architect, who works across many teams, as they have the ability to most clearly identify when an issue can take a compromise or requires struggling ahead with.
I sometimes wonder, if some Potemkin Tech Lead- all fraud, but scaring the shit out of the big ones, would be good. Sort of challenger in the ring, who constantly keeps the tech giants fighting, afraid to loose there markets.
Of course, such a scam, to make it feel real, they would to have a product at some stage.
I'd even go further to say that yes, you absolutely need a techlead when working on a project that requires a certain domain expertise or the project in question needs to have a coherent technical vision. Otherwise even skilled and well-intentioned teams can pull in different directions and/or build something that is internally incoherent and fragile.
I would say a great reason to have a tech leader is to share the role of PM between the BA and the tech lead. This role can be rotated as far as I'm concerned. A lot of companies I see have far too many PMs overseeing too few projects.
Applying the raft protocol quorum on teams, the +1 can the tech lead. According to the Raft Protocol, A quorum is a majority of members from a peer set: for a set of size n, quorum requires at least (n/2)+1 members.
While I think democracy is the best way to preserve personal liberty, I do not believe it is the way visionary or ambitious plans are conceived and executed.
as a general rule statements asserting that one can do without what is often considered essential are supposed to take the form of "We don't need no stinking {{insert pertinent phrase}}"
Curious what anyone thinks of this theory: each tech team should have two managers. One manages the people and the other manages the projects/technology.
I'm surprised to see how many people think a tech lead is a good idea.
Most teams I have worked on have a manager who used to be an engineer. In terms of direction setting, a final authority amd so forth, it is their call. They talk to their management and other teams and tell us what to work on, but are not involved in the technical day to day and are not micromanaging the details. So I might do the Android client, X does the web API which uses JSON, Y is the DBA designing the database schema, Z does iOS and so forth. It is not ruderless as they can make the final decision.
With a team lead, you have one person on the team doing work who is also doling out work. It can lead to all of the problems mentioned in the arricle.
Also - small, underfunded companies usually can not get a good experienced programmer or administrator. So the hires are the inexperienced types who could probably use a team lead. But the companies are too small to have one. By the time someone has a resume to be good enough to join a company which can afford a larger tech team with a manager, an experienced lead and several somewhat experienced programmers - the need for a lead is much less. Besides, people are naturally going to defer somewhat to a more experienced engineer who has been at the company longer.
I think the bottleneck and bus factor points are key. The tendency would be for the lead to own the most high-visible, business impacting piece of the code base, and dole out less attractive and impactful pieces to others. It can waste time as well - they can assign work but are too busy to really go over it, then after a week you show them what you did, but they did not mention they like things done with MVC, or TDD, or whatever, so then you have to spend another week doing it over. As the article says, they're overloaded and often enough away from the team. Instead of having four or five autonomonous engineers going at full blast, you have one overloaded engineer who hogs more of the critical, business visible code than they can handle, and the other engineer whose time it is to waste. Who are usually not much less experienced than the lead.
The flip side to "design by committee" is that one person is designing every thing! That person is too overloaded to design everything as needed, so you have the non-leads writing code for a week, that will be thrown away until the lead has time to come back around and decide how your project will be designed.
An ex-engineer manager does not have their hand in day to day, and many of these conflicts go away, whereas the needed leadership is there if necessary. I'm surprised people feel otherwise. The alternative to design by committee is often everyone waiting on the one overloaded person who has to design the whole system.
zaphar|9 years ago
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.
brandall10|9 years ago
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.
voidpointer|9 years ago
Jemaclus|9 years ago
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.
posabsolute|9 years ago
I think you voiced the deadlock issue pretty well.
crdoconnor|9 years ago
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.
mnsc|9 years ago
new_hackers|9 years ago
and a "decider" is definitely needed.
bryanlarsen|9 years ago
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.
calchris42|9 years ago
crdoconnor|9 years ago
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.
justinhj|9 years ago
jcadam|9 years ago
ep103|9 years ago
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.
tomca32|9 years ago
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.
skeptic2718|9 years ago
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.
mnsc|9 years ago
unknown|9 years ago
[deleted]
boubiyeah|9 years ago
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.
shandor|9 years ago
- 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.
vidarh|9 years ago
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.
module0000|9 years ago
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
mattsmith321|9 years ago
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.
shortimer|9 years ago
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.
jordan_clark|9 years ago
snarf21|9 years ago
alkonaut|9 years ago
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 .
codingdave|9 years ago
bargl|9 years ago
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.
SmellTheGlove|9 years ago
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.
ser0|9 years ago
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.
heisenbit|9 years ago
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.
doctor_fact|9 years ago
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.
MagicAndi|9 years ago
joaofs|9 years ago
nitrobeast|9 years ago
edblarney|9 years ago
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.
titzer|9 years ago
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.
pandeiro|9 years ago
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?
late2part|9 years ago
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.
[1] http://wiki.c2.com/?SurgicalTeam
hyperbole|9 years ago
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.
stcredzero|9 years ago
hipsterrific|9 years ago
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.
NumberCruncher|9 years ago
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.
jt2190|9 years ago
vsloo|9 years ago
seangrogg|9 years ago
Normal_gaussian|9 years ago
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.
lwhi|9 years ago
Pica_soO|9 years ago
Of course, such a scam, to make it feel real, they would to have a product at some stage.
titzer|9 years ago
FTA:
> So, do we really need a tech lead? - Maybe yes when the conditions are not ideal.
titzer|9 years ago
FrancoDiaz|9 years ago
rjain15|9 years ago
paulddraper|9 years ago
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.
bryanrasmussen|9 years ago
MikeTaylor|9 years ago
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.
dannygarcia|9 years ago
intrasight|9 years ago
zobzu|9 years ago
Ologn|9 years ago
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.
Allower|9 years ago
[deleted]
sapir131|9 years ago
[deleted]