
Ask HN: How do I become a better team lead for a small, junior dev team? - redthrowaway
I&#x27;m a senior developer at a small startup managing a team of three co-ops and one junior dev. My team members are great: eager, smart, curious, and effective. I rarely have to teach them how to solve a problem; they naturally research and implement solutions.<p>But I didn&#x27;t get a CS degree because I&#x27;m great with people. I&#x27;ve had some limited management experience, mostly interviewing applicants and running standups. I&#x27;m now responsible for the performance and well-being of a team of junior devs, and I&#x27;m definitely out of my comfort zone.<p>I want these guys to succeed, and I want to succeed in helping them succeed. But I&#x27;m mostly flying by the seat of my pants and I&#x27;d like to learn from others who have been in my shoes.<p>What are some good resources I should look at? What are some things I might be neglecting that I need to pay attention to? How can I best be effective in my new role?
======
austinjp
Flying by the seat of your pants is completely normal. Read about "imposter
syndrome". Obviously you can still improve, and you will.

Some basic suggestions:

You'll learn from experience while you go, far more than from reading books
(although that's still good). The fact that you're asking is a good sign. Find
a mentor and meet them regularly, in person. You'll benefit from an external
perspective.

Work out how to support your team while keeping everyone's expectations
realistic. It's easy to burn yourself out by taking on too many
responsibilities. In cynical workplaces, this can lead to you being hung out
to dry and alienated, which is thankfully rare in my experience.

Short (5 minute) meetings at the beginning or end of the day are better than
hours of chat. Usually.

Your job includes removing your team's barriers and problems. Ask them what
they are.

Figure out what motivates individuals and empower/enable them to get it.

Praise in public, criticise (constructively!!) in private.

Constructive criticism: extremely hard to get right. Sensitivity is critical.
Ask for training. Objectives need to be S.M.A.R.T. Don't dwell on the
negatives. Find ways to reach the positive. You will never perfect this.

Protect your team. Do it without pissing off your colleagues and superiors.
This is not easy :)

The best managers I've known have qualities that I know when I see, but would
struggle to define. Breezy, friendly but professional, reliable, genuine,
clear understanding of both big and small picture... difficult to cultivate
all this but not impossible.

Get up from your desk. Meet people in person. Meet your mentor in person. Walk
and talk instead of email/slack. Skype is not "in person". Your interpersonal
skills will improve.

Finally: things will go wrong. This is painful. It happens to everyone, don't
beat yourself up. Carry the good things with you and learn to let go of
failure. I'm still working on this one!

Anyway. That's a scattergun offloading of some highlights I've learned.
There's no recipe, but there are some basic ingredients. Oh... everyone's
different as are their circumstances, and none of the above may apply.

Good luck, you can do it.

~~~
redthrowaway
Thank you for this reply. You got what I was getting at but didn't articulate.
I appreciate it.

------
techcode
Read this [https://www.goodreads.com/book/show/33369254-the-manager-
s-p...](https://www.goodreads.com/book/show/33369254-the-manager-s-path)

I wish I had it 5-6 years back when I stepped up as TL (it wasn't written
yet).

Actually you might as well get your team members to read it too. Unlike the
title might make you think - book covers both management and tech (individual
contributor) paths.

~~~
pieterr
Another good read:

[https://www.amazon.com/Managing-Humans-Humorous-Software-
Eng...](https://www.amazon.com/Managing-Humans-Humorous-Software-
Engineering/dp/1484221575/)

------
veddox
I haven't been in that precise position, but I have been in other leadership
positions. The biggest lesson I've had to learn is: it's all about the people.
First and foremost, leading is a social skill (although there are of course
technical components involved too). As a leader, your job is to care for your
followers. For a person who is as task-oriented as I used to be (and you seem
to be similar), that is a tedious lesson to learn. But once you've learnt it,
it turns out to also be very rewarding to you personally.

Two books that really helped me:

\- The 21 Irrefutable Laws of Leadership (John Maxwell)

\- Leaders Eat Last (Simon Sinek)

~~~
laurentl
This.

Empathy (i.e. the ability to understand what’s going on in someone’s head) is
a key leadership trait in my opinion. The good news is that you can develop
this skill.

First and foremost, listen. Use 1:1 meetings to talk about _how_ the person is
doing, not what they’re doing. Ask open-ended questions. One of the most
underused and most powerful questions in the workplace: “how does that make
you feel?”

Pay attention to weak signals, like someone changing their daily routine,
being snappier than usual in team meetings, etc. Learn how the people in your
team usually behave, what they like and don’t like.

Then, put yourself in their shoes. This is easier than you think: if you’re
used to writing code, chances are you can emulate pretty complex systems in
your head (like the behavior of the piece of code you’re working on). A normal
human being is a complex system that you can learn to emulate, by which I mean
that once you know how someone usually behaves, what motivates them and so
forth, and you know their current situation (see step 1: “listen”), then you
can take a pretty good guess at their internal state.

Once you know how your team works, both as individuals and as a team, your job
is simply to keep them in a state of maximal happiness. And they will move
mountains.

------
DarwinMailApp
I think you've taken a great step already - asking for advice and learning
from others.

As soon as we realize that we're not alone and there is a wealth of
information to learn from, we are taking a proactive step in becoming better
leads.

I would also suggest; \- Host regular (perhaps every two weeks) meetings to
discuss how the team are feeling. Gather their feedback and make changes based
on it.

\- Do some light reading in your downtime on the topic.

\- Try to think in their shoes. Imagine what it would feel like working for
you if you were one the dev team. That will allow you to appreciate where they
are coming from.

All in all, be positive!

Ensure every complaint is met with a positive response. Make everyone feel
valued. Always listen to their opinions.

Have fun!

------
kat
The Manager's Path by Camille Fournier This book validated a lot of my fears
and concerns. It also gave me much more insight to see how other
managers/directors above me see my role - rather than just focusing on your
reports.

Also, join Rand's manager slack. [http://randsinrepose.com/welcome-to-rands-
leadership-slack/](http://randsinrepose.com/welcome-to-rands-leadership-
slack/)

Even if you only have time to lurk on that slack, the discussions have been
incredibly illuminating for me!

------
p0d
Be kind but consistent. When I have had drama it tended to be over non-
technical issues such as pay, time-off, notice period, stuff like that. It’s
best your team respects you first and likes you second.

------
codechapin
Read a lot! A lot! psychology and relationship books (even the ones that are
about romantic relationships)

------
sirrele
Hey I this is legit the same thing that I said to someone else that had a
similar question here and I think it addresses your questions..

\---

I am not sure what role you are actually in with this start up but at the end
of the day its really going to be more about what you enjoy more... HOWEVER,
here are my two sense from my experience of the years. I am going to assume
that this "tech lead" has the potential of growing into a CTO role or some
exec/admin role within the organization structure. Regardless everyone in this
situation will reach a bridge where they are going to have to pick management
or a "hacker" that is always going to stay in the code regardless of the
transitions. I personally have chosen the technical route in the situations.
Here are some bigger points just to outline..

1\. Set the team culture.. it speaks volumes having the highest role also on
the ground with everyone else (as much as they can) 2\. Choosing to not be
part of code will create risk for yourself and for the company, especially if
you were a vital part of the scaling 3\. No one needs to be a delegator full
time.. or better yet, just don't be. 4\. A PM role is a FULL-TIME role.. can
it be done part time? Of course.. but its going to be half ass and that person
will not have a full picture of the current state of the software, the team
pulse, the product pipeline, and ect. 5\. Do what you have to do to make
things work but have a clear path insight collectively. Your role may be a
hard to define role overtime, especially as a CTO but there are many members
of a software dev life cycle for a reason. There is risk of things becoming
detrimental if clear processes aren't the goal. 6\. Be protective over your
time. Allocate at least 4 hours of your day to code even if you wont be able
to get all that time in. At least you are communicating the need and
importances of your contribution. 7\. GET A MENTOR! Get someone that knows
what they are talking about and don't just take anyone.. Thing through what
you need in a mentor and ask for one. You need a sounding board, but just be
careful of conflicts of interest. 8\. Focus on knowledge transfer and team
processes so the team and software can scale. This is one of the harder parts
and should be leaning on whoever is leading the operations to collaborate
with. 9\. Use agile + JIRA and if you have the company funds add Confluence..
and get your team on the same page.. YES there are other options. I am really
not debating that but these are solid solutions that are going to assist the
PM and the entire team as you all develop procedures.. 10\. It doesn't exist
unless its a ticket.. I would be sensitive and put thoughtful effort when
introducing non-technical people to the software dev life cycle. However, user
contracts/requirements, tasks, bugs, QA, design, etc are all HUGE influences
of how well your team will do over time. Build a culture around that.

Thats enough even though I have a bit more too say.. at the end of the day you
will figure it out. I think the better leadership choice is to keep as much of
your time in code as you can as well as the bigger picture while at the same
time, develop the processes to allow for scaling in all areas..

Hope that helped!

~~~
sirrele
Sorry for my typos as well.. clearly didnt edit and I am headed to bed! Hope
the points were clear enough to resinate with you

------
arthurcolle
> But I didn't get a CS degree because I'm great with people.

Shots fired

~~~
austinjp
Yeah, I think this line is easily misread. I suspect the meaning is: "I have a
CS degree, but my people skills need work".

~~~
redthrowaway
In all honesty, it's more like, "my people skills need work, so I got a CS
degree"

~~~
AnimalMuppet
Well... don't feel alone.

