
We don't need a Tech Lead - ThundaUp
http://vvgomes.com/we-dont-need-tech-leads/
======
zaphar
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.

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

~~~
vidarh
Great. But we live in reality where lots of teams are not well functioning
some or all of the time, and we still need to get things done even when we
don't have the time, resources or influence to fix the team composition then
and there.

EDIT: I'd also argue that in most well functioning team few decisions needs to
be taken by the team, because the team members know their role well enough and
trusts the others to do the same that everyone is empowered to take decisions.
Unfortunately again, we live in the real world where decision making is often
needed exactly because a lot of the time there are team members we _can 't_
let run rampant and make their own decisions. Or have too much influence.

~~~
crdoconnor
>Great. But we live in reality where lots of teams are not well functioning
some or all of the time

Managers abusing their power causes way more dysfunction than a lack of
authority ever does.

>Unfortunately again, we live in the real world where decision making is often
needed exactly because a lot of the time there are team members we can't let
run rampant and make their own decisions.

That isn't what managing by consensus means. In the real world bad eggs don't
"run rampant", they are reined in by peer pressure, and poor developers very
often _recognize_ that they are poor developers (except when they are
designated as leaders, in which case they usually do 'run rampant').

~~~
vidarh
> In the real world bad eggs don't "run rampant", they are reined in by peer
> pressure, and poor developers very often recognize that they are poor
> developers

I wish I lived in your world, but clearly we live in very different worlds.

~~~
crdoconnor
Which developer ran rampant in your world who wasn't either in authority or
favored by somebody who was?

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

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

~~~
calchris42
A team chatroom... what a nice idea. This was a larger, more enterprise
company. Enough said?

But seriously, I think the answer depends heavily on company and team size.
The role I mention is a lot less critical for smaller teams or when there are
minimal different stakeholders involved.

~~~
crdoconnor
>A team chatroom... what a nice idea. This was a larger, more enterprise
company. Enough said?

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.

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

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

~~~
mnsc
Hey, quit!

~~~
ep103
Nah, I like these people, and helping them grow.

~~~
pc86
More than technical expertise this is what will make you a good lead.

You can learn the tech side. You can't learn to like your team, be a good
person, or enjoy helping people.

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

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

~~~
matwood
It's not about a junior person leading in the decision, it is about deciding
between competing solutions. As the senior person you should see the bigger
picture beyond the current problem solution even if it's an area your
unfamiliar with. The people proposing the solution need to convince you that
their solution is the one to go with.

A good lead will listen to all sides, and explain how a decision is being
made. The goal is that whatever decision occurs that everyone is okay with it,
even if they disagree. This is where people skills (and engineering skills
like cost, consistency, time) are just as important as technical skills.

~~~
mnsc
Sounds like a "Tech Lead" that is a skilled mediator that gets the whole team
onboard the right decision and at the same time a skilled coach that can
explain the relevant part of the bigger picture to the juniors and how it
relates to the decision at hand.

My takeaway from the article is that these two roles in a well functioning
team can be two people and also different people depending on the problem.

------
boubiyeah
Just like design by committee works well right?

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

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

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

edit: added example and hopefully removed typos

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

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

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

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

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

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

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

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

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

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

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

But it is unusual.

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

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

------
nitrobeast
See "conceptual integrity" in The Mythical Man-Month. There needes to be
someone who resolves technical conflicts and keeps the design conherent.

~~~
edblarney
You can have a business / product person effectively prioritize the work -
this is not necessarily a requirement of tech lead.

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

------
pandeiro
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?

------
late2part
Brooks covered this well in Mythical Man Month about the Surgeon, also
detailed in [1].

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](http://wiki.c2.com/?SurgicalTeam)

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

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

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

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

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

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

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

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

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

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

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

------
lwhi
The article comes across as if the author has had beef with a tech lead in the
past, and wishes to back up his position to gain credibility.

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

------
titzer
The conclusion doesn't agree with the title.

FTA:

> So, do we really need a tech lead? - Maybe yes when the conditions are not
> ideal.

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

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

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

------
paulddraper
There's a phrase for that: "design by committee"

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
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}}"

------
MikeTaylor
Let me summarise all the comments:

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

------
intrasight
Why not just call him/her a manager and be done with it.

------
zobzu
we dont need a president we dont need a ceo we dont need...

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

