
Ask HN: How to Be a Good Technical Lead? - Evgeny
Dear HN,<p>You&#x27;ve been a source of great information before, and I&#x27;m sure I won&#x27;t be disappointed by your advice.<p>I worked as a Software Developer all my career (more than 15 years now), but now I&#x27;m interviewing for a Technical Lead position. I have almost two weeks before the interview.<p>I&#x27;m interested in resources and advice on how to be a good Tech Lead, regarding both technology and people skills. Of course I&#x27;ve seen and taken note on how other leads work, but still feels like a big step for me.<p>The development environment is Microsoft.NET. The main product is a complex software. The main goal would be to develop it so that it is &quot;loosely&quot; built, split into separate modules so that each one can be modified without touching the others.
======
7402
Here are three rules I've followed:

1) If there's an exciting fun task and a messy unpleasant task, assign the fun
task to someone else and do the unpleasant task yourself.

2) If someone on your team wants to ask you a question, always make yourself
available and absolutely pretend that you don't mind being interrupted. But if
you need to ask someone on your team a question, always ask first if it is a
good time for them to talk and offer to come back later if they are in the
middle of something.

3) If someone wants to try an approach that you think is wrong, say: "I'm not
sure that's the right approach, because of X, Y, and Z. However, I've been
wrong before, so I might be wrong about this, too. How long will it take you
to research this approach and see if it works out?" If you're working on a
tight schedule, this may not be practical, but if you want to develop good
engineers in the long run, this can be beneficial for everyone.

~~~
spenczar5
How do you avoid burnout when you're being so self-sacrificial? Seems like
it'd be a big risk.

~~~
7402
Your satisfaction changes from being happy that you've polished some nice bit
of code to being happy that you've shipped a product and successfully run a
group, and gained the admiration of the people on your team and in your
company. Competence is it's own reward.

I learned those rules from observing the behavior of group leaders I've worked
with/for. There have been a few times (over many years) when I've thought to
myself, "My boss is fantastic! I am so amazingly lucky to be working for this
person!!" When that happens, I've asked myself, how does he/she do it? And
tried to figure out the answer.

~~~
S4M
Well, if you keep working on shitty tasks (because you assign them to
yourself) and keep being interrupted, only for your product to depend on the
hazards of the market, you will get burned at some point if what you ship
fails for reasons that don't depend on you or the team and people leave as a
result.

I honestly hope it will not happen because you seem like a great Lead, but you
can't say this scenario is not a possibility.

~~~
nostrademons
Burnout's likely whenever you work really hard on a product that nobody uses,
regardless of what your role at the company was. It sucks to sacrifice hard
for something that doesn't pan out.

The solution to that isn't to only work on the stuff that pleases you, though.
It's to only work for companies that have traction or at least demonstrated
consumer demand. It's the founders' job to validate that there's a reason for
the company to exist; make sure they've actually done their job before you
entrust them with yours.

------
dorfsmay
\- you're going to be part of a lot of meetings, email list etc... Make sure
you flow information down to your team, every day.

\- your main job will be to:

    
    
        - unblock your tam members
    
        - bring them back on track
    

\- consensus is great, but sometimes it doesn't work. Know when you need to
make a decision even if not popular.

\- praise publicly, criticize in private

\- give people a chance (give warnings)

~~~
curun1r
Also:

    
    
      - Be explicit about your expectations for each of the team members. This is a
        discussion, not a declaration.
    
      - Give feedback early and often, both constructive and kudos.
    
      - Your first priority is the productivity of your team, not your individual
        productivity. This means taking the time to help team members that are
        struggling, even at the expense of closing out your own stories on time.
    
      - Don't be afraid to be vulnerable, admit your own failings or tell your team
        that you don't know. Allowing your team to see the decision making process
        when you go through it can be very valuable and is much better than just being
        the guy who has an answer to everything. As a plus, showing your own
        vulnerability will lead to your team showing their vulnerability more readily.
    
      - Even if you've got the answer, sometimes it makes sense to let your team make
        the decision. There are often many right answers. Remember, your job isn't to
        choose a right answer, it's to ensure that the team doesn't choose a wrong
        answer.

~~~
escapee
> Even if you've got the answer, sometimes it makes sense to let your team
> make the decision. There are often many right answers. Remember, your job
> isn't to choose a right answer, it's to ensure that the team doesn't choose
> a wrong answer.

Couldn't agree more. Allowing the team to own decisions as a group goes a long
way toward boosting morale and giving each member a greater sense of pride and
ownership. Sometimes people need subtle guidance away from poor choices, but
often time, allowing people to explore options on their own-even briefly,
they'll often make the right choice in the end.

------
randcraw
What's a good source on becoming a software dev lead? Here are a few
suggestions among the many available:

Brooks' "The Mythical Man Month" is a classic in this space, though I think
its emphasis is less on leadership than the difficulties in software project
management. And the book is rather dated now.

DeMarco and Lister's "Peopleware: Productive Projects and Teams" is also a
classic, and emphasizes interpersonal team dynamics as well as software
project management.

Hunt and Thomas's "The Pragmatic Programmer" is highly regarded and traces the
progression of a software pro from being led to becoming leader.

Mantle's "Managing the Unmanageable: Rules, Tools, and Insights for Managing
Software People and Teams" looks intriguing, but I have no firsthand
experience with it.

I know agile is a big deal these days, but I can't recommend any books that
are specific to doing it well. I'm not really a fan. But in this space, you
might take a look at Rich Sheridan's: "Joy Inc: How We Built a Workplace
People Love". He runs a small creative agile contracting shop that employs a
variety of techniques build and maintain a positive workplace.

In a similar vein is Weinzweig's "A Lapsed Anarchist's Approach to Being a
Better Leader". He's the founder of Zingerman's Deli (in Ann Arbor MI) and is
a very creative force toward making your workplace constructive and engaging.
Not related to software, but full of good ideas.

Weinberg's "Becoming a Technical Leader: An Organic Problem-Solving Approach"
is an oldie but goodie in this space, though it doesn't focus on software but
tech of all kinds.

Finally, I heartily recommend "Code Complete" as an excellent source on how to
program solid/maintainable code, especially if you hope to lead more by
example than command.

~~~
samelawrence
Amazon links for the lazy:

"The Mythical Man Month" \-
[http://amzn.com/0201835959](http://amzn.com/0201835959)

"Peopleware: Productive Projects and Team" \-
[http://amzn.com/0321934113](http://amzn.com/0321934113)

"The Pragmatic Programmer" \-
[http://amzn.com/020161622X](http://amzn.com/020161622X)

"Managing the Unmanageable: Rules, Tools, and Insights for Managing Software
People and Teams" \- [http://amzn.com/032182203X](http://amzn.com/032182203X)

"Joy Inc: How We Built a Workplace People Love" \-
[http://amzn.com/1591845874](http://amzn.com/1591845874)

"A Lapsed Anarchist's Approach to Being a Better Leader" \-
[http://amzn.com/0964895692](http://amzn.com/0964895692)

"Becoming a Technical Leader: An Organic Problem-Solving Approach" \-
[http://amzn.com/0932633021](http://amzn.com/0932633021)

"Code Complete" \- [http://amzn.com/0735619670](http://amzn.com/0735619670)

~~~
owensmartin
Thanks for the shortened URLs. Question: I always obtain those by hitting
"Share" and then copying the link. Is there a better way?

------
edw519
Technology

    
    
      1. Know your apps.
      2. Understand your domain.
      3. Understand your technology under the hood.
      4. Have an idea of how you'd approach each project.
      5. Write detailed technical specs for juniors.
      6. Write general technical specs for seniors.
    
      

People

    
    
       1. Be nice.
       2. Understand you are a resource provider, not a boss.
       3. Get shit done.
       4. Ditch team building gimmicks (see #3 for what's important).
       5. Listen!
       6. Share. Share. Share. 
       7. Teach. Teach. Teach.
       8. When you need a bad guy/gal, you're it.
       9. When you need a good guy/gal, your people are it. 
      10. Know how to run a project as needed.
      11. Know how to run a meeting as needed.
      12. Don't be bashful.
      13. Don't be (too) stubborn.
      14. Stand your ground with users/bosses.
      15. Have fun & foster an environment for others to too.
      16. Always do the right thing.
      17. Never stop being a programmer.
      18. Never stop loving building stuff.

~~~
robryk
These seem to be terribly vague, e.g.:

    
    
      16. Always do the right thing.
    

Some of these I either misunderstand or contradict each other, e.g.:

    
    
       1. Be nice.
       8. When you need a bad guy/gal, you're it.

~~~
vincentkriek
I think number 8 (& nine, because they are heavily related) mean that when
higher ups want to blame someone, they should blame you as technical lead (and
not individual team members) but when someone needs/is going to be praised
make sure it's the team member that deserves it (and not you!). I heavily
agree with this.

------
brandonb
I always recommend the book "Leading Snowflakes" for new technical leads or
engineering managers:

    
    
      http://leadingsnowflakes.com
    

It gives very concrete advice, and it explains the people side in terms of
skills that may already be familiar to you as an engineer -- for example, to
"code review" your management decisions with your teammates.

I'm also a big fan of this video on Autonomy without Chaos, by David
Singleton. David is one of the best engineering managers I've worked with, and
really exemplifies a style of management that's focused on empowering your
team from the bottom up:
[https://www.youtube.com/watch?v=RKgZmHhSD9I](https://www.youtube.com/watch?v=RKgZmHhSD9I)

~~~
pc86
It's always interesting to come across a book relevant to me and find that
it's basically a step-by-step implementation of Nathan Barry's "Authority"
guide to writing a book (I mean that in a positive way, the site is very well
made).

------
dclowd9901
A good tech lead in my mind is someone with a strong technical vision who has
the backbone to see their vision through, but is also very adept at ironing
out the myriad issues that fracture teams. It means being an advocate for the
best technical solution but compromising with the other teams in the org to
meet their needs. It also means being very unpopular as a good technical lead
will give commandments from on high even when they're not popular or well
liked opinions.

Basically your job will be reducing friction by pissing everyone off. So it's
even worse than "if you've done it right, no one will know."

~~~
mopoke
In my experience, a good technical lead won't give commandments from on high.
A good technical lead will consult and facilitate a discussion and mediate
conflict. They will also be directive when the time is right, but only after
having listened and weighed the arguments. They will also be able to explain
the rationale behind those decisions.

~~~
dclowd9901
I've had your tech lead. They're a weenie and nobody ever congeals around
initiatives because they have endless meetings to debate everything all the
time. Sometimes you just need to say, "do it this way or find another job." I
know that's not a popular idea around the democratized millennial coddling of
Silicon Valley, but honestly I'd rather have someone throw down the gavel than
sit through another month of research findings meetings before we finally
decide git is better than svn. Your person isn't a lead, they're a diplomat.

~~~
angersock
_democratized millennial coddling of Silicon Valley_

What does this even mean?

I'm sorry that you felt your time was wasted in meetings, but you seem to
ignore the equally bad outcome of blindly chasing a direction and pissing off
all the devs who actually had some foresight.

~~~
dclowd9901
It means what it means. Do you want me to define each word?

It doesn't mean ignoring devs who have foresight; it means looking at the
options and picking the best one. Not endlessly debating. We agree on the
approach but I think you misread my comment as being a unilateral decision all
the way through. I'm just saying you have to be able to make a tough decision
without waffling and without all of the facts but with enough conviction that
people fall into line with you.

~~~
dasil003
> _It means what it means. Do you want me to define each word?_

The most meaning that can be extracted is about your worldview.

The fact is, there are indecisive weenies, and there are over-confident
blowhards, but most people fall somewhere in between. When you complain about
the culture in general, especially in a get-off-my-lawn manner, it sort of
pushes you into the far end of the spectrum where you start to lose
credibility with your employees because they realize over time the confidence
is not commensurate with the knowledge and expertise.

------
wpeterson
As a tech lead, you're a mixture of manager and lead engineer.

As a manager, you should be clear to represent your team in public in terms of
giving everyone credit for success and taking personal responsibility for
failure yourself.

As a manager, you need to balance what technical work you assign yourself - it
should be a mixture of interesting projects and valuable scutwork. Don't be
the guy who takes all the good work for himself and only delegates work no one
wants.

As a lead engineer, the most valuable thing you can do for your team is to
focus on helping them start things and finish things. Folks do well in the
middle between those two, but most of the wasted time and frustration comes
from not knowing how to begin working productively on things or getting lost
and not knowing how to wrap them up successfully.

As an architect, be able to quickly change altitude when explaining the
behavior of the system or code that you're responsible for. When debugging an
issue with a developer, be able to dive deep into the technical details. When
explaining a schedule or cost estimate, be able to talk about the system at a
high level to the CEO.

------
Jackrabbit1981
As a tech lead your job is to support the developers in your team so they are
as effective as possible. This means:

1\. You must know the code. Say 'no' to meetings - spend most your time coding
2\. Be honest - When you know the answer say so even if that means someone
will have to redo a lot of work. If you don't know the answer, say so (there's
no point pretending to be cleverer than you are - you got the job so you
deserve it, never try to prove your abilities to others) 3\. Remember your job
is to support others so fight for your team's interests even (especially) when
unpopular higher up. 4\. Lead by example - take the shit jobs and write
awesome code. 5\. Let your team members review your code AND TAKE THEIR
ADVICE! 6\. When team members ask you questions attack their problems with the
same determination as you would attack your own 7\. To inspire your team
members you need to be loyal to them. 8\. To inspire your team members you
need to be loyal to the business (often forgotten) 9\. '7' is more important
than '8' 10\. Be the best developer you can be (note the word 'be' not 'appear
to be')

Ultimately, if your team regularly invite you for beers after work and your
boss respects you then you are doing ok. Never, ever assume that 'team lead'
is anything more than a specialist role within the team. Your job is to
support others. That does not make you more special or important. Respect is
earned not given. Being a good team lead is much the same as being a good
developer. If you find the job hard then you weren't really a good developer.
This is why a lot of companies don't externally recruit tech leads, preferring
to recruit from within.

------
dpweb
On management, it's tough to find good info - some is trite leaderhip
strategies. I tend to favor the order writings cause they've stood the test of
time. I keep this one saved and re-read it pretty regularly.

[http://philip.greenspun.com/ancient-history/managing-
softwar...](http://philip.greenspun.com/ancient-history/managing-software-
engineers)

My team is remote, a couple of us been together 10 years and most of us at
least 5 years. My managing style I picked up from my mgrs in the company.
Pretty hands off. Stars are stars and don't need me meddling - so the general
style - let them do their thing.

As far as the average or underperforming employee, I view my job not as trying
to "improve people". I need to empower people. As a leader you have some
influence on your team, but I think that's a bit overblown. A person's
performance is really a result of their mindset.

Their IQ as well. That's important, but some people are just motivated for
excellence, others not. I think the key is - understanding where you have
opportunities to influence this in your team members' and when not.

One thing I did notice - moving to a mgmt position. It is very temptimg the
idea to just get rid of them. It's tough but easier then getting someone truly
hopeless to make the necessary effort to improve.

------
tootie
Some excellent advice here already, but I'll add a few more. One is to avoid
putting development tasks on your own plate that you won't be able to
complete. Your time is now likely to be taxed at 50% or more meaning you'll
have a lot of demands on your time for meetings and such and so you'll find
dev tasks can pile up. Just take on less work for yourself and delegate.

The other one is learning how to wield your authority. You'll now (hopefully)
be invited to or least have visibility into leadership meetings, design
reviews, contract reviews, road mapping. Make sure you voice opinions in terms
of much time tasks will take, which people are needed, what is
feasible/infeasible, if you're signing up for a mission impossible. Stop
saying things are "hard" or "easy" and instead identify "risks".

Notice that almost nobody in this thread is telling you to work on your
technical skills :)

------
mopoke
I get asked this a fair bit so I started to collect a few of my favourite
links together in a blog post: [http://www.andykelk.net/leadership/the-big-
list-of-managemen...](http://www.andykelk.net/leadership/the-big-list-of-
management-and-leadership-resources)

Specifically to new tech lead roles, I'd recommend "Peopleware" and "Behind
Closed Doors"

And a couple of articles specific to your situation:
[http://firstround.com/review/this-90-day-plan-turns-
engineer...](http://firstround.com/review/this-90-day-plan-turns-engineers-
into-remarkable-managers/) and
[https://blog.stackexchange.com/2015/08/developer-turned-
mana...](https://blog.stackexchange.com/2015/08/developer-turned-manager/)

~~~
Evgeny
Thanks, added your blog post to favorites. I lived in Melbourne for 12 years,
still consider Australia my home.

------
Rabidgremlin
Have a read of these essays
[http://97things.oreilly.com/wiki/index.php/97_Things_Every_S...](http://97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_-
_The_Book)

Basically you want to become a "Force Multiplier" for your team, thinking a
few steps ahead, seeing the big picture, guiding everyone past upcoming road
blocks, you need to be able to mentor/help out when it its the fan. And of
course you still need to code ;)

A hard job but endlessly fun

------
rikkus
You will have people who depend on you to allow them to get on with what they
do best. You will likely find that you don't write code any more, but have to
trust others to do a good job - a better job than you might have done, even.
You may not have the time to understand everything they produce. Even so you
need to be able to understand the system at a higher level.

As you say, you have some architectural responsibility. This can seem like a
large weight on your shoulders if you think that it is all your job. Remember
that your developers probably have a huge amount of understanding of the
codebase: Don't be afraid to let them guide you, at least partially, in making
improvements. There may be others at a similar level who have moved elsewhere
in the company who can give you what their plan was for making things
better... They might have been where you are but without your remit.

It can be a role where you get to build stuff (with the hands of others), have
some power and weight behind decison making, also ever-varied and even fun. It
can also be stressful and extremely taxing. Good luck!

------
ABS
I also recommend Patrick Kua's 'Talking with Tech Leads' book:
[http://blog.fogcreek.com/becoming-a-tech-lead-interview-
with...](http://blog.fogcreek.com/becoming-a-tech-lead-interview-with-pat-
kua/)

There is also this interview with him here:
[http://blog.fogcreek.com/becoming-a-tech-lead-interview-
with...](http://blog.fogcreek.com/becoming-a-tech-lead-interview-with-pat-
kua/)

------
NoNotTheDuo
I'm sure you will get plenty of good advice. My own (limited) experience is
that your job is going from a "Individual Contributor" to a "Team Lead". This
requires a pretty drastic change in thinking and is not something to overlook,
or else things will not end up well. This means that there is going to be a
lot of work - much more than you can do by yourself - that's why you have a
team to support you. The primary thing I struggled with in the past was
delegation. Learning to trust (but verify) your team to complete tasks the way
they should be done. I think a lot of people struggle with this and is a
primary reason for not doing well in a new role.

Some other quick things that come to mind are: \- Don't be a gatekeeper of
information. If you learn something that would be a benefit to the team, make
sure they know it and don't have to go through you to get it. That is - get
the team involved.

\- Do take a Crucial Conversations course. You will inevitably have to deal
with conflict within the team and knowing how to approach the situation will
help significantly.

\- Do have 1-on-1's with your team on a regular basis. You determine how
often, but it should be regular and should be a priority for both of you. This
is where you will learn about conflicts within the team, about their career
path and aspirations, about personal issues that they are dealing with, and
will help build trust between the two of you.

Good luck! It's a fun role and comes with it's own challenges, but can be very
rewarding!

~~~
pan69
> The primary thing I struggled with in the past was delegation. Learning to
> trust (but verify) your team to complete tasks the way they should be done.

I would like to add that the above is only possible if you "plan" the work. If
you have expectations of how a certain task should be accomplished then you
should be able to define the task on a detailed enough level so that you "can"
delegate it and that the team member working on it actually has the ability to
complete the task according to your expectations.

There is nothing worse for a team member to be given some vague idea of what
should be done to then afterwards having a big discussion on the expectations,
i.e. how to be a mind reader.

------
austinsharp
Regarding people skills, I always recommend Peopleware[1].

[1] [http://www.amazon.com/Peopleware-Productive-Projects-
Teams-3...](http://www.amazon.com/Peopleware-Productive-Projects-
Teams-3rd/dp/0321934113/)

------
mtabini
In no particular order:

1\. _Listen before you speak._ The people you manage are prone to giving your
opinion more weight than it deserves.

2\. _Give your subordinates problems, not solutions._ People like to own a
task, not to be told what to do; treating them like adults and professionals
empowers them and brings out their potential. Besides, if one person only ever
makes all the decisions, no decision can be better than that one person's
knowledge. If you're afraid of delegation, institute a tight review loop to
ensure that people don't go off-track.

3\. _You 're a facilitator, not a doer._ People will come to you with their
problems, and you _must_ be available at all times to help them through it. As
someone else has pointed out, your productivity is secondary to that of the
team. It's your job, among other things, to ensure that your team has a good
working environment, including good tools, practices, and access to
uninterrupted “flow” time.

4\. _Be aware of politics._ The moment you manage a team, politics become a
part of your daily job. This is not a bad thing—“politics” just means managing
interpersonal relations; it becomes a bad thing when you ignore it.

5\. _Never be in a position to take._ Success belongs to your teammates;
failure is all yours.

6\. _Face problems head-on._ People don't like confrontation, and let problems
fester until it's too late to fix them. Instead, provide frequent one-on-one
time with all your teammates, exhort them to confide in you, and show them
that you're trustworthy. Also see #1.

7\. _Offer clarity._ Explain what you expect others to do in a _measurable_
way to make it possible for both you and your team to understand how well
everyone is doing. You can use a method like OKR[0] to track your goals
internally.

[0] [https://en.wikipedia.org/wiki/OKR](https://en.wikipedia.org/wiki/OKR)

------
LukeB_UK
One thing that I've not seen mentioned is that you don't have to feel like
you're the one that has to answer all the questions, just because you're the
lead. Deferring questions to those you feel may have more specific knowledge
shows that you know where your weaker areas are and where the strengths of
your team are.

This also goes for asking your team questions, don't be afraid to ask them
things you feel unsure on rather than try and power through.

------
philk10
Book: Becoming a Technical Leader by Jerry Weinberg is a good read and one
that I re-read often -
[https://leanpub.com/becomingatechnicalleader](https://leanpub.com/becomingatechnicalleader)

------
skapadia
In addition to everything already said, I reemphasize:

\- allow your team to focus

\- provide just enough structure (and no more)

\- help shorten feedback loops

\- try to remove hurdles to acquiring information

Deep focus unleashes creativity, passion, and great work. I know that's when
I'm the happiest.

------
fenguin
Management is a completely separate set of skills from engineering, and a set
you have to force yourself to learn. The best book I've read on the subject is
Andy Grove's High Output Management [1] -- it talks about how to choose tasks
with the highest leverage, how to run meetings and one-on-ones, how to make
managerial decisions, and how to motivate your team.

[1] Cliffnotes at [http://charles.io/high-output-
management](http://charles.io/high-output-management)

------
SonicSoul
all of these lists sound nice and all, but think back to the people that you
really respect that have taught and influenced you to become who you are
today.

what was the most important part? for me it was the person who was many
degrees smarter than the rest of the team and pushed everyone to be their
best. In my case he was not the most diplomatic or encouraging, hell he yelled
at me a few times (and trust me, i don't appreciate being yelled at even by my
parents). but anyone who was interested in software engineering was in awe of
his skill. He devoured tech books and prototyped things on the train to work
so that he always had good ideas and answers. I was sold right from the
interview where I could tell he just knew his stuff inside and out. My point
is that having the necessary knowledge to actually teach people is so much
more important than all those other things. For most of us that means a lot of
hard work in the trenches during free time. New technology? there goes
Saturday and Sunday. It's the only way to have all the answers to the ones
above you, and the ones you're leading.

Additionally try to get your team the best development/infrastructure tools
money can buy and the best learning resources (such as pluralsight,
egghead.io, all-you-can-read online books subscription)

------
devonkim
I've been a team lead for less than a year but it feels somewhat natural for
me since I've handled leadership roles informally on projects in the past. The
hardest thing is having to delegate when a fire's going on that you know how
to fix but you have to stop trying to uh... "do work"

If you embrace that you're expected to be a force multiplier for the team, you
have the right mentality. But being sensitive to what role you need to play is
critical. Sometimes you need to be a tie-breaker on a heated argument on a
framework decision (lead by wisdom / deference to your respected authority),
perhaps people are in despair and they just need someone that puts everyone at
ease that something's being done right and you should just step in and write a
reference implementation (lead by example).

One thing I would add is that you should find out if there's a program /
product manager present and ask to interview with that person if you haven't.
If there's no such role, you will have to pull triple duty as a product /
program manager potentially by making a lot of strategic decisions probably.
At that level, you might as well be considered a CTO though rather than a
technical middle manager basically.

------
leothekim
A colleague of mine wrote a useful post on this:
[https://medium.com/swlh/good-tech-lead-bad-tech-
lead-948b2b8...](https://medium.com/swlh/good-tech-lead-bad-tech-
lead-948b2b806d86)

------
methodover
OP, I'm sort of curious why they're hiring a tech lead from the outside. Why
hasn't someone taken that position from within the organization? Someone who's
worked on the project, who understands it, who has the moral and political
authority to lead? I worry that your task will be really, really tough. If you
can, in the interview, try and understand the situation over there. Why do
they need an outside lead?

~~~
Vraxx
Hmm.. I didn't necessarily read it as they were hiring from outside
necessarily.. I'm sure it's not uncommon to have interviews internally even if
all of the potential candidates are already employees.

~~~
davnicwil
> I'm sure it's not uncommon to have interviews internally

In fact depending on location it may be legally required - I'm fairly sure
this is the case in the UK (in addition to having to advertise the opening
externally too, even if there's absolutely no intention of hiring anyone
external) - please someone correct me if this is wrong.

Probably the sort of thing early-stage startups can get away with not doing
because they're very under the radar, but it's certainly happened at mid-sized
companies I've worked at.

------
stevewilhelm
Being a team lead means you must manage in three directions:

a) manage the expectations of your boss and shield your team from distractions
and firefights,

b) manage collaboration and dependencies with other other teams, and

c) manage the day to day work of your team.

------
hndl
I've been a Tech Lead for a year now. I'm still learning but some of the
things I've done which I think will help are:

1\. Start by setting up the development environment and getting the software
you'll be working on to run locally. Then, fix a couple of easy to medium
level bug fixes as soon as possible. This is the fastest way to learn what
your team is talking about.

1.5 If you don't understand something that's being said at a meeting ask, but
don't hijack the meeting, make a note and talk to someone who can explain in
more detail.

2\. Think at a high-level -- what is the product supposed to be doing,
abstract away -- some engineers will talk in code -- which you may not
understand early on but interpret what they're saying at a high-level.

4\. Be available and approachable to everyone on the team.

5\. Understand the impact of a bug fix or a feature -- how much QA effort does
it require, what is the operational impact of the work, does it break backward
compatibility etc.

6\. Participate in product meetings and consider designing any new features as
homework so you can better discuss it with the engineering team you're
leading.

Good luck!

 _Edit_

Some DO NOTs:

1\. Do not complain how bad the code base is. No one likes someone new walking
in and saying that at once.

2\. That said, understand what technical debt there is and address it
incrementally. Don't say "we should re-write XYZ."

3\. Do not suggest alternate platforms and frameworks unless is absolutely
makes sense -- this is especially true if the team is big and no one knows
this new framework besides you. You need your existing team to contribute to
and maintain projects.

------
mrlyc
What worked for me was to learn to listen to people, to let them explain the
problem and sometimes find an answer as they were talking. What helped was to
do lots of peer reviews of both code and documentation so the the young ones
could learn from the old ones and the old ones could get new ideas or more up
to date ways of doing things from the young ones. I came to realise that
programming is flow based while leading a team is interrupt driven so I had to
learn how to do context switching quickly and to block out areas of time when
I could do my own programming. I had to learn to help people do their work and
restrain myself from rushing in to do the work myself. And I had to learn that
my team members were people who had lives outside work that affected the work
they did.

For example, I had a team member who was a good programmer but had trouble
coming to work on time. He was getting married so I bought him a clock radio
as a wedding gift. That fixed the problem.

~~~
erlich
Great to hear others have gone through a similar process to the one I am
taking now.

> block out areas of time when I could do my own programming

My biggest challenge is that this time for me is evenings and Sundays
afternoons which eats into the work/life thing.

~~~
mixmastamyk
Maybe take off fridays, and make Sunday a formal work day.

------
endymi0n
Some gems from when I asked something similar 4 years ago...

[https://news.ycombinator.com/item?id=3407643](https://news.ycombinator.com/item?id=3407643)

~~~
dasil003
Nice link. How have the last four years gone for you?

------
grandalf
There is some great advice in this thread. One thing that I've learned is that
different organizations have very different cultures and ways of viewing
technology (and thus technology leadership).

Some are more deadline oriented, some are more bug/problem oriented, and some
are more product oriented, and others care a lot about the price per head of
engineers and would prefer to outsource everything to the third world if they
could ever manage it. A small number of companies care about open source
contribution, attracting top talent, and innovating.

So whoever is hiring you probably has a very clear idea of what they want from
the tech lead, so considering that the goals can be very different, you might
want to ask this question. In my opinion, it won't seem like a naive question
to ask because there are so many facets to people and technology leadership.

------
arnonejoe
I just took a technical lead role with a bay area SAAS company. It's been a
difficult adjustment having worked on contract where all I did was write code.
Now, I sit in a lot of meetings, do code merges, interview/hire developers and
worry about blockers on two Jira boards. Here are a few things you might want
to try;

If their branching strategy is screwed up, help them fix it. You are going in
to a .net shop and there is a good chance they have TFS. There is the ALM
Rangers branching guidelines you can refer to.

Hold a brown bag and show the team how to write unit tests. Many of the junior
developers on the team probably do not understand how to write tests.

Hold a team code reviews.

Initiate common architectural components like a logging or instrumentation
framework.

Take on tiny bites of technical debt.

Push to get your team re-sharper licenses.

------
qznc
I heard about this model from Michael Church, which I like. The idea is that
there are three forces, you need to balance as a manager.

1\. Your team. This is obvious. Acknowledge they are humans. You have to worry
about them. Try to keep them happy and safe.

2\. The Business. This is the cold-hearted inhumane entity which only
considers the free market. You need to satisfy that beast, because otherwise
everybody loses their jobs. It only wants to squeeze the maximum productivity
out of its employees. Often its goal are in direct conflict to your teams
goals.

3\. The Organization. These are all the other people in the company. Your
boss, collegues in other teams, etc. They have their own needs and agendas,
usually different to The Business. Do not forget to consider these.

------
twicezero
My summary, after many years thinking about it, is: Build technical leadership
in depth.

What ever you do, what ever the problem. It's a key-person problem unless your
team can do it.

If you have to tell your team what to do. You are failing, and you need to do
something about it.

The leader sets the vision, makes as start, demonstrates good and keeps people
on track. The coach makes people the great person they want to be. A leader
can use simple coach techniques to grow an resilient team who can work to
build something great.

I've noted down some of my learnings:
[http://www.engineeringandcareering.co.uk/p/leading-and-
guidi...](http://www.engineeringandcareering.co.uk/p/leading-and-guiding-
groups.html)

------
acjohnson55
A couple articles I've seen previously on HN on the subject:

Things I was unprepared for as a lead developer -- [http://dev-
human.io/~pascaldevink/things-i-was-unprepared-fo...](http://dev-
human.io/~pascaldevink/things-i-was-unprepared-for)

Becoming a Tech Lead – Interview with Pat Kua --
[http://blog.fogcreek.com/becoming-a-tech-lead-interview-
with...](http://blog.fogcreek.com/becoming-a-tech-lead-interview-with-pat-
kua/)

------
twicezero
I guess I should really answer your question though :) I collected some
interesting blog posts that I loved and stuck them here

[http://www.engineeringandcareering.co.uk/2013/07/technical-l...](http://www.engineeringandcareering.co.uk/2013/07/technical-
lead-articles-and-blogs.html)

Talking with Tech Leads might interest you also: [https://leanpub.com/talking-
with-tech-leads](https://leanpub.com/talking-with-tech-leads)

------
moron4hire
1) Solicit ideas from everyone. Admit when you don't know the best way.
Attempt to achieve consensus. But be steadfast in the face of majority
opposition when you're sure you do know better.

2) Insist on always doing the right thing. Never compromise your standards or
your ethics [0]. You set the example for everyone else.

3) Treat your customer like an honored guest in your home. Bend over backwards
to understand them. But never let them anywhere near your developers. It's not
good for anyone, _especially_ the customer.

4) Always take the heat for your team (which is easier if you're the single
point of contact for the customer). Always spread credit around.

5) Don't get personally involved with your team [1]. You might have to fire
one of them one day. And your praise will mean more. You can socialize with
the whole team on occasion, but don't do anything that could ever allow the
appearance of favoritism to develop.

6) Trust people to do their work. Give them a chance to succeed... or fail.
But the few that repeatedly and consistently fail to live up to expectations
or even improve, get rid of.

[0] If anyone ever tells you "we might as well do this unethical thing,
because the customer will just get someone else to do it," your reply should
be, "well then, it doesn't have to be me" and walk away. I have done it twice
now and have regretted neither time.

[1] I would like to think this goes without saying, but NEVER EVER EVER make
sexual or romantic advances towards anyone under you. It is extremely
unethical. If there is any chance of something happening, wait until you're no
longer on the same team. Best to wait for them to make the first move, too, if
you're still at a higher authority level after the team change.

------
joshdick
I really enjoyed "Notes to a Software Team Leader: Growing Self Organizing
Teams."

The second half of the book is advice from various tech leads.

~~~
c0achmcguirk
I can't recommend this book highly enough. This is the best book on tech
leadership I've come across and I've read a lot of them.

It underscores the importance of _NOT_ trying to solve problems for your team.
Instead, help your team learn to solve problems on their own--so you don't
become a bottleneck to getting things done.

------
lifeisstillgood
Candour, honesty and therapy. And enforce ridiculously high standards.

Most of us are not as good as we say/imply we are. All of us are terrified
that someone will find out, and terrified that we will slip. So there is often
a refusal to say "I don't know" or a refusal to accept that we might need to
slow down and think about the work we are doing

Your best bet is to make a team that is willing to try something that will
make them look like they don't know what they are doing, send off signals to
"management" that are opposite of what all the other teams are sending. (This
is the other point about a tech lead - you will be compared to the other tech
leads - if they are hiding their faults, you will look bad by comparison as
will your team - how you persuade management this is not the case is hard.

My best suggestion for that is ridiculously high standards - perfect test
coverage, documentation, linting, enforced peer review and more. For every
commit. Enforced by scripts not by you.

------
hamhamed
Good read: [http://dev-human.io/~pascaldevink/things-i-was-unprepared-
fo...](http://dev-human.io/~pascaldevink/things-i-was-unprepared-for)

Discussion:
[https://news.ycombinator.com/item?id=10223472](https://news.ycombinator.com/item?id=10223472)

------
4lejandrito
I would suggest to always put yourself in the shoes of the developers when you
make decisions as a leader. Think about what you would have thought as a dev.

Also try always to explain why you make the decisions you make.

I am a dev and I hate when decisions are made without telling/explaining team
members. I also appreciate a lot when I receive feedback, good or bad.

------
royosherove
[http://5whys.com](http://5whys.com) \- I'd recommend a lot of the advice
there (I'm the owner of that blog so I'm a bit biased).

[http://teamleaderbook.com](http://teamleaderbook.com) is a book that I wrote
for software team leaders

~~~
Evgeny
Well, that's too amazing to be true - as part of my preparation I started
reading "The Art of Unit Testing" just a couple days ago (not that I did not
write tests before, but got a suggestion that the book will help me better
understand dependency injection, inversion of control etc.)

~~~
royosherove
heh! It's a small world!

------
elrikdante
Wow, I can't say I'm surprised at the quality of the answers. I'll add a
couple of my own:

.) be mindful that different members of the team are on different trajectories
skill set wise. (beginner Exs -> juniors -> mids -> seniors -> etc)

I like to pair members with technology whose stability is inversely
proportional to their experience.

More experienced engineers design tighter interfaces in the face of increased
variability in final spec.

Whereas technology that is older will usually have a good breadth of info
either in house or available on Stack Overflow which means the problems (and
communally derived solutions to them) are accessible.

This I've found results in having to clean up less code overall, which helps
build team momentum.

Which is my next point.

.) Team Momentum

You're leading a team, which can be assessed as a set of quantities at any
given point in time (viz. velocity in Pivotal Tracker for instance).

The team however is a dynamic interplay of business expectations (from the
principal, boss, client) technical debt (recurring known issues), and the team
strength (which waxes and wanes based on moral, environment, etc).

Always look for ways to make the lives of the engineers around you easier.

-) build tooling

yeoman generators build tools etc.

enriching internal tooling makes each engineer more effective, which means it
has a compound effect.

    
    
      You can cover a lot of ground just focusing on addressing pain points in your team.
    

]) One last point actually, you're a leader so remember that means you're
expected to have finer grain control over your ego, it helps if you take an
objective view towards the technology that comprises your stack rather than a
predominantly fanatical view.

Congratulations by the way! Regards,

Dante Elrik

------
CraigJPerry
[http://katemats.com/](http://katemats.com/)

------
thecourier
You can get a summary of this discussion here:
[http://sevcode.tumblr.com/post/131264031520/the-30-laws-
of-s...](http://sevcode.tumblr.com/post/131264031520/the-30-laws-of-software-
management)

------
pc86
This seems prescient as I will be starting a new job as a tech lead in a week,
and I actually considered making the same Ask HN post! Same tech stack, no
less, although it's for 2-3 medium-sized projects, not a single large, complex
one.

Best of luck on your interview.

------
scottndecker
Lessons I learned as Tech Lead:

[http://scottndecker.com/blog/2015/04/04/Tech-Lead-Lessons-
Le...](http://scottndecker.com/blog/2015/04/04/Tech-Lead-Lessons-Learned/)

------
digital_ins
At the core of it - you're going to be leading engineers. A lot of how this
leading happens depending on the organizational makeup of the firm you're
going to. (This is super super important!!!).

So figure out the organizational culture before you join. Understanding this
helps you understand the confines within which you will operate (for the first
couple of months, atleast). If you're replacing someone, understand how they
worked, what gaps were there in that person's performance and how you could
cover those. If you're the first tech lead, then figure out what problems
they're having that necessitated the creation of the tech lead position.

------
frankus
I've found this a really good discussion of how tech leads' responsibilities
differ from front-line developers:

[http://madeofmetaphors.com/shapes](http://madeofmetaphors.com/shapes)

------
bloat
This fellow writes some good articles on the subject and will send them via a
mailing list once a week:

[http://marcusblankenship.com/list/](http://marcusblankenship.com/list/)

------
flashman
Read this set of articles: "Things I wish I was told when I became a manager"
[http://fractio.nl/management/](http://fractio.nl/management/)

------
charkubi
[http://www.engineeringandcareering.co.uk/p/the-well-
rounded-...](http://www.engineeringandcareering.co.uk/p/the-well-rounded-
technical-lead.html?m=1)

------
eitally
After you get the job, here's something my old team learned through experience
(failure): modular is good, but in practice, abstracting things to the
theoretical max results is software that none of the developers understand, is
impossible to maintain, and probably doesn't perform any better than if you
didn't "optimize" near as much.

(Source: I was a programmer, then a tech lead, then moved into managing about
100 of them.)

Another tip: it's your job to help the programmers make you look good. You do
that by making them look good. It _should_ be a virtuous cycle.

------
choult
There's plenty of great advice already in the comments, but mine is quite
simple, and quite relevatory when I made the transition to Lead:

Measure your success by your team's productivity and not your own.

------
thejerz
\- Be flexible

\- Prioritize everything

\- Simplify code, processes, and infrastructure at every step

\- Build a well-rounded, emotionally stable team

\- Loosely follow scrum & agile

\- Be realistic

\- Be honest, even when it is inconvenient

\- At the tech lead level, the most important skill is your own psychology.
Hone your personality, establish work-life balance, and take some courses in
positive psych

\- Have an opinion

\- Learn when to talk, when not to talk, when to put it in writing, and when
not to put it in writing

\- Adopt a "good enough, and let's move on" design approach

\- Build strong relationships with non-technical management

------
samstave
You need to read this...

[http://www.altisinc.com/resources/rules/](http://www.altisinc.com/resources/rules/)

------
zschuessler
I would stress this the most: support your team. Give your team the technical
and emotional support they need to do their jobs well and _have fun doing it_.

Some things I've noticed that had the largest impact on employee engagement:

-

1\. Poorly defined development processes heavily impacts morale. Define your
code standards, your process for picking a library to use, how you handle
versioning of code (and which methodologies), how your team should escalate
problems, and expectations of individual team members. Document this in a
place where anyone on the team can view it.

2\. All projects require documentation on how to setup a build. If that
doesn't exist, developers ramped up on the project will loathe the project
from the start (and in some cases, the team lead). From scratch, setup a
project before handing it off. Document everything you had to do.

3\. Onboarding of new team members: make yourself or someone you appoint
available at all times for the first week or so. Document and fix anything the
new team member needed help with. Onboarding is hard, this will be an ongoing
process.

4\. Setup one-on-one meetings. Once every couple of weeks seems ideal in my
experience. Don't have an agenda, but have a few questions you resort to for
filling in quiet spots for the more introverted types. Don't be afraid to ask
hard questions (did you have a problem with Robert in accounting last week?
are you happy with your salary? what would make you happier?). This meeting is
key to employee retention and team happiness.

5\. Allow for an open discussion on all major decisions. Have a tool in place
where anyone can raise problems. If someone can post anonymously to start a
topic, that's ideal. That is where some of the best business growth will take
place.

6\. Read a book on mentorship. Mentor your team. If someone surpasses your
skillset on the team, you've succeeded. I've not read all of Maxwell's books,
but he has some really great insight in the couple I've read:
[http://www.amazon.com/John-C.-Maxwell/e/B001H6NROC/](http://www.amazon.com/John-C.-Maxwell/e/B001H6NROC/)

7\. Become known as an advocate/mediator for those on your team and the
higher-ups. Fight for your team when you need to, and fight for upper
management decisions when you need to. Finding a balance is important, but
never lose trust of those you lead.

-

In many cases, becoming a technical lead also means you are expected to learn
the business side of things. It wouldn't hurt to read business-oriented books.
Anything by Jim Collins is great (Good to Great is a must-read):
[http://www.amazon.com/Jim-Collins/e/B001H6GSHK](http://www.amazon.com/Jim-
Collins/e/B001H6GSHK)

Best of luck, and congratulations on your learning opportunity!

~~~
ramtatatam
\+ for mentioning on-boarding and implications, another + for mentioning open
discussions on things that matter

------
erlich
I think it can be summed up as "code less".

I want to stress that this is much more easily said than done.

\- A lot of programmers gain immense satisfaction from writing nice code, and
getting into "flow". There will be less of this, and you have to rewire your
reward system and vicariously experience this through your team. If you
already get more satisfaction from shipping and having users use your
product/module/apis rather than how elegant your code or apis are, then you
are heading in the right direction.

An earlier comment on this page sums up the goal:

> Your satisfaction changes from being happy that you've polished some nice
> bit of code to being happy that you've shipped a product and successfully
> run a group, and gained the admiration of the people on your team and in
> your company. Competence is it's own reward.

\- You must prepare yourself to watch others implement things you would love
to do yourself, in a less-optimal, and less-clean way than you might have. Its
harder if the codebase is your baby that you wrote from scatch. Instead of
coming out of a project with new skills, new familiarity with modules, code
that you could open-source, satisfaction from having written nice modular,
maintainable and testable code, you will only have the satisfaction of the
hitting a deadline.

\- Coding less allows more time for you to ask your team what they need, think
about what they need but don't realize, and get that for them.

\- Giving feedback is an art. You want to keep a positive, upbeat repore with
your colleagues. If you empathize too much about how the developer will feel
when you deliver criticism you will end up doing it less and not being as
honest. Finding the right words will make it easier for yourself to deliver,
and will create less tension.

\- Hiring people like yourself who write code similar to you will make life
much easier - but often you have to money-ball your team, and make do with
what you have.

\- Creating an atmosphere where employees can all talk about problems, and
personal mistakes, without feeling judged by their peers is important.
Encourage everyone to acknowledge their failings, and identify improvements.
"What did everyone learn this week/sprint? What could you do better?". As soon
as employee holds back, everyone will start because they will fear they are
underperforming. If someone is falling behind, others in the team should be
thinking how they can assist their colleague, rather than looking at it as an
opportunity to stand out. Standups are great for this. Make sure its not only
one person asking for help at the standup.

------
yareally
1) Learn as much about the people on your team as you can. That can be
sometimes hard while at work, so I end up going out to lunch with them or
occasionally grab a beer afterwards.

2) While at lunch or after work, my team and I end up talking about random
stuff, but it pays off when you can sense if someone is having a bad day/week
or is stuck on a particular issue. Also helps to build mutual trust with your
team and keeps the communication lines more open.

3) It's hard to sometimes tell how well you're doing as a technical lead, but
one way I do it is by how often people come to me for help to things that
can't easily be Googled. If developers are seeking out your help, they trust
you and consider you reliable source of help.

4) If it comes down to doing more work or helping your team. Always pick your
team. Helping them will likely be more productive overall than any amount of
additional work you take on yourself.

5) Every developer is different. Recognize that when communicating with them
and approach each differently. A true tech lead isn't a managing position,
it's a mentoring/leadership role while still being a developer.

6) Be concise. Your team needs help, but they have work to do. Save the long
explanations for later. That doesn't mean you should avoid the "why" in your
responses, just don't make your answers a monologue.

7) If asked by a team member why you think a particular approach or solution
is correct, give them an explanation. I always feel if I can't explain a
particular subject, then I don't really know it that well and may be
incorrect.

8) You don't always have to be correct. Admitting you aren't when you can't
explain something reflects better than all other responses you could give your
team.

9) Making yourself available to your team for assistance is also a must as
already mentioned. Everyone communicates differently, so adjust to your team
as much as possible.

10) Don't deter someone outright from pursuing a potential solution, even if
you're pretty certain it won't work. Instead saying no, apply some rubber duck
debugging[1] and talk them through their idea aloud. If all goes well, they'll
either realize it's not feasible and learn the value of communication or
they'll convince you that it will likely work. If they win me over, I'll try
to help them devise a way to small way to test their idea further.

[1]
[https://en.wikipedia.org/wiki/Rubber_duck_debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging)

------
tlinton
A great technical lead is a great therapist.

They're kind, supportive and know how to focus your energy to help get a
really difficult task done. They don't dictate, they don't prescribe, they
listen.

Your job as a tech lead is to listen and help figure out a way to make
testing, compiling, deployment, support, and escalation easier.

------
brandall10
Many times a tech lead isn't about being the smartest or most knowledgable
person in the room - it's about getting your team, your boss, other
departments on board with a plan and executing. In some environments it may be
that you have to be the sharpest depending on the team you're given, but often
times it's best to be the most judicious and compassionate. Think of it more
like being a mini-manager - perhaps 30% management (where you're like an
extension of your supervisor) and 70% software. Also be prepared to bring your
boss into issues you may have with external teams/organizations, but try to
shield your team itself from that activity. Be prepared to handle considerably
more email, process work, signing of documents, etc.

I'm going to share a personal story - it might not have much directly
actionable advice, but it may give you some thought on how to approach this
strategically.

I spent about 15 years as well on windows software for enterprise health care
systems (starting back in VS6 C++ days back in the late 90s) before jumping
ship to do Rails development a few years ago.

Right around the 10 year mark in my career I was a run of the mill sr. dev...
the only 'lead' experience was on a couple projects, rarely with more than
another dev and most of the time solo. I just never really had much confidence
in my skill set as a whole, esp. when it came to telling other devs what to
do. In 2009 as a 33 year old I felt pretty deflated and was considering a
career change. One thing I caught wind of was this book called "The Passionate
Programmer" by Chad Fowler (not related to Martin). It was ~200 pages, and it
was separated out into 50 or so little chapters of tidbits of mostly, well,
soft skills, but also general career advice. I absolutely loved it and
finished it in an evening.

In short order a whole bunch of things about my working style changed, not
only my demeanor working with other engineers, but key key people in other
departments in the projects I worked on(ie. QA, System Engineer,
Documentation, Product, Project Management). Ultimately I realized at that
particular organization the biggest problem was that departments were silo'ed
a bit too much, and as a result schedules slipped because coordinating
resources was always a challenge.

Six months after reading the book I was given a lead role on a medium sized
project at that company (had 6 engineers on the team and about 20 people
working on it for 9 months, ~$15M per annum, 300k LOC over the prior 10
years). One of the engineers who reported to me during on that project was one
of the 2 Fellow Engineers at the company (3 titles above mine!). It went well,
and my next review had a recommendation from my supervisor to go into
management. I politely declined and a few months later was promoted to a
principal dev.

One of the reasons why I believe this worked so well was 1) I did
underestimate my skills as a whole - I was not the best, but I was certainly
good enough that my suggestions held weight and I felt ok with admitting to
things I didn't know and delegating 2) I had, as you say, seen other people in
this position and already knew what success and failure looked like. I wasn't
just given a position as a lead, I had assumed it to some degree on another
project I was on at the time (not entirely and not to usurp the authority of
the actual lead, but I just became helpful on things that needed to be done
but were getting brushed aside, esp. things that were important to other
departments). And as such, people started to pay attention to what I was
saying.

It sounds like you think it's slated toward being an architect. It can be, but
many times it really isn't - you may want to delegate that overall to the
stronger members of your team and help them work through the process - be the
person who asks questions and helps poke holes. Give the most challenging work
to your brightest people. Isolate the more 'dangerous' members from mission
critical stuff, and if they have the passion and smarts but they're just a bit
misguided give them a nudge of encouragement in the right direction and
challenge them accordingly. Pay attention to your devs' key strengths and
delegate accordingly, but also remember to provide a degree of work that is
challenging and exciting.

So that's my advice - check out that book. It's a quick read. It is about 6
years old now but the advice is mostly generic. Try to put some of it to
effect in your current job... assume the role where you can. Even if it's just
a week or so, I think the best practice is actually trying it out in real
life.

~~~
Evgeny
Thanks a lot. I'm sure I read the book a few years ago ... will have closer
look to make sure I'm not confusing it with "The Pragmatic Programmer".

~~~
brandall10
Absolutely. Best of luck!

------
pgbovine
i enjoyed reading the book Team Geek [http://www.amazon.com/Team-Geek-
Software-Developers-Working/...](http://www.amazon.com/Team-Geek-Software-
Developers-Working/dp/1449302440)

~~~
dochtman
I liked Michael Lopp's (also known as Rands, from Rands in Repose) book,
Managing Humans, when I first became a team lead 18 months ago.

[http://www.amazon.com/Managing-Humans-Humorous-Software-
Engi...](http://www.amazon.com/Managing-Humans-Humorous-Software-
Engineering/dp/1430243147/ref=sr_1_1?s=books&ie=UTF8&qid=1444939385&sr=1-1&keywords=michael+lopp)

------
Amio
Most of all, make your contribution visible to your leader, or to KPI, or to
anything evaluating your contribution. If no one knows your great works, It
worth nothing to your career.

First, know how they evaluate your works.

------
rickette
Checkout
[https://leanpub.com/becomingatechnicalleader](https://leanpub.com/becomingatechnicalleader)

------
mirceal
also worth reading: [http://www.amazon.com/Driving-Technical-Change-Terrence-
Ryan...](http://www.amazon.com/Driving-Technical-Change-Terrence-
Ryan/dp/1934356603)

------
z3t4
You lead the way and when you have half of them with you, the rest will
follow.

------
scardine
Do you have a few kittens? Managing developers is like herding cats.

The truth is you don't really have real control.

------
marcuscreo
Great question! I just wrote an article on this very topic here...

[https://www.linkedin.com/pulse/real-work-management-
marcus-b...](https://www.linkedin.com/pulse/real-work-management-marcus-
blankenship?trk=pulse_spock-articles)

If you're looking for books, I recommend Johanna Rothman's "Behind Closed
Doors" as a great book about leading software teams.

Good luck!

------
locopati
Learn to listen. To your team members. To your peers. To your boss(es). To
people in other departments. Not just to their words, but their body language,
their activities, the way they carry themselves in meetings.

I am constantly learning from the people around me how I can be a better
manager. If I see something that catches my attention about the way someone
handles something, I aim to bring that into my own toolkit.

------
a3voices
Just try not to get fired.

~~~
dasil003
Come on guys, I know we don't generally appreciate humor here, but this is
pretty fucking funny.

