Live data from Hacker News

Ask HN: How to Be a Good Technical Lead?

news.ycombinator.com

91–100 of 178 posts

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

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

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

#92

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…

A big +1 for Becoming a Technical Leader. Foster motivation, organization and innovation in yourself and your team.

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

#93
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…

This. As a relatively new technical lead I'm finding myself coding less and less because of these sorts of things. I don't enjoy that aspect but at the end of the day what my job really is is to make the rest of the team as productive as they can

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

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

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

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

There's some amount of zen to it. Your job is no longer to be the best coder yourself, it's to make everyone else the best coders they can be. I don't have kids yet, but I can imagine some similarities.

On the other hand, once a month or so I hide from the office for an afternoon/night and replace some infrastructure or build an internal tool that's never going to get prioritized. Everyone's happy about it, and you get to feel like a bit of a hero :)

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

#96
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

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

#97
post #73

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.

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, the best thing for me to do is ensure that my team who is doing the actual coding work is as supported as they can possibly be, so they can get the most work done in the shortest time frame.

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

#98
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 really good tech lead will manage you by telling you "do it this way or find another job", but will manage the more sensitive members of the team by gently suggesting what they might want to do, and might manage the more technically-minded members of the team by pointing out the concrete pros and cons of an approach.

The point is that different people need to be managed in different ways. You might want clear direction. I will quit if told "do it this way or find another job". The best managers will interact with you in the ways that get the most out of you, while interacting with me in the ways that get the most out of me. If we were to compare notes, it's doubtful we'd believe we had the same manager.

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

#99
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…

I would like to work for a leader like that.

In that way, I would rather stay there as savy engineer for as long as it holds.

What impresses me the most are,

8. When you need a bad guy/gal, you're it. 9. When you need a good guy/gal, your people are it.

It is natural for good leader to think for engineers. But also thinking in the position of users/productivities wise is important.

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

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

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.

Post reply on HN