Ask HN: Promo from Senior to Tech Lead, any TL's care to share some wisdom? | Hacker News Reader

Ask HN: Promo from Senior to Tech Lead, any TL's care to share some wisdom?

5 pointscachestash6 comments

So I am freshly minted Tech Lead. The move makes sense and I expected it. I have worked as a developer for 15 years+ now and been on numerous projects and I am fairly well respected guy in my engineering department. I mentor other engineers and take a genuine interest in helping them solve issues and growing as a developer.

I would say I have pretty good people skills. That would be strength I could play to perhaps.

I want to get the team off to the best start possible and lay a good foundation, so would like to ask others who have made the same move - what sort of things can encourage / do from the beginning and what should I be mindful of over the first six months that will help things get off to a good start. What sort of pitful's / traps should I be aware of?

View on HN

It's important to find the balance between letting your other engineers design and implement the more interesting and challenging problems, and also making sure they don't get in over their head.

Sometimes tech leads (often rightfully) assess that they are the best engineer in the room, so they should tackle the hardest problem. I don't think this is a good idea most of the time!

Giving ownership and autonomy is often one of the easiest ways to increase someone's productivity, so let your team take ownership of the parts of the project they are interested in.

Often a tech lead might end up having to take on the least fun tickets, the drudgery, yak shaving, etc. while the engineers working under you will get assigned work that has more prestige/glory. This won't go unnoticed, and will be appreciated by your team.

It depends on the company you're in, and whether or not there's a CTO above you. If there isn't then my experience is that you should expect to write a lot less code and to do a lot more project management and meetings. Your job is now to steer the tech your team is building while navigating the antagonistic wants of other parts of the business. You're going to be the person people blame a lot. Your dev team will blame you if you can't stop the product team changing things all the time or the money team complaining that things are taking too long, and the product and money teams will blame you if they don't get the changes they're requesting done fast enough.

Don't try to make everyone happy. You can't. Sometimes your team will think you're making the wrong decisions. Sometimes product and money will think you're deliberately trying to make things difficult for them. Do what you think is right for the tech you're building and fight hard for what you believe in. Usually you'll be proved right in the end.

Thanks. There is in fact a CTO who is very supportive.

> Don't try to make everyone happy.

Excellent point, I am thinking of printing that out and framing it somewhere.

I'd disagree - tech leads are there to steer the team, not the tech. They are supposed to understand why the product designers and owners are asking for constant change, and work to make that change happen in a way that isn't disruptive. They are a liaison between different groups, to help the devs be part of an aligned effort between groups, by understanding the goals of all groups, helping the others understand the needs of the devs, while helping the devs understand how they can help meet the needs of other teams.

Do that well, and you don't have a "product" team, a "money" team, and a tech team - you just have a team.

Typically when I was the Team Lead, my boss had a business view and not a tech understanding. As such I became the voice of tech to business. Likewise I was the business voice to the techies.

You will/should have a good understanding of each persons project. Your people will come to you when they have trouble. When they do, usually the best method is to just talk through the problem. eg "so you say your routine blows up just once a week, and you did not change a thing ... lets discuss what environment it is running in .... "

You MUST watch for when an engineer gets stuck. You are the voice of reason for when they argue tabs vs spaces. (FYI tabs). It is key on you to recognize when it occurs because engineers will suck up a lot of time on things that just do not matter. Unlike tabs which are critical ;-)

You must be prepared to defend your people when they make a mistake, which is a when not an if situation. My worst was one of mine getting arrested for dealing. I had not defense. Fortunately it only happened once.

Congratulations, now get back to work.

Great answer thanks!

Reply on news.ycombinator.com