Ask HN: How do I become a better team lead for a small, junior dev team?

60 points by redthrowaway 7 years ago | 17 comments

I'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.

But I didn't get a CS degree because I'm great with people. I've had some limited management experience, mostly interviewing applicants and running standups. I'm now responsible for the performance and well-being of a team of junior devs, and I'm definitely out of my comfort zone.

I want these guys to succeed, and I want to succeed in helping them succeed. But I'm mostly flying by the seat of my pants and I'd like to learn from others who have been in my shoes.

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 7 years ago |

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 7 years ago | |

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

techcode 7 years ago |

Read this https://www.goodreads.com/book/show/33369254-the-manager-s-p...

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 7 years ago | |

Another good read:

https://www.amazon.com/Managing-Humans-Humorous-Software-Eng...

veddox 7 years ago |

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 7 years ago | |

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 7 years ago |

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 7 years ago |

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/

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

p0d 7 years ago |

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 7 years ago |

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

sirrele 7 years ago |

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!

arthurcolle 7 years ago |

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

Shots fired

austinjp 7 years ago | |

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 7 years ago | | |

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

peteypao 7 years ago | |

exactly what i thought!