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

131–140 of 178 posts

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

#131

Post by robryk »

edw519 wrote: post #91

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

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.

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

#132

Post by moonpompey »

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…

One of your long-term responsibilities is to grow your team so everyone is more effective in the future. To elaborate a little more on #1, the primary tool at your disposal is the ability to allocate work. It's important to allocate work in ways that are both achievable and meaningful to your team's growth. This means two things:

(1) Breaking projects into small enough chunks that they can be taken on by a single engineer.

(2) Coalescing small tickets into bigger projects so that they can be taken off in a larger chunk.

It's tempting to give all the small tickets to junior engineers, especially close to a release, but occasionally giving people projects that at the 90th percentile of their capabilities both gives them skill growth and gives them something to point to as an accomplishment come performance review-time.

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

#133

Post by Evgeny »

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…

Just wanted to thank everyone who contributed - don't know where to put this comment for everyone to see. :)

Posted before going to sleep, and didn't expect that many comments at all. What a way to start the day. Still reading.

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

#135

Post by mixmastamyk »

dclowd9901 wrote: post #104
angersock wrote: post #71

Earlier quoted context omitted.

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…

Yes, and of course there is a middle ground between "my way/highway" and endless discussion.

Debate for an hour (even two?), ask everyone their opinion, and then make a decision. Revisit in a month or three.

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

#136

Post by yitchelle »

dclowd9901 wrote: post #62
mopoke wrote: post #48

Earlier quoted context omitted.

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.

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…

A good tech lead _knows_ when to step in to make the hard decision without lots of discussion, but he also _knows_ when to take the soft road to facilitate a fruitful discussion and to arrive on a consensus.

Otherwise, if the only tool you have is a hammer, everything will look like a nail.

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

#137

Post by dasil003 »

dclowd9901 wrote: post #104
angersock wrote: post #71

Earlier quoted context omitted.

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…

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

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

#138

Post by mixmastamyk »

erlich wrote: post #88
mrlyc wrote: post #3

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

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.

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

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

#140

Post by jpatokal »

robryk wrote: post #131
edw519 wrote: post #91

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

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.

I think 8 means that if you need to find someone to blame, you're it. (Whereas 9 means that the praise goes to your team, not you.)
Post reply on HN