Live data from Hacker News

Ask HN: How to Be a Good Technical Lead?

news.ycombinator.com

121–130 of 178 posts

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

#121

Earlier quoted context omitted.

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.

When my coworkers bitch about being underpreciated I tell them to take a week off and find out if they're right. if everybody isn't on the same page it's time to move on.

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

#124
On management, it's tough to find good info - some is trite leaderhip strategies. I tend to favor the order writings cause they've stood the test of time. I keep this one saved and re-read it pretty regularly.

http://philip.greenspun.com/ancient-history/managing-softwar...

My team is remote, a couple of us been together 10 years and most of us at least 5 years. My managing style I picked up from my mgrs in the company. Pretty hands off. Stars are stars and don't need me meddling - so the general style - let them do their thing.

As far as the average or underperforming employee, I view my job not as trying to "improve people". I need to empower people. As a leader you have some influence on your team, but I think that's a bit overblown. A person's performance is really a result of their mindset.

Their IQ as well. That's important, but some people are just motivated for excellence, others not. I think the key is - understanding where you have opportunities to influence this in your team members' and when not.

One thing I did notice - moving to a mgmt position. It is very temptimg the idea to just get rid of them. It's tough but easier then getting someone truly hopeless to make the necessary effort to improve.

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

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

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…

5th is VERY must, after a while the team feels you are just another non-coding hairy pointed manager. The problem is developers will have hard time to accept your suggestions questioning your judgement subconsciously and consciously. If you keep telling them that you were once a hard coder, i am sure that won't help at all. so always make sure 1/3 rd time is spent in coding.

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

#126
I just took a technical lead role with a bay area SAAS company. It's been a difficult adjustment having worked on contract where all I did was write code. Now, I sit in a lot of meetings, do code merges, interview/hire developers and worry about blockers on two Jira boards. Here are a few things you might want to try;

If their branching strategy is screwed up, help them fix it. You are going in to a .net shop and there is a good chance they have TFS. There is the ALM Rangers branching guidelines you can refer to.

Hold a brown bag and show the team how to write unit tests. Many of the junior developers on the team probably do not understand how to write tests.

Hold a team code reviews.

Initiate common architectural components like a logging or instrumentation framework.

Take on tiny bites of technical debt.

Push to get your team re-sharper licenses.

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

#127
all of these lists sound nice and all, but think back to the people that you really respect that have taught and influenced you to become who you are today.

what was the most important part? for me it was the person who was many degrees smarter than the rest of the team and pushed everyone to be their best. In my case he was not the most diplomatic or encouraging, hell he yelled at me a few times (and trust me, i don't appreciate being yelled at even by my parents). but anyone who was interested in software engineering was in awe of his skill. He devoured tech books and prototyped things on the train to work so that he always had good ideas and answers. I was sold right from the interview where I could tell he just knew his stuff inside and out. My point is that having the necessary knowledge to actually teach people is so much more important than all those other things. For most of us that means a lot of hard work in the trenches during free time. New technology? there goes Saturday and Sunday. It's the only way to have all the answers to the ones above you, and the ones you're leading.

Additionally try to get your team the best development/infrastructure tools money can buy and the best learning resources (such as pluralsight, egghead.io, all-you-can-read online books subscription)

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

#128

Earlier quoted context omitted.

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

There is so much zen to it. I've gone from being the single developer sitting in a room with the founder and the creative director building a product from scratch to managing a technical team of 15 at the same company, with another couple dozen employees in other departments.

The difficulty of running a large technical team is all about managing coordination and communication overhead. You need to build a culture where interruption is frowned upon, but at the same time you need to ensure that knowledge isn't siloed. The balance is very very important, and the means of achieving it are much more art than science. I suppose I could throw up my hands and concede I'll never be able to regain the focus to be a good individual contributor, but I rebel against that inclination on the (perhaps selfish) belief that going full management would put me out of touch with the people I'm managing.

In any case, it is possible to both manage and write code, but it requires an incredible amount of discipline to truly embody the nature of each job and do them well side by side.

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

#130
Candour, honesty and therapy. And enforce ridiculously high standards.

Most of us are not as good as we say/imply we are. All of us are terrified that someone will find out, and terrified that we will slip. So there is often a refusal to say "I don't know" or a refusal to accept that we might need to slow down and think about the work we are doing

Your best bet is to make a team that is willing to try something that will make them look like they don't know what they are doing, send off signals to "management" that are opposite of what all the other teams are sending. (This is the other point about a tech lead - you will be compared to the other tech leads - if they are hiding their faults, you will look bad by comparison as will your team - how you persuade management this is not the case is hard.

My best suggestion for that is ridiculously high standards - perfect test coverage, documentation, linting, enforced peer review and more. For every commit. Enforced by scripts not by you.

Post reply on HN