HN Explorer

Ask HN: How to Be a Good Technical Lead?

520 points by Evgeny ↗ HN
Dear HN,

You've been a source of great information before, and I'm sure I won't be disappointed by your advice.

I worked as a Software Developer all my career (more than 15 years now), but now I'm interviewing for a Technical Lead position. I have almost two weeks before the interview.

I'm interested in resources and advice on how to be a good Tech Lead, regarding both technology and people skills. Of course I've seen and taken note on how other leads work, but still feels like a big step for me.

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 "loosely" built, split into separate modules so that each one can be modified without touching the others.

177 comments

[ 3.4 ms ] story [ 67.5 ms ] thread
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.
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)

chetanahuja
your main job will be to:

- unblock your tam members

- bring them back on track

Ditto. Note that the unblocking/course-correcting role is the real job. Depending on the size of the team, you may or may not want to be involved in architecture/design of minor projects that crop up all the time (things that might take a week or two to develop). Your team should trust and rely on your advise/insight around technical issues. Writing code yourself would be a secondary role though if it's a smaller team (2-3) people, you'd be advised to pull your weight there as well.

And yes, that set of responsibilities means that this would be more than a full-time job. You should know that going in. If you're more inclined to a strict 40 hour week, you'd probably better off declining this offer.

hiram112
And yes, that set of responsibilities means that this would be more than a full-time job. You should know that going in. If you're more inclined to a strict 40 hour week, you'd probably better off declining this offer.

Exactly. In my experience, team lead of smaller teams (less than 6-8 developers, testers, etc.) just means 50% more work for the same pay and status. You are not a true manager in your superiors' eyes.

Also, it is rarely a way to move up the ladder. In our business, changing companies every few years is the only way to get promotions and raises.

Unless the job comes with the ability to purchase resources, make hiring and firing decisions, while also being paid more, team lead is not a position I volunteer for anymore. It's better to use the extra time for your own projects / networking.

hluska
This is one of the more useful set of management tips that I have read.

First, thanks for adding this information. Second, congratulations on keeping it so concise. Excellent job.

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.
burkemw3
> Your first priority is the productivity of your team

I agree! The grandparent talks about unblocking team members and bringing them back on track. These little tweaks happen frequently as part of team productivity.

Other things also affect the team's productivity though! Consider how productivity will be impacted with various paths forward (Should we implement feature A or B, should we implement it with X or Y?)

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.

[deleted]
(comment deleted)
joe_the_user
- Don't be a part-time developer while managing. Managers who fight for code with the people they're managing are the worst.

- You are there to filter the more outrageous demands of other department into something manageable rather than just forwarding everything people say down to the department.

- Don't quibble team member's estimates for time required to implement feature X. Just forward that to management.

- Encourage each team member's professional development. Encourage members to mentor each other. If someone screws up, it's possible they didn't have the tools to succeed, have them investigate what they need.

mizchief2
With your experience you will likely know the right course of action to take immediately, but will still have to reach consensus with the team to keep them engaged as solving the problem is the fun part.

Get good a steering the conversation to your solution vs. just handing it down. You know the whole making it seem like it was their idea thing.

If your team perceives you as an authoritarian, they will be afraid to make any decisions on their own and you will become a constant roadblock.

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/

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

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

[deleted]
(comment deleted)
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

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).
Rabidgremlin
Have a read of these essays http://97things.oreilly.com/wiki/index.php/97_Things_Every_S...

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

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.

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!

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

"Peopleware: Productive Projects and Team" - http://amzn.com/0321934113

"The Pragmatic Programmer" - http://amzn.com/020161622X

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

"Joy Inc: How We Built a Workplace People Love" - http://amzn.com/1591845874

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

"Becoming a Technical Leader: An Organic Problem-Solving Approach" - http://amzn.com/0932633021

"Code Complete" - 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?
Malic
DeMarco and Lister's "Peopleware: Productive Projects and Teams" was published way back in 1987 with 2 new editions over the years.

And even the first edition untouched is still completely relevant.

While its focus is "getting teams to work well together and develop good software", I think it has excellent viewpoints and advice for any workplace where people use their brains for a living, regardless of what the company does.

I'd also like to add "Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams" by Steve Maguire.

nzoschke
A big +1 for Becoming a Technical Leader. Foster motivation, organization and innovation in yourself and your team.
euske
I highly recommend "The Psychology of Computer Programming" by Weinberg to this list. One of the best books about programming that I've ever read.
Evgeny
I'm so happy that I've read four of the mentioned above - the first three and the "Code complete". Will try to do some more reading in the nearest days.
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.

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

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.

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 :)

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.

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.