Ask HN: How to Be a Good Technical Lead? • Hacker News Board

Re: Ask HN: How to Be a Good Technical Lead?

#101

Post by Jackrabbit1981 » Fri, Oct 16, 2015, 12:29 AM UTC

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.

Re: Ask HN: How to Be a Good Technical Lead?

#102

Post by escapee » Fri, Oct 16, 2015, 12:29 AM UTC

curun1r wrote: post #37

dorfsmay wrote: post #4

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

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…

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

Re: Ask HN: How to Be a Good Technical Lead?

#103

Post by greenyoda » Fri, Oct 16, 2015, 12:51 AM UTC

S4M wrote: post #80

7402 wrote: post #61

Earlier quoted context omitted.

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 t…

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 po…

This happened to me, and is one of the reasons I quit being a manager and went back to being a developer. The product didn't actually fail, but the daily stress of constant interruption and long hours of slogging through thankless shitty tasks eventually wore me down.

Also, I regret not having delegated some of those boring and shitty tasks, since they would have developed skills in my staff (like debugging under difficult environments) that would have made them stronger and more independent developers.

Re: Ask HN: How to Be a Good Technical Lead?

#104

Post by dclowd9901 » Fri, Oct 16, 2015, 12:53 AM UTC

angersock wrote: post #71

dclowd9901 wrote: post #62

Earlier quoted context omitted.

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 resear…

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.

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.

Re: Ask HN: How to Be a Good Technical Lead?

#105

Post by oliyoung » Fri, Oct 16, 2015, 1:09 AM UTC

sokoloff wrote: post #100

spenczar5 wrote: post #54

Earlier quoted context omitted.

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

Be very judicious about how often you put your own delivery on the critical path of the project (or sprint, or other unit of work.) It shouldn't be very often.

Yep. You should never ever be on the critical path

1. If you don't deliver and you hold up the schedule, you lose authority as a leader because really … if you can't, then you can't expect others. 2. You WILL be diverted to other tasks that will hold you up

Knowing #2 and still causing #1 is fatal.

Re: Ask HN: How to Be a Good Technical Lead?

#106

Post by euske » Fri, Oct 16, 2015, 1:12 AM UTC

randcraw wrote: post #20

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 t…

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.

Re: Ask HN: How to Be a Good Technical Lead?

#107

Post by alttab » Fri, Oct 16, 2015, 1:42 AM UTC

tomphoolery wrote: post #97

matwood wrote: post #73

Earlier quoted context omitted.

1-5 are great and what I do. The hardest one for me is 2. I have so many things to get done, but always remember keeping your team on track is your number 1 priority.

It's hard for me as well, but as I've lead more teams I've learned how to delegate more. It's okay to delegate hard tasks to more advanced members of your team, if it leaves you open for more questions and the ability to support others. As far as the client is concerned, I'm the representative for all of the backend work that's been done, so according to them it is I who take ownership for the whole thing. Therefore,…

Ownership. Delegation. Support.

Re: Ask HN: How to Be a Good Technical Lead?

#108

Post by msloc016 » Fri, Oct 16, 2015, 1:58 AM UTC

matwood wrote: post #73

adamrmcd wrote: post #68

Earlier quoted context omitted.

I follow 1..3 daily. I also have this. 4) Be humble. Redirect upstream praise for your team's work onto your team directly (away from yourself). Accept criticism for your team's work directly onto yourself. 5) Expect to do less actual programming, but still keep ownership of one or two components (UI, DB, etc) for up to 1/3 of your time. This helps to maintain an ear-to-the-ground on ongoing features/bugs and to comm…

1-5 are great and what I do. The hardest one for me is 2. I have so many things to get done, but always remember keeping your team on track is your number 1 priority.

I have to remind myself that no matter how productive I am, I can't be more productive as a whole team of smart engineers. One of my main jobs as a tech lead is an enabler. If I can remove blockers and try to cultivate experts then things get done.

I do about 30% helping and answering questions. 30% meetings and planning. 30% code reviews. 10% coding.

Re: Ask HN: How to Be a Good Technical Lead?

#109

Post by code_sterling » Fri, Oct 16, 2015, 2:07 AM UTC

erlich wrote: post #84

7402 wrote: post #53

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…

Note of caution on point 2. If you still do a lot of coding, this can really impede on your productivity, and break you out of any flow state. When an employee asks you a question, you will feel like you don't want to be abrupt and will find yourself taking a few minutes each time. I find a lot of the time employees will come with questions they could have asked over slack/chat that would have not broken my flow, and…

I wouldn't recommend this. I have over 15 years as lead dev experience, and this isn't good advice. This tells your team that your time is more valuable than their contribution. No matter how good you are, you can't do as much as your team if they are properly guided, supported, and motivated.

Re: Ask HN: How to Be a Good Technical Lead?

#110

Post by c0achmcguirk » Fri, Oct 16, 2015, 2:13 AM UTC

joshdick wrote: post #30

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.

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.