
Ask HN: Advice for a new and inexperienced tech lead? - Voxoff
I&#x27;m only a mid-level developer. I&#x27;ve been offered a position as a tech lead with the aim of building a team. What advice would you give a new, inexperienced, and ambitious tech lead?<p>Thank you HN
======
jaspal747
Few things I would like to say:

It will no longer be about you. It will all be about your team. Make sure you
create a great team, nurture them, train them, teach them how to think
critically (in doing so yourself).

Ask your team to write out everything they plan to do before they actually do
it. Reason with them on what they wrote and what approach decisions they plan
to take. Teach them to think long term. Writing before actually doing the task
helps get a lot of clarity to them and also helps you in assessing what they
were planning to build. (It also makes for a great log of what we did and why
we did it. This will be the product documentation for your entire product
tomorrow.)

Treat your team like your family. Do not stress them out with too much work.
Be respectful of their time and effort. Give them breaks post completion of
major tasks. Every second that you let them rest and breathe is a second you
have invested in the future. They will recharge and put their best in the next
task.

You have a tough job of standing up for the right long-term tech decisions.
Stay loyal to your product. Work for your product - not your company. Take
tough tech decisions that will stand for the long term stability and
robustness of your product. But occasionally make allowance for your business
team too.

Sometimes your teammates might shy away from a big daunting challenge - step
in and work side by side with them to tackle it. But do this infrequently.

There is a lot to add to the above list but in general the idea is to help
your teammates grow, help them think critically, stand for your product - make
the tough calls.

All the best!

~~~
derekchiang
I think your advice is great for tech leads at big companies, but for tech
leads at startups, I have to disagree with the point about "Work for your
product - not your company."

At a startup, the business objective has to come first and the engineering
team has to keep the bigger picture in mind. "Long-term stability and
robustness" won't matter if your company is dead. Build for the short-term and
build fast while you are figuring out product-market fit. Move fast and break
things.

~~~
bransonf
I see where you’re going, but I think the advice still sticks.

If you’re at a startup, your product _is_ your business.

The point about not hesitating to move fast is the biggest difference between
startups and mature companies.

~~~
unlinked_dll
The problem is if you're at a startup you probably don't know what your
product is, because you don't know who your customers are.

My last startup died because we committed too hard to the product and the
business model, which while innovative and one that I still believe could have
succeeded - we utterly failed because we didn't understand our customers and
we didn't pivot fast enough, ran out of runway and then everyone but the
founders got laid off. Waiting on hearing about the equity.

~~~
fsloth
If I may function as the devil's advocate - One can read the above as a claim
that because you didn't have a good business guy engineers should have worked
faster? Would a faster product iteration worked if the business acumen would
still have been missing?

~~~
hanspeter
I don't think the argument is that engineers should work faster. It's that
they should be willing to skip some of the stuff you would normally say is
good practice in order to ship features super agile and make any necessary
pivot easier.

~~~
unlinked_dll
It wasn't a lack of features so much as a lack of talking to people that had
purchasing discretion. Never focus on users in B2B, focus on people who have
the ability to approve a purchase order.

------
tbabb
Top mistakes by new leads:

\- Not delegating. New leads often feel that if they're not writing code (or
doing whatever it means to be an individual contributor), they're slacking
off. The definition of "work" has changed. It now means "helping your team
succeed". If you try to be an individual contributor, you are doing your old
job instead of your new one, and you'll get overwhelmed and sink.

\- Not asking questions. New leads often think that being a lead means being
an expert, so they're embarrassed to ask or consult someone else about their
team's domain, for fear of looking inadequate. Your team and your peers are
the experts— it is your job to ensure that expertise prevails, whether it's
yours or someone else's. You'll look much more dumb if you're too insecure to
admit what you don't know, or fail to ask basic questions that allow you to
get the job done.

\- Hiding problems. When things aren't going well (and often they don't),
don't hide this from the leadership above you. They are there to help you and
guide you, and can save you from crashing and burning. You will look much
worse if a problem comes to light months after it could have been communicated
and dealt with.

\- Not communicating. Share what's going on with your team. Share what's going
on in the big picture. Don't keep people in the dark, either above you or
below you.

Some leads (moreso if they're prone to impostor syndrome) think they have to
wait for permission to speak, or to be offered something that they need— don't
do this. If you have something important to say/ask, it's your responsibility
as a leader to say it and get what you need.

\- Forgetting the big picture. As an individual contributor, you often only
have to think about near-term or small-scope problems. It is an easy mistake
to make as a new lead to spend priority on those things instead of keeping in
mind what's necessary for the entire team to succeed at its high level goal.

Good luck!

~~~
jrochkind1
"tech lead" is not considered an individual contributor role? Is it considered
a management role?

I'm realizing I'm not quite sure what is meant by a "tech lead" role.

~~~
smilekzs
My understanding is that "tech lead" as a role in Big Tech is more of a
gateway position to bridge the gap between IC and management roles, a
transition for a well-performing engineer who otherwise has no experience
managing a team to "bootstrap" and gain that experience. During this, coding
expectations for said engineer naturally lowers, and is shifted towards the
total productivity of the emerging "subtree".

~~~
jrochkind1
OK, that's helpful. Maybe not lowered to ZERO though?

~~~
tbabb
Didn't mean to suggest that it should be zero— only that new leads feel like
they are falling behind when they're actually doing normal leadership tasks,
because it's not coding, and coding is what feels like work to them; or that
their instinct for dealing with increased workload is to code more (instead of
organizing more). Those are bad instincts, hence they need to readjust their
definition of "what feels like work".

------
laddershoe
I was in this exact position a few years ago! I led a group for a year and a
half, with somewhat mixed success. We did some pretty great successes, but
also some pretty embarrassing problems that were at least partially
attributable to my inexperience. I learned a ton though! The below is my
experience, and may or may not translate to yours, but believe me, it was
learned the hard way.

Being a tech lead is only partly about the tech, and mostly about the lead.
You'll ultimately succeed or fail based on your team.

Being an effective leader requires a completely different set of skills than
being an effective engineer. This, as silly as it sounds now, took me by
surprise. You may have a decade-plus of dev experience but still be starting
from zero when it comes to people. (Or not; some people will be better
equipped for this than others. I wasn't so much.)

Find a mentor. Someone you can be completely honest with, and who will be
honest with you. Bonus points if they know your team well too -they'll see
things that you won't.

You may have to be pretty intentional about finding out what's going on in
your team. Once you're in a position of authority, people won't always feel
free to tell you.

Share as much context with your team as you can. They'll be more motivated if
they understand why their work is important and has value. Even if you
understand this... people aren't mind readers. They don't know what's in your
head.

Part of your job now is to be available to people. This may mean you don't get
to actually work on the tech yourself as much (or at all). It may mean you get
interrupted more. That's may or may not annoy you, but you need to make the
best choices you can for your team now, not (just) for you.

Share success when you can. You may find yourself in situations where people
attribute your team's success to you... and while that's not wrong (you're the
lead after all) it's also a great opportunity to share credit with those in
your team. It's worth so much to people when you do this.

People are not interchangeable, and treating them as if they invites trouble.
You can have great people, who still have a hard time working together for
whatever reason. Be aware of inter-team dynamics; they can sink you.
(Situations like this are why it's great to have a mentor.)

It's important to keep a close eye on how things are going, but don't confuse
that with micro-management. Your best people are going to want some autonomy,
and it's best for everybody if you find a way to give it to them. If things
aren't going so well your instinct may be to tighten your grip... not
necessarily wrong, but consider that may come across as a lack of trust on
your part.

Above all: think of your job as less about being in control (though you may
be) and more about fostering an environment where your team can do your best
work. Get them what they need, shield them from the crap, give them what
opportunities you can. Don't be selfish or mean. Be kind, be empathatic.

Good luck.

------
otobrglez
Get the O'reilly's book "The Manager's Path - A Guide for Tech Leaders
Navigating Growth and Change" and READ IT.

1) You will not need to trust others to write better code/systems then you and
that you will very likely be unable to code anymore.

2) Establish a good relationship with your team members. Seek for people who
you can delegate to and trust. Trust and reliable people are really hard to
find. When shit hits the fan - and it absolutely does - you'll need that.

3) You need people who will push and people who will follow. Having just one
group and not the others is a recipe for disaster.

4) Establish what things you should care for and what not. The amount of shit
is insane and it only gets worse you need to have a threshold on when and on
what to react.

5) Do you own research as much as possible on key things.

6) Keep asking "why". It annoys me as f* but also forces you to go deeper with
explaining and understanding of the problem. (don't wanna say google "Five
whys")

7) Encourage people to go deeper, to learn more to become experts.

9) Have 1-on-1s. Regular. Scheduled. Talk about life/work. Try to find how you
can make the place and challenges better. Help them grow in an organisation
and professionally.

10) Sketch things out. Write em' down. Otherwise, you'll go insane repeating
stuff.

I sincerely wish you good luck.

P.s.: People have more bugs and are sometimes even more broken than software.
:D

~~~
Noumenon72
Should #1 start, "You will now" instead of "You will not"?

~~~
otobrglez
You are absolutely right! Thanks.

------
blowski
A few good resources for this. The different positions of "Technical Lead",
"CTO", "Engineering Manager" all vary from company to company so I'm not sure
what your new role will entail.

1\. [https://pragprog.com/book/jsengman/become-an-effective-
softw...](https://pragprog.com/book/jsengman/become-an-effective-software-
engineering-manager), which had a good conversation here
([https://news.ycombinator.com/item?id=22033129](https://news.ycombinator.com/item?id=22033129)).

2\. [https://managinghumans.com/](https://managinghumans.com/) by Michael
Lopes

3\. [https://leadingsnowflakes.com/](https://leadingsnowflakes.com/), which
also has a good weekly newsletter -
[http://softwareleadweekly.com/](http://softwareleadweekly.com/).

4\. [https://www.udemy.com/course/practical-
leadership/](https://www.udemy.com/course/practical-leadership/)

5\.
[https://tomdemarco.com/Books/deadline.html](https://tomdemarco.com/Books/deadline.html)
\- quite old now, but it's still hugely insightful.

May I wish you the best of luck. It's an exciting and really difficult
challenge, but can be hugely rewarding in the end.

~~~
basseq
On #2, there are a ton of well-written and entertaining articles by the
author—Michael "Rands" Lopp—on his website.

[https://randsinrepose.com/](https://randsinrepose.com/)

He also hosts a slack that's up to something like 100,000 people. Ask a lot of
dumb questions.

[https://randsinrepose.com/welcome-to-rands-leadership-
slack/](https://randsinrepose.com/welcome-to-rands-leadership-slack/)

------
geocrasher
A good leader doesn't compete with others- they bring out the best in others.

They assume the best of others.

They lead by example.

They are a facilitate as much as they delegate, and they don't lose sight of
the fact that you can't lead from the trenches.

A good leader remains objective when it's hard to do so, and doesn't take it
personally when somebody disagrees with them.

A good leader is kind, humble, and willing to help.

A good leader doesn't back down from using a firm approach when it's needed.

A good leader doesn't apologize for doing things that have to be done
(discipline, firing etc).

~~~
matwood
> A good leader doesn't compete with others

Agreed. Unless a leader is taking the responsibility for a failure (which they
should!), the leader should never say "I". When talking about a success it
should focus on the team, and is okay to point out individuals who did great
work.

I cringe every time I see a lead/leader present team work and say "I" over and
over.

~~~
serial_dev
I think it's okay to use the plural "We" for both successes and failures, even
as a tech lead.

------
munificent
One of my favorite parts of the Tao Te Ching is this:

 _A leader is best when people barely know that he exists, not so good when
people obey and acclaim him, worst when they despise him. Fail to honor
people, They fail to honor you. But of a good leader, who talks little, when
his work is done, his aims fulfilled, they will all say, “We did this
ourselves.”_

Your role is now defined by what your team needs you to be. Listen to them,
care, and see what you can do to help them thrive.

~~~
joshcanhelp
I have this pinned to my wall by my desk. It reminds me how far I have to go.

------
spookthesunset
One thing I don't see mentioned here is your reward cycle is going to be
different as a manager than as an engineer writing code. When you write code,
you know right away when you make progress on something. You go home at the
end of the day happy you got feature XYZ working or you go home cranky because
you spent the day fixing a fucked up dev environment. Either way, the time
between doing work and getting feedback for it is almost instant. Code
compiles and look I can enter data and it saves! Awesome!

As a manager, this won't be the case. You won't get that instant reward like
you did as an engineer. It might be months or even years between when you
started something and you see any reward for it. It might be weeks before you
even get feedback that something changed at all. Hell, you might _never_ get
to see the reward for a project you have in the oven. This can be very
challenging to deal with when you are used to getting near real-time reward
for your work.

You will have to adjust to the new reward cycle as you step out of coding for
a day job. It's okay to have mixed feelings about it too. Just know that you
will have to find other ways to find reward in what you do.

------
itronitron
I recommend getting clear guidance from your supervisor on what 'tech lead'
means to them. A lot of the commenters here think tech lead is a management
position however you shouldn't assume that your employer has that same view.
It doesn't sound like you are a 'team lead' otherwise your position would be
called 'team lead' and not 'tech lead'. Therefore you don't have any real
control over what anyone does, you can't make people do things, and you will
be responsible for leading the tech, so you can't really delegate that away to
individual contributors. Good luck.

~~~
abraxas
Yes tech lead in my experience is a BS non title invented to keep the most
productive rank and file developers feel like their careers are going
somewhere. It's extra responsibility and expectations with no additional
empowerment

~~~
daxfohl
Exactly. Tech lead is the worst role I've had. It's like make believe manager,
you get a bunch of extra supervisory work in addition to your regular work,
but no actual authority to do anything about problems, other than stay late
make up for the problems yourself.

You get bombarded by everyone outside your org who has a question vaguely
related, and by your junior devs for anything they don't want to figure out
themselves, and by your manager wanting to know whether we can release this
half baked component X to some other team even though it will break
production. You get maybe a little extra recognition but it's just not worth
the 3x extra work.

------
Accujack
Speaking as a team lead, the most important thing is to know what your
expected role is - are you a manager? Are you in charge? What does your boss
expect of you, and what does he expect of your peers?

You succeed when your team succeeds... if they don't, then you don't.

In my case, I don't have any authority other than influence. That's ok, it
also takes a lot of responsibility off my plate.

If you have authority over people, know that you can tell them what to do if
you have to, but if you reach the point where that's all you can do, you've
failed.

~~~
Jach
Knowing what's expected of you by whom is important regardless of your role.
And also team success over personal success -- you have to be in some petty
backstabbing nonsense for those things to not be tightly related.

I have a Lead title at work, but like you I don't have any authority over
anyone. So I don't really have any advice for the OP, as it seems what "lead"
means varies so much from company to company, and to me as soon as you get in
the business of authority you really need to start thinking about management,
not tech, to which I can only suggest read Deming.

I think my ideal model for 'tech lead' is something like how (I've heard,
could not actually be the case) Bryan Cantrill at Joyent operated. Even when
he was VP Eng, and later CTO, he still was involved in code, and generally
engineers there both "led and were led" without very hard cut roles on that
axis.

------
nihil75
I found the hardest part of becoming a leader is trusting my own judgment,
intuitions and decisions. The "Disney" quates for managers like "it's the team
that succeeds" and "you don't accomplish tasks, you'r team does" led me to
disregard my experience and allow engineers to dictate most of the design,
which turned out rubbish. I knew better, had solid arguments for my design,
yet I let the team proceed with an inferior solution in the spirit of
enablement. The customer payed the price.

------
cookiecaper
Become a student of psychology. If you're coming from an IC->management role
for the first time, expect your worldview to be broken, and let it happen so
you don't have to have a spectacular flame-out to allow it to reset (happened
to me, and very common for people coming from the very unambiguous world of
"code compiles" to the very loose world of human interaction, where people
can't even understand their own motives, let alone anyone else's). Even a
modicum of authority changes the way people interact and respond to you, and
that's not going to change. Work within it, meet people where they're at, and
understand that when it comes to dealing with reports, they're usually right
and you're usually wrong.

People are the only thing that matters. Deadlines come and go, companies go
bankrupt or get their entire C-suite arrested in midnight raids, competitors
come in and break everything and turn the company into a zombie. The thing
that endures is the people. If you have good people on your team, consider
yourself lucky; being a great boss is one of the best ways to cement a
lifelong connection to the best people, and you'll get way more benefit from
it than you deserve.

Nothing is straightforward or face value. Understand this and don't try to
change it. There's a lot that you'll have to learn for yourself, but keep your
priorities and loyalties straight, don't buy into anyone's bullshit too far,
and you'll be fine. Good luck.

------
dnautics
Just generally, as an employee, what I value in my manager is "someone who's
got my back".

I would say what that means is, internally, you run interference to shield
your reports from management incompetence and thrash, you take responsibility
for failures, and internally promote (in the "promoter" sense) them. And
externally, proactively provide professional advice and support, even if that
means losing someone important to your team.

More than anything else, those are the qualities I strive to as a manager.
(Not saying I'm perfect at it)

~~~
tastyfreeze
This right here. My manager needs to be a shit shield not a shit peddler. A
team will never get anything done if the lead lets upper management pull the
team every which way.

~~~
zomglings
The way I've heard it - be a shit umbrella, not a shit funnel.

------
coderheed
Run!

I’m only half joking. Hopefully your company is ‘one of the good ones’ and it
will work out, but they are few and far between.

The tech lead job varies a ton from one company to the next, but all too often
it comes with high expectations without enough autonomy or authority to
deliver on them. Make sure your boss provides clear expectations and work with
them to clarify boundaries over time. I’ve been on both sides of this process
and it is difficult and necessary.

Too often, tech leads are expected to wear more hats than they are able to
wear well. Delegate all that you can and if there is still too much work to
do, ask for help.

It’s all about communication so actively work on this skill.

------
notacoward
0\. Find other TL mentors.

1\. Remind yourself daily that the metrics you've used to gauge your own
productivity or success until now _do not apply_. It's really hard. Resist the
temptation to do non-TL things if it will affect your TL responsibilities.

2\. Find other people who have more/broader experience than you do, and _pay
attention_ to the perspective they provide. There are many people who know
more than most TLs but don't want the role themselves. You can help each
other.

3\. Remember that _lead_ is as important as _technical_ in your job title.
Your role is to bring people to a place they're not already. Figure out what's
missing in your project and/or your team members' skillsets. Those are the
things that it's your job to address.

------
KineticLensman
As a tech lead you may have to be 'the voice of the company' to your team
members, and sometimes say 'no' to requests that you might actually think are
reasonable, from a purely tech perspective. The impact on your relationship
with the team depends a lot on whether you play yourself as part of the team -
and are visibly aggrieved on their behalf - or become perceived as 'one of the
managers'. Whether this is a problem or not depends on the corporate culture
and whether there are other managers visibly involved.

Also, remember to reserve time in your day to deal with problems raised by the
team. These will often occur when you are least expecting them. And some may
be outside your own comfort zone.

On a positive note I found that being a tech lead made me a better team member
for my own management, since I better appreciated some of the leadership
challenges they were under. You'll sometimes be left stunned by how hard or
well your team members are working to solve problems, and this can make it all
worthwhile.

------
hnrodey
I've been a "senior developer" for several years and just moved to a formal
management role with direct reports. Briefly, here's where I would suggest you
start.

1\. Read the book Extreme Ownership by Jocko Willink. I'm not the first to
suggest this book but it has fundamentally shaped how I work and how I
interact with others.

2\. Try to write. I'd start with writing your "Manager Readme" file even if
you don't plan to share it with anyone. Defining expectations is critical and
it's start with understanding your own psyche. What is important to you? What
are your expectations for someone? The internet is filled with examples of
Manager Readme's along with posts that are totally for this idea and totally
against. You can find mine without _too much_ trouble if you check my comment
history and find my GitHub.

Good luck.

~~~
Reedx
> Read the book Extreme Ownership

That idea and set of principles is something I'm kind of surprised hasn't
become more widespread. It also changed my approach in a fundamental way and
is one of those things I wish I had learned a long time ago.

Also I've found his Good concept a useful way to stay positive:

 _Oh, the mission got canceled? Good… We can focus on another one. Didn’t get
the new high-speed gear we wanted? Good… We can keep it simple. Didn’t get
promoted? Good… More time to get better. Didn’t get funded? Good… We own more
of the company. Didn’t get the job you wanted? Good… Go out, gain more
experience, and build a better resume. Got injured? Good… Needed a break from
training. Got tapped out? Good… It’s better to tap out in training than tap
out on the street. Got beat? Good… We learned._

~~~
hnrodey
I feel you, brother.

 _fist bump_

------
qxmat
1\. get 2 mentors: a technical one and business one (doesn't need to be domain
specific)

2\. your job is transitioning from "doing" to "enabling". You'll be
responsible for issues of governance AND operation. Learn the ropes equally.
As you introduce successful operational concerns (bottom up) start to
generalise them so they can be used as a top-down concern (i.e. i do devops ->
we all do devops here, it's part of the training)

3\. leading by example doesn't scale - stop. Embrace a teaching method that
ends in trust: i.e. 1. introduce a concept to dev A, 2. get dev A to
demonstrate it back to you independently (monitor and prompt as appropriate),
3. from afar passively observe future implementations of said concept and
revert to steps 1..2 if required, 4. inform dev A that they are trusted
explicitly with this concept and that it is theirs to run with - encourage
them to onboard dev B in a similar fashion.

4\. at the top you're more responsible for team morale than you can possibly
imagine - random acts of kindness and/or direct conversations go a long way...
whether it's donuts or "a quick catchup" over lunch, do it... regularly (if
you find your postponing these kind of meetings you've got a priority
inversion issue to sort out ASAP).

5\. if someone is dishonest in any way take it to HR before they walk over you
and your team/product/department suffers. In other words, with HR's help,
address slow/no work or unapproved "wfh" days as a threat.

6\. push back against harmful designs and rushed/skipped processes.

~~~
pesfandiar
Number 5 reads a bit like this: if an employee is not motivated enough,
instead of trying to find the cause and mitigating, go on the hostile path and
get HR involved.

In fairness, this could be a good advice for roles that are easy to hire for
(e.g. minimum wage manual labour).

~~~
qxmat
I'm of the opinion that dishonesty is serious because it's an irreconcilable
breach of trust. There are many things I'm happy to deal with internally
providing there's a frank account but once someone intentionally misleads
another it makes individual management untenable.

Separately it's a HR problem because of the nature of certain types of work.
I'm struggling to fit my view with neural diversity though - some devs say
dishonest things without malicious intent because they lack skills to
effectively communicate.

~~~
tbabb
Sometimes people reframe mistakes or lapses in a "dishonest" way to save face.
I think it's important to use those occurrences as opportunities to show that
it's safe to be honest instead. Allow them to come clean and show that the
highest priority is correcting the problem. Running straight to HR instead of
creating a teaching moment could _increase_ distrust and the incentive to be
dishonest.

There is a line between this and manipulative dishonesty, of course. Bad faith
(when it's clearly that beyond reasonable doubt) should be treated with close
to zero tolerance.

------
nostrapollo
I am two years into being an 'inexperienced tech lead', and I think there are
some good pieces of advice in the other comments. But I think the most
important thing seems to be having some structure to your progress in all of
the mentioned categories. When dealing with your team have an objective in
mind for not only the conversation or meeting but for the takeaways you want
your team to have. Take note of what assumptions changed your mind for certain
decisions. Assume you're wrong and need to experiment to be right.

More practically: I write down feedback that is given to me regarding
leadership style and write down things that I think about at the 'moment of
impact' (assumptions, reasoning, and metrics for success/failure of decision)
when decisions are being made. Read over these notes often enough that you are
aware of those things when they happen again. Anecdote: Developers often want
time to create a quality feature and if they are frequently pressed for time
due to business requirements, they are unhappy and the product suffers, often
in less than obvious ways. It was only really obvious that this was a problem
when we tried other ways of planning and prioritizing because the assumption
was that development pressure was a given for a tech company, turns out that
some development work can be offloaded by better planning and prioritization
based upon better thought out business objectives. These learnings came about
because we kept took notes of decisions that were made, and could refer back
to them as crucial points of pain/cost/failure.

If you don't have some structure to your approach, you'll find it difficult to
call out specific changes that need to happen.

There's a lot more that could be said. Tech leads are often interfaces for
other parts of the business so respecting the context of other's roles and
aligning incentives is more important than proving your job is being done
'correctly'.

------
Cthulhu_
Realize that you are / should be in control. Make sure you get mandate from
the higher ups, that you get to say yes or no based on your own judgment. But
don't rely on yourself for everything, work with your team as well. Realize
that you're a manager, you manage people, priorities, considerations, etc, and
that for purely technical decisions you rely on input of your team a lot.

Make sure that technical decisions are documented (e.g. via an ADR), making
sure to document what you and your team know and consider at the time of
writing. This is a pushback to hype-driven development; you don't want to be
stuck with a bad decision just because one team member showed up at work one
day with a feature implemented in technology X without proving they've done
the work for it. And you don't want to have to waste time with future
employees explaining (again) why technology X is used - you can refer to the
docs, and if they want to challenge it, have THEM come up with counterpoints,
have them sell it to you and the team, and have them defend the time / effort
investment to change the technology.

Re: hiring, always do a technical interview, even if you're hiring internally.
Involve your existing team members, they have to work with the new candidate
after all. Have the applicant do a small project (4-8 hours) representative of
the technologies and context of your project in their own time, and challenge
them during the interview (the goal being they can prove they wrote and
understood the code they produced).

~~~
maerF0x0
> (e.g. via an ADR)

what is an ADR?

~~~
ahamez
It stands for Architectural Decision Records. More info here:
[https://adr.github.io](https://adr.github.io). We use this at my work to keep
a record of our decisions, as the name implies ;-).

------
streetcat1
Remember this:

 __* Code in production = value. __*

And the following (I am not the original author):

Ship small (seek the shortest path to show and deliver value to your
customers)

Ship imperfect products (perfection is the enemy of done)

Ship for your users, not for you

Ship every day (it creates momentum!)

Focus on finishing (shipping), not starting

A shipped product is worth a thousand of blog posts

Ship first. Then iterate

------
jbot29
Watch Band of Brothers - Dick Winters I think is the best example of a good
leader.

Doesn't ask from the team things that he wouldn't or isn't capable of doing.

And as many of the other comments have said you are there for the team. They
will produce the real value.

What can you do to get them all the things they need to succeed? What can you
do to shield them from the nonsense? Poor requirements, unnecessary meetings.

I think you want to give chances to fail but also provide that safety net so
they don't fail too hard.

------
fwouts
A colleague of mine who I value as a good tech lead recently wrote some tips
based on his experience: [https://medium.com/swlh/two-lessons-youll-learn-in-
your-firs...](https://medium.com/swlh/two-lessons-youll-learn-in-your-first-
year-as-a-tech-lead-f74c4f883203)

He also just published another article about quality technical communication,
which I'd highly recommend both you and your team read through:
[https://medium.com/@tpagram/a-guide-to-improving-your-
techni...](https://medium.com/@tpagram/a-guide-to-improving-your-technical-
communication-162a2563c795)

------
m0zg
First of all you need to figure out if you're a "tech lead" (informal title,
no reports or authority) or a "dev lead" (formal title, with reports and
authority).

As a former Google tech lead (and I know this sounds like a YouTube parody):
my advice is don't be a "tech lead" for long. Either be a dev or move into
management. Make up your mind. Google "tech lead" is defined above.

As a tech lead in such informal position, you'll end up doing 2 jobs and
you'll eventually find that the level of effort required is not commensurate
with compensation. You can make much more and have a faster career progression
as a manager. You can make the same money with less effort and headache as a
dev. Your IC career won't move any faster just because you're a "tech lead",
indeed the opposite could be true, because now a non-trivial fraction of your
productive capacity is taken up by intangibles which are very difficult for an
IC to articulate the value of come performance review time. Being a tech lead
makes no logical sense whatsoever, at least not at Google, unless you're
aiming for a manager position in the near future, and you need to demonstrate
your "leadership qualities".

Other companies may differ, of course, but I bet it's like that at most places
that have "tech" leads. In contrast, at Microsoft there's "dev lead", not
"tech", and it's a frontline manager position, with reports and authority, and
with the aim to move upwards on the management ladder.

Google-like informal "tech lead" is not even a title, it's just a SWE too
stupid to understand that they're basically doing more valuable work, and more
of it, for the same money.

~~~
gibb0n
Exactly what happened to me, then I read the Gervais principle and reduced all
my stress by leaving for a new role 'just' being a dev instead of tech lead

[https://www.ribbonfarm.com/the-gervais-
principle/](https://www.ribbonfarm.com/the-gervais-principle/)

------
alharith
I would advise you to not take the position. It would be a disaster in my
opinion to attempt to be a tech lead without years of experience at the senior
level. Your high level engineers will catch whiff of your lack of experience.
Your mid and associate levels will not accelerate as fast as they could have,
and you will feel over your head. You will essentially be Peter Principaling
yourself.

If you are going to do it, read a ton of books. Minimum in my opinion are: 1\.
The Managers Path -- general advise 2\. Coaching Habit -- for performing 1 on
1s 3\. Extreme Ownership -- for building an effective culture that delivers
results.

~~~
Quarrelsome
It won't be a disaster as long as they're humble and willing to learn.

~~~
alharith
My direct report is humble and most willing to learn. That doesn't mean they
aren't at the end of the day still a very green associate developer with 7
months of experience so far. Any talks about reaching senior developer status
any time soon would be a huge disservice to their development. We need to
first talk about what being an exceptional associate developer looks like,
transitioning to being a mid level developer.

You can't shortcut these things.

~~~
Quarrelsome
Really good coding/architecture skills or able to collaborate and seek opinion
and input from others.

For me as long as people have one or the other I can work with it. I've often
been in scenarios with people that aren't good and won't collaborate and
THAT'S the hell.

Obviously both is best but the skill set is rare. I'll happily take someone
that defers to me and trusts my judgement over the HELL. Its not ideal and
doesn't result in the best outcomes but its still workable.

------
peteforde
Wait, do you actually want to stop programming and manage other programmers so
early in your own personal development arc?

My primary advice is a strong "most people asking this question should not do
this".

Not because you won't be good enough or grow into the job, but because it's a
completely different job - and one that many programmers who actually like
programming don't enjoy and in many cases aren't well suited for.

There are two toxic traps I should confront. The first is that titles like
"tech lead" and "CTO" flatter your ego and impress your friends and parents.
The only thing I can think of that exceeds this on the "sounds amazing today;
tomorrow you'll start the rest of your miserable life" is an idealist taking
money from a VC. Find a different way to impress your dad.

The second is that many companies do not understand how to incentivize
programmers beyond "junior/intermediate/senior" (even architect is mostly just
a senior who has to spend time managing, eg are distracted and less productive
most days than a senior with a closed office) and you get to the point where
the upper reaches of the programmer food chain are managing other programmers.
Very few things could be more destructive. Honestly, it's fucking obnoxious.

You know what the very best programmers should get? A salary twice as big as
the next best programmer, a quiet private workspace with permission to work
from home, paid childcare and spousal assistance, and firm dedication from the
management to insulate them from as many meetings and distractions as
logistically possible. There should be penalties for disturbing them. Now
that's tech leadership.

Also, the folks saying that you're working for the product, not the company
are high as a kite. They are painfully wrong.

Long story short: if you love what you do, thank them politely for considering
you and ask them for a quiet workspace and insulation from meetings. Then get
back to work.

------
mkadlec
Inspire!

I transitioned into a tech lead a year ago and at first it was kind of annoyed
by all the requests from the team regarding technical assistance.

I realized there were two paths I could take. 1. Continue to be annoyed and
try to get as much coding in as I can. 2. Sit down with each individual, help
them, give examples of how things should work etc.

Luckily I chose the latter option and I have a great relationship with all the
team, I have strong coders that are more self-sufficient, and I enjoy more
time coding now.

I think the lesson I learned is that you get out of your team much more than
you put in, strive to inspire your devs.

~~~
nk1337
Agreed. I think one of the things I learned from my Tech Lead is how to handle
stressful code-related situations and communicate with other teams.

This is one of the important skills to have and will have huge impact on
"engineering atmosphere".

------
dtw0617
This one comes from personal experience.

If a team member comes to you and says that they feel disrespected,
discouraged, ignored, or even _bullied_ by a more senior team member, take
that seriously. Immediately schedule a 1-on-1-on-1 and don't give anybody any
time to prepare. Create a safe space for people to voice their concerns, and
express to _everyone_ that if they are not capable of treating others with
respect, they can be made redundant.

I'm going through this right now and it sucks. I wish my team lead had my
back, but they don't.

------
nicholassmith
The bits I wish I'd known:

It's okay to make mistakes. Really, you're going to make loads of them, and
your team is going to make loads of them and you're going to own those
mistakes.

It's now going to be more about getting the best out of your team than it is
about squeezing out more code. I spent a lot of time beating myself up over
how much code I wrote dropping off, there is a nice sweet balance you'll find.

Learn to delegate, and learn to do it early. You'll burn yourself out super
quickly otherwise.

------
somesortofsystm
Never consider yourself senior to someone unless you can do their work, and
until they have demonstrated they can't do it. Otherwise, stand back and let
people work.

You doing their work is sometimes going to be needed, but a 'good team' has an
equitable workload. Be willing to do any of it.

The biggest thing a team leader can do is help the team communicate with
itself. The worst thing a team leader can do is create conditions where team
members are not communicating.

~~~
mc3
I agree with this because my 2 favourite places to work (my current on and one
9 years ago) had more of a 'self organising' vibe which encouraged people to
put their hands up for things, and although the most senior people have the
most codebase knowledge (due to simply having written that code themselves
over the years), there are now a lot of areas of code that newer people like
myself are the experts in. And also applies to technologies, for example React
is known more by a few people needing it for their task.

The point I am getting at is that it is OK and I'd argue optimal if the team
leader knows less than the person they are leading and the team leader has to
ask them questions about how something works, but their job is to know enough
to be able to make decisions and get a feel for things.

------
ph2082
I worked couple of years in this role so here are my few cents:

1\. Listen - Learn to Listen to Your customer and Team Members. Understand the
reasoning behind what they are asking for.

2\. Show, not only tell - I used to sit next to devs and see that problem they
are mentioning is actually is problem. Sometimes issue could be business
requirement. If technical issue, explain throughly teach how to go about
solving such kind of problem. If they are still not able to do it fine, work
with them while continue to explain. You want to teach - how to go about
"solving problem".

3\. Learn, Learn More and Learn More and Keep Learning and then Share - Learn
about the business domain. Learn about technical domain. Learn about
everything which lets you 'get things done'.

4\. Delegate - But delegate properly, once task is assigned, make sure the
team member understand what needs to be done. And they understand 'how it will
be done'. You don't want to figure out at end of day that because of
misunderstanding or lack of information task was not done correctly or worse
has to be redone from the start. Reworking sucks big time and will suck big
amount of time for everyone - you, team member and customer.

5\. Get Details - Try to get as much as detail as possible, based on
information take decision based on 'who is right for this job'.

6\. Don't play favorites.

7\. You dealing with Humans. People make mistakes. Find way to reduce chances
of happening mistake in first place.

8\. Be cool. Never get Angry. Anger drives out reason.

Good Luck.

------
kristov
For one scenario: if two members of your team disagree passionately on
something technical and come to you for resolution do the following: tell them
they must resolve the argument between themselves with you as a mediator (to
make sure they stay civilised and focussed on the technical arguments). Tell
them they must come to a consenses themselves. Do NOT pick a side unless the
process breaks down. I made this mistake and it wasn't good.

~~~
gwbas1c
Never treat issues of incompetence, inexperience, or bad attitudes as
interpersonal disputes. When one team member isn't following well-known
processes, or is obviously wrong, you must pick a side quickly.

(Examples include things like magic numbers instead of #defines, use of
strings instead of well-defined enums, pull requests with lots of commented
out code. They can also go to deeper topics, like bad database schemas or poor
data access patterns.)

Why must you pick a side quickly? If you treat incompetence or inexperience as
an interpersonal dispute, you aren't managing. Instead, your team will quickly
view you as appeasing incompetence, and this will quickly drain morale. This
is especially the case if one person should be moved to a less-challenging
role, or fired.

From personal experience: In these situations the technical lead fixed the
code before merge, and management eventually pushed the other person out. But,
it was a long slog while management tried to be diplomatic with someone who
just wasn't willing, or able, to be professional.

~~~
kristov
I agree with that totally. In the case of technical incompetence for sure it's
demoralizing for others to pretend it's a dispute with no "right" answer.

In the case I was involved it was two very competent senior developers and the
dispute was between a iterate-fast-and-learn approach, and a build-for-the-
future approach. It wasn't clear which one was right at the time and I
respected both their opinions. It became clear that it was growing from a
technical disagreement into something much more personal. I let it go too far
and felt like I needed to step in and pick a side. I believe that I missed an
opportunity for them to come to a compromise and learn something about that
experience, instead ending up with one very pissed off dev, and one that
thought I was on their "side" from then on.

Sometimes you feel like you have to make a decision just because your in a
position of power, when actually in many cases you can be there as a mediator,
lowering the emotion and keeping things professional and let people work it
out themselves.

------
meristem
Great absolute clarity on what is expected of you by your manager. Tech lead
roles have a mix of manager-light bits and your manager may have very specific
ideas as to what the role ‘looks like’ or ‘feels like’. You need that info to
succeed.

~~~
alex-warren
Absolutely this. There's a lot of nice talk in this thread about empowering
and enabling your team - but in my experience, that's not what companies are
hiring tech leads and managers for. They're hiring you to get stuff shipped!

So understand your own manager's approach to management, and make sure you're
aligned with it. Recently I was in a job where my own "servant leadership"
style clashed quite badly with my boss, who was much more focussed on
management "driving delivery" of projects. It did not end well.

------
sixhobbits
Join the Rands Leadership Slack group [0] if you're into slack communities.
This question gets asked a lot and there are dedicated channels to chat about
exactly this and overall it's a supportive community :)

[0] [https://randsinrepose.com/welcome-to-rands-leadership-
slack/](https://randsinrepose.com/welcome-to-rands-leadership-slack/)

------
stackzero
\- You can't lead a team further than you have been yourself There is a
constant need to spend time up-skilling, performing tech spikes, thinking
ahead \- 20% of people do 80% of the work. You should be in the 20% and also
invest time with the people in your team that are in the 20% \- Genuinely care
about the people you lead and help them get better at whatever their goals are

~~~
q-base
\- "You can't lead a team further than you have been yourself"

I respectfully disagree. A good leader hires, nurtures and grows individuals
that are better than himself. The goal of course always is to have the team be
more than the sum of its parts. In doing so it should be the goal of taking it
much further than the leader could ever have gone alone.

------
ajford
I totally recommend you read/listen to the Phoenix Project
([https://www.amazon.com/Phoenix-Project-Helping-Business-
Anni...](https://www.amazon.com/Phoenix-Project-Helping-Business-
Anniversary/dp/B00VATFAMI)). It's heavy on the DevOps slant, but that's a good
thing!

\- Treat your team like their adults, not children, and respect them like
such.

\- Also, be transparent and clear with them. Hiding things or beating around
the bush just wastes everyone's time.

\- Give them autonomy to explore new tech when they get the itch, and you'll
likely get better results and keep your team active and engaged.

\- Embrace the blameless culture. Failures and bugs happen. Being hostile
about it means people are more likely to hide stuff and not be up front about
things. Not to say it shouldn't be addressed if it becomes a problem, but
everyone's going to mess up sometime. Also, it's your job to make sure that
any heat from on-high doesn't come down on them.

------
chasd00
I've was a TL for a few years in my career and still play that role from time
to time.

1\. have your team's back, no matter what. They (and you) are going to screw
up but your team is counting on you.

2\. make the team better, every single day. Whether it's technical, emotional,
productiveness, it doesn't matter. The team just needs to be better every
single day.

3\. get rid of the assholes, acquire those who want to be better

4\. see the forest through the trees. Understand and appreciate how the work
your team does translates into dollars for payroll

also, a while back someone posted this link on leadership from the Army. It's
more straightforward and clear than any airport bookstore leadership book
you'll ever find.

[https://fas.org/irp/doddir/army/adp6_22.pdf](https://fas.org/irp/doddir/army/adp6_22.pdf)

------
devurand
Empathy. Definitely practice empathy. Hacking brains is a lot more difficult
compared to hacking code.

------
cheshireoctopus
1.Have patience as you transition into this role

2\. Lead by example - be the change you wish to see

3\. Focus on strengthening your team members (designers and product managers
included!)

4\. Ensure your engineers are given ownership and leadership opportunities

5\. Do not be afraid to let someone else lead - actually encourage this

6\. Do not overload yourself (surprisingly easy to do)

7\. Expect the amount of time you spend developing to decrease

8\. Expect the amount of time you spend in meetings to increase

9\. Actually spend time learning the business your code supports

10\. Become a resource to the non-technical ppl your team supports

A lot of good advice in this thread, but remember to have patience with both
yourself and your team as you take on this new role. Nothing changes overnight
and it might be a number of weeks/months until you find your groove.

Congratulations and best of luck.

------
varjag
Hello, I've been in your position many years ago, so my 2 cents of hard earned
experience.

If your project pipeline has a non-coding architect, they better be your
subordinate. If they are not, be prepared to push back on their design
decisions. Ideally they should have a stake in the project delivery.

When some estimate, deadline or feature complexity feels off to you, listen to
your inner voice and stand your ground. No matter what others, with more
seniority/authority/clout in the company think.

Take care of your team. Get rid of slackers, but don't overwork the others.

Accept responsibility for the failures, and share success with the team. "I
failed", "we succeeded".

------
unoti
Remember that the programming is the easy part. Planning and collaboration
doesn’t come as naturally for most engineers, and becomes increasingly
important the higher level that you go. This is because large software isn’t
built by one person that goes all Superman and codes it in isolation; larger
software is done in collaboration.

1\. Collaboration is key:

1a. When there are differences in opinion on how to implement something, your
desired outcome is that the right thing happens for the company, and that
everyone feels like their opinion was heard and legitimately considered. You
don’t want to alienate even the most junior engineers even if you have
absolute power over them.

1b. You need a good relationship with your business partners/customers, with
your boss, and with your direct reports. Make this a top priority.
Productivity improves drastically when the customer loves you. You need the
upward, downward, and lateral relationships healthy because it’s crucial that
you and your people feel safe to talk about the truth and work on solutions
together. Counter example: people don’t want to ask for help or talk about
what they’re feeling uncomfortable about because they think they’ll be judged
as incompetent or a problem child. It’s important that you don’t feel that way
when talking to your customers or boss, and that your people don’t feel that
way when talking with you and each other. Foster a culture of love, respect,
and acceptance to help with this.

1c. Pick your battles. Figure out for example when a design decision really
matters strategically and when it can go either way. Give your people as much
latitude as you can to give them a chance to learn from their mistakes.

I drone on here about collaboration because some of my larger failures in the
last few years are because of running afoul of these ideas. Forgetting these
ideas often leads to winning the battle but losing the war.

2\. Constantly work to empower your people And figure out how they need to
grow. Figure out their target growth areas, keep notes on those, give them
opportunities to grow and learn in those areas. Watch how they do, and give
them feedback every chance you get about what they did well and how they can
do better. Never miss an opportunity to show them how pleased you are with
positive things.

------
vbtemp
If you establish a strong, rigorous software QA process, everything will be
like butter. Your team will feel more confident about the product they release
- and thus about you and each other, and you will have fewer emergencies to
deal with, moreover with this virtuous cycle in place you'll generally be more
on top and proactive about problem when they occur, rather than it just being
another stressful thing in the backlog.

------
lbriner
One thing you might not have had to manage up until now is dealing with
conflict and/or under-performance. This will really cause any insecurities of
yours to surface and make it feel very awkward in the workplace. If you feel
like you need it (and you probably do anyway), have some therapy on your self-
esteem and confidence, once you have dealt with that, discipline can be much
more objective and less weird!

------
gshdg
Read at least the first few chapters of Camille Fournier’s _The Manager’s
Path_.

~~~
strictnein
Another good book to read: Radical Candor

~~~
jkereako
+1

I'm not a manager and I found a lot of value in this. I now ask my manager and
my peers for immediate feedback anytime I lead a meeting. I've also adopted
the habit of providing unsolicited feedback.

------
throwawayeueq
I would like to urge you to consider that maybe there is nothing to fix and
maybe people are actually not interesting around you. I realized that I had
the same"symptoms" as you did, but only sometimes. I started being worried
just like you, but then I looked closer into how I communicate and with whom.

There are people who have a very different life, which I deliberately choose
to avoid. Talking to these people diverges into talking about myself as there
is always something exciting happening somehow, and they do ask about it
(maybe out of politeness, but I'm a bad judge for that). These people sadly
form a majority of people around me.

However, there is a much smaller number of people who I can listen to for
hours and I genuinely care about what they have to say, so I ask a lot too.
These people are really excited about their lives and have stories to tell. In
my experience, not a lot of people have that. Also, they tend to care about
things that I can say least imagine someone caring about.

So overall, maybe there is nothing to fix on your side here. At least, I
think, there is a possibility of this.

~~~
throwawayeueq
Sorry, wrong thread... :(

~~~
bitcoinmoney
Can you link the thread you were replying to?

------
bkirkby
When you have a disagreement about how something should be done, think that
your role is to try and convince the other person. If you don't convince them
and their way is safe enough to try, don't stop them from doing it.

If it's not safe enough to try, then understand when you use your authority to
stop them there will be a strain on your trust relationship that you need to
deliberately rebuild.

------
nurettin
>> What advice would you give a new, inexperienced, and ambitious tech lead?

Do try to keep things simple. By that I mean if you have the choice between a
simple rpc framework and "the netflix microservice architecture with message
queues and scalable container orchestration", do learn the latter, set it up,
scale it to multiple sites over a vpn, but in the end,

you know what to pick.

------
troughway
@Voxoff,

What have your experiences and tasks been so far as a mid-level developer?
What were you in charge of? Did you have a regular rapport with other
departments, with clients, stakesholders? Did they talk to you directly when
they "wanted things done"?

What are the sizes of the companies that you've worked in already? How big
over all, how big were the teams you were on?

I'm surprised no one is asking these questions to see what existing experience
you do have can contribute to this, because it is possible that this might be
a natural extension of what you already do. It's company-size specific, but
good to ask all the same.

In smaller companies, being a mid-level developer means occasionally having to
make a call that directly impacts the bottom line and talking to the CEO and
clients in a very matter-of-fact way. You wouldn't know that from just the
title of a person however.

------
sailfast
Sometimes this means a bunch of things. For clarity, are you supervising
people on the team or mostly guiding the team's work on a specific product?

In addition to others' recommendations about reading "The Manager's Path"
(this is a must-do! An excellent book) I would take a look at how the team
makes technical decisions and make sure that's healthy, and also make sure you
have an understanding of the core value your product is trying to deliver by
talking with your Product Manager.

If you are the defacto Product manager, make sure you know what the business
is trying to accomplish so you can build the right thing and prioritize
appropriately.

The more I do this work, the more a clear, open, decisionmaking process and a
clear understanding of the value increment power everything else. Context and
a way to talk about it.

One other note: your job will change. Know that. Be OK with it.

Good luck!

------
koliber
Think in terms of risk and ease of changing your mind / product.

Decisions which carry little risk and are easy to undo or pivot in the future,
make them quickly and confidently.

Decisions which carry non-negligible risk but are easy to undo, give some
thought but don’t fret too much. If the risk starts becoming reality, you can
change your mind later.

Hard to change decisions with low risk are tricky. Make sure the time spent on
research and decision making is proportional to the risk, which in theory is
low, but that needs to be double-checked.

Decisions that are hard to undo and carry significant risk should be the ones
you spend as much time as necessary thinking through, planning out, coming up
with contingency plans, building in safety checks and making sure that you can
avoid making those hard-to-make changes should you decision prove incorrect.

------
siddhant
There’s great advice in the other comments already.

One additional resource I would recommend is
[https://devtomanager.com](https://devtomanager.com) , which is a list of
interviews with other developers on how their transition was like.

Good luck on your career move!

------
hartem_
Understand what are the things that you should stop doing, and what are the
new things that you should start doing. What made you a great contributor and
put you in a position to be promoted is not going to necessarily make you a
successful tech lead going forward. You need to start optimizing your work
around different metrics now. How much you produce with your own hands becomes
almost irrelevant, and how much your team produces as a whole, and how quickly
people on your team grow becomes paramount. Another aspect is that you should
be managing up and sideways, be a voice and an ambassador for your team within
your engineering organization. Be on the lookout for what is going on and
provide air cover for people on your team.

------
frequentnapper
Similar thing happened to me a long time ago. One major lesson to take away is
this: everybody on your team is smart and capable unless proven otherwise. You
are not supposed to be the smartest or most skilled developer there and you
are not supposed to be the one to taken on hard technical problems.

Your #1 priority is to be a _facilitator_ in order to keep things on track.
Clear the hurdles and engage with developers on the problems they are solving.
And be humble. Don't treat others like they are less than you just because you
are a lead.

And congrats! Enjoy it and be fully engaged. Also don't step on your
superiors' toes or make them look stupid in front of their superiors. If you
disagree with them, make sure to do it in private.

------
ltbarcly3
You're going to mess up and people will try to manipulate you. Trust yourself,
be respectful and professional, and just keep showing up. You'll get good at
this, but only if you keep trying.

If you don't know what to say or are feeling angry, don't say something just
to have a response. Its super rare that you need to commit on the spot. If you
get negative feedback from your boss, wait a day before you try to start
panic-changing things on the team. Bosses are flighty and under pressure, try
to keep it constructive.

Your main job is to keep the team productive. If you do this, you can leverage
having a team that delivers into raises for yourself and your team --
eventually.

------
slumdev
Assume that, for the people on your team, work is a #4 or #5 priority. And
there's nothing wrong with this, as long as they're giving you a solid 80-90%
effort during working hours.

If you ask them to put work ahead of family or faith or rest, or if you
somehow expect more than 100% effort from them, you're going to drive away the
ones who have other options. And the reason they have other options is because
they're the best ones.

~~~
sergiosgc
I always say people have five productive hours per day. I ask they give me
four of those on working days.

This applies to creative work: development, document writing, content
production and similar. Meetings, sales, email and other types of interactions
are less taxing.

~~~
KptMarchewa
Meetings, sales, email and other types of interactions are more taxing.

~~~
sergiosgc
I don't mean to downplay the effort of interaction-type tasks. It's the result
of observing people around me. I know many people who are happily productive
on sales for 12h workdays. I know no developer who's proud of code written on
the 12th hour.

~~~
adambyrtek
Don't assume that these sales people are so happy to work overtime. They
probably rely on commission and/or need to hit that sales target. Sales teams
are known for super-competitive, target-driven, and high-pressure culture. We
software engineers have it easy in comparison.

------
anonsivalley652
There's no magic. Humility, patience, fairness, learn from mistakes and be a
good listener. There's nothing you inherently lack that can't be acquired
through experience. Don't let titles or status go to your head, because it's
all temporary and meaningless anyhow. Perhaps find a mentor, either internally
or externally, to help you grow into a respectable leader because the last
thing you or any sane person wants to do is evolve into a PHB Lundberg who
thinks they're a superior species. A sense of humor, appreciating people's
good work and self-deprecation helps too.

~~~
pmarreck
“Lumbergh” (as in Bill, from Office Space) :)

------
fredley
The _Manager Tools_ podcast is a good guide to learn management skills.

------
jb3689
It's important to say "no" or "we shouldn't be doing this" especially at
startups. In my experience many startups hit a brick wall and it's the
responsibility of new hires and promos to try and help the company move past
that wall. As an engineer it is often the case that the company is solving the
wrong problems. Running a strong team - that's the easy part. Pushing back on
management and being able to collect data to defend your position and support
your proposal - that's more difficult

------
dillonmckay
There was a good book, written my one of the first Facebook front-end devs,
and she was also interviewed about this topic on an HBR Ideacast podcast...

[https://hbr.org/podcast/2019/08/the-challenges-and-
triumphs-...](https://hbr.org/podcast/2019/08/the-challenges-and-triumphs-of-
a-young-manager)

 _The Making of a Manager: What to Do When Everyone Looks to You_

[https://www.amazon.com/dp/0735219567](https://www.amazon.com/dp/0735219567)

------
tentam
First ask yourself if you are the kind of person that enjoys serving others.
Do you like to help the less experienced guys? Leading ain't about telling
people what to do. So if you aim for that back off.

From my experience having kids helps a lot. Look into your past. Did you enjoy
organizing stuff? Do you like to communicate with people? Do you have
experience lobbing your ideas?

If you ain't scared of that then go and find yourself a mentor. Best would be
if that is somebody you already respect.

~~~
nailer
> First ask yourself if you are the kind of person that enjoys serving others.
> > Do you like to help the less experienced guys? Leading ain't about telling
> people what to do.

Sometimes telling people what to do is right. Sometimes it isn't.

We can bring up a thousand cases proving both.

I recommend the OP reads "The Dichotomy of Leadership" by Jocko Willink, which
is about understanding where the balance lies.

[https://www.amazon.com/Dichotomy-Leadership-Balancing-
Challe...](https://www.amazon.com/Dichotomy-Leadership-Balancing-Challenges-
Ownership/dp/1250195772)

------
kopos
Congratulations on the move!

This may sound very pedantic, but please spend a week reading “High Output
Management” by Andy Grove.

The biggest change that happens when you move from a individual to a team lead
is that suddenly you have a team which you can leverage to get the needle
moving.

This is a great opportunity to punch above your weight but also fraught with
peril if not planned well.

There is a need for a mix of comradeship and accountability which is not easy
to grasp. But please spend a week reading the book

------
issa
I think the most important aspect of the job is making sure that what you and
your team plan will work. Try to keep things simple and use well tested
technology. If you are attempting anything bleeding edge, do a quick proof of
concept to make sure there are no gotchas. Sometimes team members want to use
something novel to solve a problem, and they tend to underestimate the risks
(short and long term). Keep it simple. Deliver what you say you will.

------
pm
You seem to already have it, but admit what you don't know, and don't be coy
about it. You will learn from those below you as much as from those above you.

------
rootusrootus
In addition to lots of other good advice I see here, I would say that you
should remember the old adage "fake it 'til you make it." By that I mean act
the part. Taking a leadership role requires not just a change in action, but a
change in mindset. You need to see yourself as the lead, and at least pretend
to be confident in that role. In time you will actually feel legitimate
confidence in your abilities.

------
gwbas1c
One tip: Make sure that tickets (both bugs and support requests) make sense.

Meaning: Make sure that you're either running, or involved with, ticket
triage. No ticket should go to an engineer without a basic review. (Edit: 2-3
minutes a ticket)

What are things that you should look for, before assigning a ticket to an
engineer?

\- Is the title and description coherent? Written in decent English (or
whatever language your office uses.)

\- Did whoever submit the ticket do an appropriate amount of troubleshooting
for their role? (Or are they just trying to pass work off on your engineers?)
Specifically, if this is a support escalation, did the submitter follow any
troubleshooting steps that you've already documented?

\- If this is a bug, do the steps to reproduce make sense?

\- Do your processes require things like logs, screenshots, videos, ect? Are
they present? (Edit: QE and support need to be trained on what kind of
information to collect before passing a ticket to your team. Being a "team
player" means holding other groups accountable for providing your engineers
what they need to do their jobs.)

\- Is this a duplicate of a well-known issue?

\- Is the bug steered to your team appropriately, or should a different team
take the first attempt?

\- [Edit] Are there multiple bugs / support requests in a single ticket? (I
have a firm one-bug-per-ticket, or one-escalation-per-ticket rule. It just
gets too confusing otherwise.)

The above shouldn't take long. Specifically, during triage, you aren't trying
to _understand_ the bug or escalation. You're just making sure that whoever
wrote the ticket put in enough knowledge that you're comfortable handing it
off to your team.

When a ticket doesn't make sense, just send it back to whoever wrote it. You
might need to meet with other managers to make sure that everyone understands
what you need, and expect, prior to assigning work to your team.

The point is that you should be the filter blocking other teams from sending
crap to your engineers. You can also involve your team members in triage, as
long as your team members understand the difference between triage and
actively working on a bug.

What happens when you don't triage well? Bugs pile up on your team and don't
get solved. Some engineers will be good at asking for clarification for bad
bugs, other engineers will just let them sit.

In this case, when tickets aren't being resolved, the solution is to re-triage
and send back poorly-defined tickets.

------
qrush
Read everything you can from Camille Fournier and consider attending (or at
least watching all you can) the next LeadDev conference closest to you.

------
decentralised
I'd recommend getting a mentor.

In my experience, it makes a world of difference when you have someone you can
reach out to and bounce some ideas off of..

------
chrisweekly
Read "7 Habits of Highly Effective People"

~~~
gwbas1c
Why is this being downvoted?

I haven't read the book, but it has 5 stars on Amazon.

So what's wrong with the book that multiple people downvoted the suggestion?

------
njacobs5074
As several other people have recommended, get a mentor.

If it's company large enough that it has managers who primarily talk to other
managers, you're not going to be able to figure things out quickly enough to
survive in that role.

Trust your team. Never break their trust. If you do that, you will not make
it.

Never put yourself before your team (i.e. make your needs more important than
the team's needs)

------
JamesBarney
First piece of advice is the title tech lead applies to several different
roles. Everything from pm to architect to just most sr. Dev.

First thing to do is go to your new boss and get them to give you an
exhaustive list of your new duties, responsibilities, what success look like,
etc..

Also go to other people who have done well in that role at your company and
ask them the same questions.

------
Quarrelsome
Remember that great teams are not necessarily homogeneous. This means you
might need to tailor parts of your process around your team as opposed to
trying to make your team fit the process. This also means that there is no
perfect template for "developer", because of this you might want to consider a
mix of creative, workhorse, meticulous, etc.

------
sys_64738
Technical leads generally are not managers. There's a lot of confusion here as
to the division between providing technical direction and managing people.
Your task as a tech lead isn't to manage people. If that's being what you're
being sold then get a written description of the job requirements.

~~~
arcticbull
Define manage, lol.

Tech leads work through their team to deliver. To work through their team,
they need to drive to consensus. To do that, they need the support and
understanding of their team, so they need to lead. To lead, you need to
manage. That doesn't make a TL responsible for firing or resolving
interpersonal disputes, but it certainly makes them responsible for
coaching/mentorship/up-leveling in a much more direct and often valuable way
than a manager.

------
jstanier
Hello! I did a Show HN recently as I wrote a book on exactly this:
[https://news.ycombinator.com/item?id=22033129](https://news.ycombinator.com/item?id=22033129)

There's a lot of interesting discussion on that thread that might be useful to
you as well.

------
mindtricks
Take an ownership role in what your team is trying to build and the purpose in
which it's intended to serve. If you don't, people around you won't feel the
need to either. And those that do need you to be an owner when you're not,
will find ways to go around you.

------
zupreme
Make friends with veterans in your field and vertical, and some outside of
your vertical, but within your technical discipline.

Share new and fresh ideas with them and be attentive when they share time-
tested techniques and horror stories.

The horror stories will teach as much, if not more, than all of the above.

------
mathattack
Be very explicit in your interviewing. Follow a process. Have the same people
ask the same questions every time. Ask for a rating immediately after the
interview. See who are the good interviewers over time. Don’t count on
recruiting to source good inbound candidates.

------
Jernik
The advice that I was given when I temporarily took a team lead position is to
overcommunicate everything. Build good relationships with the people you
report to and your peers and (hopefully) you can lean on them and ask
questions as you learn and adapt to this new role

------
ch3ckmat3
Learn the difference between a leader and a boss, and be the leader to your
team, not the boss.

------
disordinary
Protect your team and make sure they're empowered to do their jobs and are
unblocked. Depending on the organisation a lot of pressure may be placed on
your shoulders and you need to make sure that doesn't impact on their
productivity.

------
haseeb1431
its' like a family where you enjoy when the whole family is doing great You
have to think about each and everyone on the team while keeping the healthy
competition. Identify the people's interests and feed them type of challenges
e.g. someone like debugging for those weird things or someone doing research
and coming up with the ideas Lead with the examples Try to connect with them
off the works (depending on the country/location) Bring up the difficult
discussion as early as possible, don't avoid them at any cost Train more
leaders as you're trying to finish your job Take ownership and delegate

------
jakevoytko
This is really late in the game, but I wrote a blog post that summarizes my
approach. People have told me that they have found it helpful.

[https://www.bitlog.com/2017/10/12/what-does-a-tech-lead-
do/](https://www.bitlog.com/2017/10/12/what-does-a-tech-lead-do/)

The TL;DR is that you are now responsible for anything that is not moving your
team forward. If nobody knows what "forward" means, it's your responsibility
to define it. If a code review is languishing, that's your responsibility. If
a person has a technical question and they're junior enough that they don't
know they can ask it, that's your responsibility. If your team doesn't have a
good technical strategy, that's your responsibility. If your team is having
trouble getting technical help from another team, that's your responsibility.

It's not your job to do all of these things, but it's your job to make sure
they get done.

------
sopooneo
Above all else: listen.

Your job will no longer be primarily about creating good code, it will be
about making it as easy as possible for everyone else on your team to do so.

Writing well is very important. I literally spend half my day writing:
tickets, pull request comments, upstream status reports, explaining the
cost/benefit of various options to project managers.

Get basic functionality locked down early and then build from there.

Don't micromanage tech decisions but do make it easy for people to be
consistent with one another by providing a style guide.

If all you do is prevent a few _foundationally_ stupid decisions from making
their way into the project, you're already way ahead. [hint: most really
stupid decisions are not actually any one person's conscious decision].

After all else: listen.

------
mehh
Don't assume what motivated you as an engineer applies to others.

------
hello44
empathy builds trust and trust builds respect, define the box, public praise
private criticism, let them fail, give everyone ownership of something,
promote continuous ideas, teach synthesis from the finest grain possible,
isolate that which varies, abstract, your decisions are reversible make one
and move forward, fall in love with the problem, be cross functional, listen
first then act, stay one chapter ahead, be consistently consistent, make them
smile!

------
richdin
My favorite quote - "A manager needs to provide the tools to do the job remove
obstacles from doing the job and take responsibility for the result" E. Jaques

------
45ure
Be firm yet be fair and consistent; there is a lot of room in-between, which
you can figure out as you go along ─ don't get overwhelmed, as there is no
blueprint.

------
taytus
I have had the privilege of leading a couple of teams.

1- Put your team before anything else.

2- Be as honest as you can about deadlines and limitations.

3- There is time for crunch mode, not all the time is crunch mode.

------
eric234223
TLDR: Be very skilled or be likable.

Be very good than most team members in your tech skills and demonstrate it
when chance presents, that will make them respect your judgement. If your tech
skills are not on par with some of the team members that's fine, but you need
to handle them differently. Time and time again i have seen skilled members of
the team will question authority if they don't get along with team leads.
Remember the cost of replacing a manager or techlead is low compared to
skilled people because they get paid lower usually. You may have to delegate
work but you must be the most skilled guy in the team or you should have a
very likable personality.

------
crimsonalucard
Give your team ownership. Let them be in control of the product as much as you
are. Your team should be made of people more skilled than you.

------
diminish
Focus on results, transparency, trust, iteration

------
duiker101
Your role will probably change drastically. Keep an open mind and be ready to
learn a lot of stuff that is not only writing code.

------
leonardoeloy
1) Serve 2) Don't complain 3) Nobody owes you anything n) Do the rest of the
tech lead stuff

------
lazyant
Read these three books:

    
    
       - The Manager's Path
       - Managing Humans
       - Radical Candor

------
Reedx
As it turns out, there's an entire YouTube channel dedicated to this topic
from an ex-Google, ex-Facebook Tech Lead (as a millionaire)

[https://www.youtube.com/channel/UC4xKdmAXFh4ACyhpiQ_3qBw/vid...](https://www.youtube.com/channel/UC4xKdmAXFh4ACyhpiQ_3qBw/videos)

(more seriously, it's mostly just amusing)

~~~
lecarore
I'm not sure I'd value his advices at more than entertainment value though,
it's half ironic jokes half serious but cynical, and last time I checked he
was pushing hard on his quizz product that turns out to be a bit of a ripoff.
I wouldn't put my trust in that guy too much.

------
imvetri
Give over estimates and save junior developer by mentoring for their next job

------
nthj
My team lead philosophy: engineers that score successes continue to be
successful.

There will always be a backlog of tickets, and you can't hit inbox zero. But
you can hack it. Executives need to increase the Average Sales Price (ASP) and
Reduce Churn. Your team will want to fix technical debt.

Your job is to bridge the gap: help your team understand how their work
impacts customers. Help the business understand how your team's successes
impact ASP and churn rates.

Tell your team they hit the goal. Tell the organization your team hit the
goal. Tell the organization where your team can see you telling the
organization. Many engineers aren't known for their salesmanship, and they can
and should improve, but you can step in and rapidly build trust with them and
the organization by selling their work on their behalf.

Instead of asking for time to fix tech debt, explain to the organization what
the tech debt actually fixes: Reliability (churn), Operations/Chores (COGS),
Resistance to Future Change (ASP), Infrastructure Bills (COGS), App
Performance (churn), and like that.

The weekly 30-minute O3 is your new best friend, especially with non-technical
stakeholders. As a team lead, I usually meet with engineers every other
week—you're a team lead, not their manager.

Understand the differences between Accountability, Responsibility, and
Authority. Responsibility is "yup, we're on it." Accountability means the
business expects you to accept "consequences" for failure. Don't accept
Accountability without both Authority to make decisions and compensation for
the job risk. More than likely someone else is accountable (an actual manager
or maybe a product owner.) Engineers are too difficult to hire to be holding
them accountable. As an ambitious founder-turned-tech-lead I bristle a bit at
this, but at least you can be aware of how things are set up.

But this also means you'll have limited authority, and you'll have to achieve
alignment rather than dictate solutions. Which brings me to:

Pre-wire meetings. If you need a decision to go your way, meet with each
attendee individually first and get their feedback on your proposal. Don't put
together the meeting with everyone until you're confident it's a formality.

You can push back on processes that don't work for you: too many meetings,
scrum ceremonies, taps on the shoulder. "I understand the importance of
schedules and status updates to the business. My team needs protected time to
achieve our best results. Will you help me batch our meetings into tighter
windows so we're able to both put in the work and keep the business informed
on our progress?"

Set up systems. Don't take on all the chores yourself. Set up a schedule for a
"triage" engineer, include yourself in the schedule. I like rotating out
weekly. This engineer intakes all of the bugs/questions/fire drills and
provides answers and verifies things aren't on fire. They are assigned less
critical tasks that week because they'll be interrupted. This gets you
protected time to think.

Set up engineering "pairing office hours" 4-5x a week. You're not a manager:
you still need to be on a Maker's Schedule. Your engineers will need help and
rubber duck sessions, but if you drop everything every time they ask or get
stuck, you won't ever be able to get in the zone yourself. Likewise, they'll
know when you're available to help. Tell them you expect them to come prepared
with a list of things they've already tried.

[http://www.paulgraham.com/makersschedule.html](http://www.paulgraham.com/makersschedule.html)

Read every MR your team submits. Don't comment on the direction 8 times out of
10 (unless you're directly assigned to a review.) You're looking for
opportunities to ask Ben to talk to Samantha because they are both changing
related areas. Great software is built by gardening over months, quarters, and
years. You don't need every MR to be perfect (and that's subjective, anyway),
and you'll achieve better results month over month if your engineers feel like
they have ownership over their work.

On the flip side, if you're the one being micromanaged, try accepting
responsibility for larger time frames. "We will achieve this specific thing by
next Friday. We will provide confidence updates on Tuesdays and Thursdays."
Then do it. Every time, if you can. The reason the CEO can go play golf on a
Tuesday afternoon is because he accepts responsibility for improving the
valuation of the whole company by 120% by the end of the year. The junior
engineer accepts responsibility for one JIRA ticket, and is likewise expected
to be available from 9-5 most days.

Read both Peopleware and The Mythical Man-Month. You're not a manager, but
they will help you articulate your frustrations and give you tools to talk to
management.

Email and twitter in profile, let me know how I can help.

~~~
kaskavalci
One of the best answers on the whole thread. It is good to know the things I
suffer most (no deep work because of interruptions) are quite common. Your
post deserves to be much higher on the thread.

------
briandilley
\- hire into your weaknesses \- hire people smarter than you

------
Spooky23
Listen. Protect the team.

Don't let ambition get in the way!

------
exabrial
Listen. Set an example. Promote others.

------
geori
Listen to the manager tools podcast.

------
rubyn00bie
Well, I have been where you are, so here are some lessons I learned:

1.) Delegate. Have nothing to do.

This is not about being "lazy" or not doing "actual work," it's about giving
autonomy to your team. If you do not delegate, your team will constantly be
blocked by you and you will not retain them. If you delegate properly, and
trust your team, it'll feel like you (sometimes) have almost no job at all.

A pretty solid way to delegate, is to find out where people want to go next in
their career, and offer up decisions/work based on helping people get there.
It also prevents #2 on my list...

2.) Do not horde work.

It's shitty, I've done it, and learned from it. Every-fucking-time I
accidentally did it, it sucked, it would (a) take forever because meetings can
eat your life, (b) stress you out because of the time constraints, and (c)
MOST IMPORTANTLY someone on my team would have benefited from, and enjoyed,
doing the work more.

3.) Hire people smarter than you.

Don't be afraid to hire people with more experience than you or who are
"smarter" in some specific field of expertise than you.

You will learn so much by being open to others knowledge, your team will
benefit even more by having other people able to guide/mentor/coach them.

4.) Blame process, not people.

When shit hits the fan, you should ALWAYS be cool as a cucumber. It doesn't
matter what the reason is, if someone pressed the wrong button, configured
something badly, whatever it was cannot be undone.

What you need to do (AFTER) is a root cause analysis; I have always been a fan
of the "Five Whys" but to each there own (you can probably google that to get
started if its new to you or to find others). You can then implement, document
it, and develop new process so that shit storm doesn't happen again.

Just in case the focus here on process wasn't clear, let me spell out the
other part to be clear: do not every fucking blame your team. Do not ever
blame an individual. You will fix nothing, and your team will grow to hate you
as you toss people under the bus.

5.) Shit rolls down hill, it also rolls up hill, and you're always stuck
pushing it.

Depending on where you are in the org, this isn't quite so heavy, but
truthfully, as a manager/lead the bullshit you weather for your team is what
defines you. The more you prevent rolling downhill onto your team, and the
more you prevent rolling uphill to your boss(es), the more loved you will be
by both.

At some places, without bullshit densities strong enough to make a strange-
quark, this won't be an issue... At other ones, this will very likely be what
keeps your bosses and your team happy in an otherwise (i.e. other departments)
not-fun workplace.

6.) Be kind and be honest.

Don't treat people like family. Treat them better. Families have bullshit,
families hide things, families have history, families might be kind, but they
can also be brutal. You also can't fire your "family," but you might have to
your co-worker... So, just fucking don't.

What to do instead? It turns out, when push comes to shove more than anything
they want (a) honesty about the state of the company and their status, (b) to
be communicated with kindly. Don't yell at people, or talk about them behind
their backs, don't marginalize people or groups you don't think are in the
room (I cannot believe what some people will fucking say when they think "no
one" is listening)...

And we all can have a bad day and maybe rudely reply to someone or do
something not our best-selves, and in those situations you just gotta learn to
proactively and meaningfully say "I am sorry." It's even good for you if
people find out you did, because it means you're not an asshole, and again
they'll trust you more.

The best will be when people give you that same respect because you've set the
standard and they want to uphold it...

7.) Your title doesn't mean anything, your experience does, it is the real
investment here and completely defined by what you do and how much you put
into it.

8.) If it truly fucking sucks, leave. Don't be afraid to jump shit; with a
"lesser title." See #7 again, as long as you've done it right, you'll very
likely be getting paid more anyway :)

------
nhumrich
A must read: peopleware

------
jiveturkey
fake it til you make it

\- not kidding

------
fadifrancis
very interesting advice here. thanks y'all

------
jbarbosa
Recently, I've been in charge of Growth at Whitesmith. For the last months I
can pretty much resume everything to talking with everyone. Not only it will
give you insights where you should go, but it will also help your team to
solve their pains and frustrations and they will naturally grow and follow
your lead.

So, a few (sorry, not that few) notes:

* Too much information around You will feel lost in a sea of information. There's an infinite number of posts, blogs, threads talking about tech lead. You will want to read everything before doing any action. However, it's impossible, and you'll quickly feel overwhelmed with all that info.

* Listen your team and know their pains More than knowing everything about tech lead, what's really important is to know your team and where you're going. 1on1's with everyone will bring the knowledge for that. They will tell you their frustrations and pains. These will be the first insights on where to start your job.

* Delegate and communicate Just because you're not coding, it doesn't mean you are not working. To me, that was a big issue. So, in order to sort it I try to communicate regularly so that the team has visibility of what I'm doing. Also, most of the times you will have too much on your plate. Feel free to delegate. I'm pretty sure that you will have volunteers for certain areas (in my case, infrastucture, front-end,...)

* Iterate fast Iterate and fail fast. One of the biggest pains I felt was the fear of releasing something which was not perfect or that I was not secure of. However, it will never be perfect. Your team is not like any other team described in blogposts. Teams are always different, which mean different approaches. Instead of waiting too long for releasing something almost perfect, release, fail and improve more often. Be aware that if you iterate once each quarter, at the end of the year you have 4 iterations and 4 data points. If you iterate monthly you will have 12 iterations. Way more precision to fine tune your team.

* Are we engineers, or are we humans? (terrible pun with The Killers song) Each person of your team is different, each one of them has a different life with different problems. We all have our own different battles in life and sometimes we need to spend energy and focus on other things rather than work. Keeping that in mind some are more shy, some not. Some will think that they own you something, that they are behind schedule and hurting the team. Usually these people won't feel comfortable about talking their pains. Be their leader and help them. Actively listen each one, give them space and support when necessary.

* Align expectations Make sure that there's a common goal, and that everyone understands it in a crystal clear way. At Whitesmith, more than knowing how to master a couple of techs, our team must be critic about the product. Our good engineers will then find the best tools for the job and then you can step in to define boundaries on which tech is better for that specific problem. But it depends a lot on the company. Question yourself what's your most common project type and what's your best set of tools. Do you want to be really good at just that? Or do you prefer to be more flexible and allow other tools? Define standards, some role models of your team so that people know where the team is going and consequently where they are going too. It kind of reminds me of Ryanair. All planes are 737 to minimize differences, processes and overall complexity.

* Growth aka learning, enineering manager, space for your team to improve Give your people space to grow. Try to find time for them to learn something new. However, it's also important to find a place for this knowledge to be applied. Learning without a purpose and not being able to apply it regularly, seems to be almost as furstrating as not growing at all.

Sorry for the long post. A lot of things coming to my mind atm. Feel free to
reach out and disagree. That's actually what I do as a tech lead with my team.
Also, I've been told the book "The Phoenix Project" is a really nice read for
tech leads.

All the best!

~~~
kaskavalci
I am late to the party but here it goes. Everybody recommends to take care of
the team and nurture. But nobody mentions what to do with slackers. Tech leads
don't have the authority to hire/fire people but responsible for their
performance. If one decides to only give 10% of their time to work, how one
can motivate them?

------
tikiman163
I have a few pieces of advice. The general theme, always focus on making other
people successful, and make sure things are meaningfully organized with both
current and future team members in mind.

1\. Checklists make everything easier. What needs to be in the checklists
should be the most common issues that come up during code review or have been
related to defects that made it past the dev environment.

2\. Good agile documentation means all business rules/application behavior
requirements should be in the story/task and in a centralized wiki. This makes
it possible for new team members to familiarize themselves with application
behavior quickly, and that list of behaviors is also the documentation on what
needs to be tested so QA can implement integration and regression tests.

3\. Every major code review needs an organized explanation of code changes per
business rule. I've got my team using a OneNote where they initially write
down each stories business rules at a high level for non-technical people in a
list format and add sub items that describe an architectural overview of
changes like design patterns and technologies used, and an addition sub level
briefly describing code changes. I also have them provide links to an articles
they used to make decisions or that describe design patterns used rather than
needing to rewrite them. This rarely takes longer than an hour for a large
story and it provides a semantic map between business logic and technical
terminology for non-technical people and a sort of historical stream of
consciousness that can be looked back at to get a feel for the history and
direction for a given project.

4\. Assess how team members are doing with technologies they use and get them
whatever training they need.

5\. No matter how experienced a developer might be before they join your team,
new team members should always start out by getting the project to run and
fixing bugs. Expecting too much too fast is a guaranteed way to lose high
quality talent.

6\. Always keep your ego out of everything and if someone is getting defensive
about code, remind them that there is no such thing as perfect code. There is
always room for improvement, and the focus on any changes or
development/architectural decisions must always be about the potential future
cost of each decision. Principals like Dry and Solid are important, but over
implementing them will always result in difficult to maintain code.
Abstraction is only good if it doesn't lock you into a design pattern that
might not apply to the future state of all application behaviors you might
need in the future. Also, reflection based code is cool to implement and a
huge pain to get right let alone maintain or update.

7\. Always beware implementing anything you're excited about. Code should
always be focused on efficiency and maintainability, never on how cool or
familiar a specific tool is. This is sort the same as keeping your ego out,
but more about keeping your excitement out of things.

8\. Developers should talk to customers, and logging should be implemented in
ways that enable analyzing feature usage and user feedback. Many feature
request come from managers, but the end users are the people that really need
to feel like your software improves their lives.

9\. Beware any list that has a psychologically pleasing number of items
because it is definitely padded out or shortened to reach that number.

------
jacquesm
I'd refuse. You've basically disqualified yourself. If you mean well by your
team you go and train under an experienced tech lead and then move up when you
think you are confident you can actually do the job. Mid level developers
should not be tech leads.

~~~
CathedralBorrow
Funny how you can judge an entire person based on one post. Is this a skill
anyone can learn or so you have unique insight into the human mind?

~~~
jacquesm
It's called reading.

If you feel that you are a mid level developer then positioning yourself as a
newly minted and inexperienced tech lead is a recipe for failure, someone else
will be called in later on to clean up the mess, assuming the company
survives.

I'm only responding to the content of the post, if there is more that I'm not
aware of then you're free to point me to it but for now this stands unopposed
based on the facts available. After all, what better way to interpret the
question then to answer it truthfully?

