
Ask HN: Promo from Senior to Tech Lead, any TL's care to share some wisdom? - cachestash
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.<p>I would say I have pretty good people skills. That would be strength I could play to perhaps.<p>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 &#x2F; 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&#x27;s &#x2F; traps should I be aware of?
======
runT1ME
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.

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

~~~
codingdave
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.

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

~~~
cachestash
Great answer thanks!

