Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How to Be a Good Technical Lead?

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 178 posts

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

#111

Post by immoderate »

angersock wrote: post #69
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.

Make sure you're getting compensated properly, and make sure it's work that's visible. If you can't do those two things...well, enjoy your burnout. :(

I chuckled, then cried inside reading this, so true.

But there is something to add to this, I got burned out, took a mini-sabbatical and came back a rockstar with a pay raise.

I guess the invisible work became visible in my absence. :-)

An additional side-benefit, I became human again.

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

#112

Post by FLGMwt »

code_sterling wrote: post #109
erlich wrote: post #84

Earlier quoted context omitted.

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.

OP's most important point is that when you're talking to team members, you ask them if it's a good time. Ideally, they'll take that as leading by example and hopefully they'll catch on.

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

#113

Post by immoderate »

robryk wrote: post #85
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…

As far as (3) is concerned, I'd say that it's more important to actually have an "I might be wrong and would want to change my beliefs in that case" attitude and just be honest. It's terribly easy to notice when someone gives a canned "I'm not sure it's the right approach" response while thinking that it's obviously wrong. Noticing that causes many people to feel patronized and/or lose trust in that someone.

I agree. The "I'm not sure it's the right approach" is too easily brushed off.

Open, factual discussion has been my approach. It may bruise some egos, but in my experience, the alternative may be just as bad as rubber-stamping and that just isn't compatible with my ideals.

I also think that people will learn to respect the results of the approach in the long run and that is infectious, promoting real growth.

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

#114

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

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

#116

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

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

#118

Post by hinkley »

nostrademons wrote: post #89
erlich wrote: post #84

Earlier quoted context omitted.

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…

It's important to understand that that when you're a tech lead, your first priority is the productivity of your teammates, not your own productivity. You're responsible for the output of the team as a whole, and if that means you do zero coding, so be it. You should also be coming up with good ways to use productivity tools asynchronously. But remember that the natural impulse for many employees will be "Oh, the boss…

The second most important thing is to make sure the guy with the checkbook agrees with this. Worked myself out of a job once by not doing that, not on my timeline.

Actually both leads did the same thing, and I have no idea how they solved deep technical problems after that since the two of us were handling 75% of them... Here were two expensive Devs not getting features done as fast as anybody else. Look at all the money I saved!

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

#119

Post by hinkley »

spenczar5 wrote: post #54
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…

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

For me, I get the satisfaction of solving the really crazy problems, and seeing how it affects team productivity. Every week you find a way to save the team a manhour or more of frustration, and it adds up quickly.

You also tend to fix bugs and perf issues nobody else is sanctioned to spend that kind of time to tackle.

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

#120

Post by hinkley »

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.

My biggest energy expenditure is usually right at the beginning of a release cycle, or even a week or two before it when our process is working correctly (a good process means a boring release week).

We will have figured out some big infrastructure or design issue we need to fix and between requirements meetings we code like hell. Blocking people during week 1 or 2 goes a lot better than week 8 or 17.

Post reply on HN