Ask HN: How to Be a Good Technical Lead?

I think it can be summed up as "code less".

I want to stress that this is much more easily said than done.

- A lot of programmers gain immense satisfaction from writing nice code, and getting into "flow". There will be less of this, and you have to rewire your reward system and vicariously experience this through your team. If you already get more satisfaction from shipping and having users use your product/module/apis rather than how elegant your code or apis are, then you are heading in the right direction.

An earlier comment on this page sums up the goal:

> Your satisfaction changes from being happy that you've polished some nice bit of code to being happy that you've shipped a product and successfully run a group, and gained the admiration of the people on your team and in your company. Competence is it's own reward.

- You must prepare yourself to watch others implement things you would love to do yourself, in a less-optimal, and less-clean way than you might have. Its harder if the codebase is your baby that you wrote from scatch. Instead of coming out of a project with new skills, new familiarity with modules, code that you could open-source, satisfaction from having written nice modular, maintainable and testable code, you will only have the satisfaction of the hitting a deadline.

- Coding less allows more time for you to ask your team what they need, think about what they need but don't realize, and get that for them.

- Giving feedback is an art. You want to keep a positive, upbeat repore with your colleagues. If you empathize too much about how the developer will feel when you deliver criticism you will end up doing it less and not being as honest. Finding the right words will make it easier for yourself to deliver, and will create less tension.

- Hiring people like yourself who write code similar to you will make life much easier - but often you have to money-ball your team, and make do with what you have.

- Creating an atmosphere where employees can all talk about problems, and personal mistakes, without feeling judged by their peers is important. Encourage everyone to acknowledge their failings, and identify improvements. "What did everyone learn this week/sprint? What could you do better?". As soon as employee holds back, everyone will start because they will fear they are underperforming. If someone is falling behind, others in the team should be thinking how they can assist their colleague, rather than looking at it as an opportunity to stand out. Standups are great for this. Make sure its not only one person asking for help at the standup.

I'm not going to take the inter-generational warfare bait :). But I agree with what I think is your main point.

My natural tendency is to want consensus. I think that's worth attempting within a reasonable time-frame. But after some discussion, eventually a decision needs to be made.

Many decisions are reversible at a very small cost. Sometimes making the wrong decision, soon, then correcting it, soon, wastes no more time and resources than not deciding at all. Sometimes it's even preferable for morale.

Having everyone row together in the wrong direction, then change course, isn't ideal. But at least everyone is rowing in the same direction and feels like a real team. Often that's better than sitting in middle of the ocean, oars in the water, debating and going nowhere.

But as with most advice I offer unsolicited, I'm going to waffle and say, "it depends on the situation". :)

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.

In no particular order:

1. Listen before you speak. The people you manage are prone to giving your opinion more weight than it deserves.

2. Give your subordinates problems, not solutions. People like to own a task, not to be told what to do; treating them like adults and professionals empowers them and brings out their potential. Besides, if one person only ever makes all the decisions, no decision can be better than that one person's knowledge. If you're afraid of delegation, institute a tight review loop to ensure that people don't go off-track.

3. You're a facilitator, not a doer. People will come to you with their problems, and you must be available at all times to help them through it. As someone else has pointed out, your productivity is secondary to that of the team. It's your job, among other things, to ensure that your team has a good working environment, including good tools, practices, and access to uninterrupted “flow” time.

4. Be aware of politics. The moment you manage a team, politics become a part of your daily job. This is not a bad thing—“politics” just means managing interpersonal relations; it becomes a bad thing when you ignore it.

5. Never be in a position to take. Success belongs to your teammates; failure is all yours.

6. Face problems head-on. People don't like confrontation, and let problems fester until it's too late to fix them. Instead, provide frequent one-on-one time with all your teammates, exhort them to confide in you, and show them that you're trustworthy. Also see #1.

7. Offer clarity. Explain what you expect others to do in a measurable way to make it possible for both you and your team to understand how well everyone is doing. You can use a method like OKR[0] to track your goals internally.

[0] https://en.wikipedia.org/wiki/OKR

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 is busy, I better not disturb him. Guess I can't do any work until then!" You need to make sure that whatever communication mechanisms you agree on have buy-in from the rest of the team, and that they'll be comfortable interrupting you if they're really blocked and unable to get work done.