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.
Ask HN: How to Be a Good Technical Lead?
171–178 of 178 posts
Re: Ask HN: How to Be a Good Technical Lead?
#172Here 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…
Re: Ask HN: How to Be a Good Technical Lead?
#173Here 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…
I disagree on #1. There's no need to be a martyr as a tech lead. Assign the tasks based on who is the best person to get it done (based on competency, knowledge of affected components, etc.). Treat your employees like adults. They don't need to be coddled, they know there are unpleasant tasks sometimes. Just try to be fair and ensure that your employees are not getting too such tasks to the point where they feel bogg…
Why would they answer honestly and not what they believe is your expectation? I know I have been in lots of situation where I chose the nice over the honest answer and I don't think I am special here.
Re: Ask HN: How to Be a Good Technical Lead?
#174Here 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…
Re: Ask HN: How to Be a Good Technical Lead?
#175Earlier 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.
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?
#176First, know how they evaluate your works.
Re: Ask HN: How to Be a Good Technical Lead?
#177What'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…
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…
Re: Ask HN: How to Be a Good Technical Lead?
#178http://5whys.com - I'd recommend a lot of the advice there (I'm the owner of that blog so I'm a bit biased). http://teamleaderbook.com is a book that I wrote for software team leaders
Well, that's too amazing to be true - as part of my preparation I started reading "The Art of Unit Testing" just a couple days ago (not that I did not write tests before, but got a suggestion that the book will help me better understand dependency injection, inversion of control etc.)