top | item 3407643

Ask HN: I just got my first team lead. What should I do?

89 points| endymi0n | 14 years ago

Dear Community,

Lucky me (29, Software Engineer from Berlin, Germany) recently got a new job as a Lead Architect for a startup.

Now I'd say I'm not a bad engineer, but I've never been much of a "people person" or a natural leader. Although my colleagues treat me with a lot of respect, I still feel a little awkward. I'm a total newcomer to the "business" of managing, regularly keeping up with people and doing hiring/firing decisions, but I think I'm worst at delegating. Since the company is still pretty small, there's no choice for me than to get my hands dirty on coding and sysadmin stuff as well. Unfortunately, I'd rather do it all myself than entrusting and encouraging others with it, so I'm kind of playing my old role. Also, I'm having a hard time being a good listener, since I'm always coming up with my own ideas and notice that I'm mostly talking about myself which doesn't exactly make me more likeable, but it's hard to stop.

Reading "How to win friends and influence people" already helped me a lot with my people's skills, but I'm still struggling to get it all into practice.

Have you ever been in a similar situation? Do you know of any great resources, tips, tricks, hacks, communities or seminars short of doing an MBA (which I definitely wouldn't do due to time constraints and the bullshit factor)?

I'd really appreciate your help, especially from the engineer-turned-manager folks!

Best,

Dom

50 comments

order
[+] tkiley|14 years ago|reply
Three years ago, I was the sole employee/founder of my startup. Today, I'm CTO of a 21-person company with a 6-person dev team.

As an individual developer, my default loop is "Find something to do. Do it. Repeat."

As a CTO, my default loop is "First, cycle through all my employees and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat."

[+] nekojima|14 years ago|reply
"First, cycle through all my employees and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat."

This is what I did in my role as team leader and earned the equivalent of Employee of the Year at a large firm. Its quite simple to say, more difficult to successfully implement and often even harder to quantify during a subsequent job interview, because when you do it well, to you its common sense or straight forward doing your job. As a result, its not necessarily easy to train into the behaviour of others. But it is quite easy to undersell (its easy for you) or oversell (can sound arrogant) how you did it and doesn't have the impact it should or could have on a hiring manager. Obviously referrals from those you worked with can be a much better testament to the impact you provided.

[+] ScottBurson|14 years ago|reply
As a CTO, my default loop is "First, cycle through all my employees and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat."

I have nothing to add except that this struck me as such an excellent distillation that a mere upvote seemed inadequate.

[+] jbob24|14 years ago|reply
I made a similar transition myself and have one piece of advice for you.

Forget about all that "leadership" and "management" bullshit. Seriously. When you have direct reports your primary function is to serve them. I'm not kidding - I know it sounds all squishy and kumbaya-ish but if you think about what it means to serve somebody else you'll have a really good compass to guide you through your day.

Everybody seems to throw around bits of advice around what to do and even how to do it. The problem is every person is different and since people make up teams, every team is different. Plus, they change. Don't get lost in the what and the how until you understand the why. Everybody on your team has different needs and serving those people means understanding their needs. Some people need to be micro-managed and some people need to be given tons of space. Don't let their needs/situation effect your respect for them and always remember that people change.

Your to "why" will be different than anybody else's answer to that question and will give you immense insight into which "what" and "how" things you pick up from all that advice that is out there. It will also determine what kind of a leader/manager you are. This is important.

Identify what makes you and others around you happy and you will probably find yourself asking "what should I do?" a lot less often. Oh, and in case it's not clear, don't be so naive to think that "happy" is all fun and games and wine and roses and group hugs. And don't forget that you serve the "team" too - it's an entity with its own needs and challenges.

[+] bane|14 years ago|reply
Absolutely agreed.

There's a saying, "shit rolls downhill." I'd argue that a surprising amount of your job will be to keep that from happening to your people. Providing top-cover is one of the most important ways you can serve your team. Keep the crap off of them so they can concentrate on doing there jobs.

[+] steamer25|14 years ago|reply
Agreed. This reminds me of the article from a few days ago about maximizing shareholder value being the 'dumbest idea': https://news.ycombinator.com/item?id=3392500 .

If you consider yourself a mini-CEO, you could think of your employer as your shareholders and your direct reports as your customers. If you can serve your customers well enough to make them happy and effective in the long run, you will also please your shareholders.

This may require periods of investment where you focus less on delivering immediate results and more on removing impediments for and building experience in the people who could help you achieve exponential results in following seasons.

"Two are better than one because they have a good reward for their efforts. For if either falls, his companion can lift him up; but pity the one who falls without another to lift him up. Also, if two lie down together, they can keep warm; but how can one person alone keep warm? And if someone overpowers one person, two can resist him. A cord of three strands is not easily broken."

[+] scottm01|14 years ago|reply
Shortly before I started managing engineers I read "Managing Humans" (I'd already been following http://www.randsinrepose.com/) and found it helpful. One of the best resources I found was (luckily) my own boss. Find others in a similar (or higher) position and talk with them regularly, openly, and candidly about any challenges you're facing.

I wish I had better advice, but what you'll find is that being a good manager/team lead is at least as hard as your old job (and probably harder). Continuing to do your old job alongside it, while probably a good idea for your own job satisfaction/sanity, will only make it harder.

Random bits of advice I find helpful:

* Your primary job is to shield your direct reports from management BS (false priorities, unrealistic deadlines, company drama); while this is less of a problem at a small startup, don't ignore it. Your secondary job is to make your direct reports look good; promote what they're doing and make sure what they're doing is aligned with the company's goals.

* Schedule 1:1 meetings. See Rands' advice on how to structure and run them, but basically keep them short, informal, and regular. Start with a softball and use it as a time for your direct reports to warn you about any upcoming problems that may be bubbling. Avoid the temptation for status reports, one larger team meeting instead, etc. Sit down with each individual direct report and get to know them better.

* Set clear goals and priorities for everyone.

* Avoid the temptation to micro-manage. You may eventually find you have an employee who has to be micromanaged, but most people hate it and will find it counter-productive. While this sounds obvious, it's hard for someone who likely got to their new management position because they were the best at the job they're now managing. Let people make mistakes and then let them recover from them.

[+] bmelton|14 years ago|reply
The first thing you need to do is learn the capabilities of your team.

Who are the best programmers? Who are the best programmers for the given types of problems you have to solve? Who are the most creative thinkers? Who is good at meeting deadlines?

If somebody is bad at meeting deadlines, why?

One of the best programmers I've ever worked with was always missing deadlines. Turns out, it was only because he was really bad at estimating time. Once I learned that, and started handling some of his estimates for him, he was the best programmer on paper too.

As for managing, I try not to micro-manage, but it's easier to get a sense of who does and doesn't need it once you understand, from a manager's perspective, who is capable of what, and to what degree of consistency.

For the actual management, most of the time, I would just periodically see if anybody needed any assistance, and let them know that I was always happy to help where needed.

[+] endymi0n|14 years ago|reply
Great advice, thanks! On a sidenote, that guy:

"One of the best programmers I've ever worked with was always missing deadlines. Turns out, it was only because he was really bad at estimating time. Once I learned that, and started handling some of his estimates for him, he was the best programmer on paper too."

...was most probably me =D

[+] kls|14 years ago|reply
I think I'm worst at delegating

I'm having a hard time being a good listener

Wow that is a description of me 10 years ago to the T. I was always the guy that people turn to and the guy that pulled the project out. It can and does go to ones head. Be very careful to not become arrogant, I really wish someone gave me that advice 10 years ago.

As for your case specifically, the delegation is going to be the hardest one and the one that you have to cross the chasm on. Given your nature (I know from experience) it will be hard but you just have to trust in your people. Hire people that you believe are smarter than you, this will help in delegation because you will perceive their opinions higher than your own. Also try to remember, you design systems the way you do because it worked for you, they will design it their different way because they are drawing on what worked for them, look at it as an opportunity to learn a different way of doing things. Many times when people like you and I enter this type of role we believe that we are the authority, it can make working with our personality type unbearable when you are a subordinate. Instead take it as an opportunity to learn. Help them make their solutions better, not make your solutions better. Just because you are the lead does not mean you are the best at every situation, be humble and try to be an eternal student, that is the best advice I can give you.

[+] gmantastic|14 years ago|reply
The best advice I could give is, whenever someone you manage brings you a problem, resist taking it away and solving it for them. Instead, give them some pointers on how they might solve it, but leave ownership of the solution with them. This is hard to do consistently, particularly when it would take you less time to do the work yourself, but the long-term effect is that you grow a team of self-sufficient people, who only bring you problems when they have tried hard to solve them themselves and genuinely need your help. This in turn means your time is freed up to work on the most important things.
[+] elliottcarlson|14 years ago|reply
This is very important imho - the temptation to just do it yourself is for me personally a hard thing to resist, but you will definitely strengthen your team this way and gain more respect from your developers. You obviously want to be there for them for any help and advice, but allow them to be the ones to solve it in the end.
[+] ThereRNoDumbQs|14 years ago|reply
Congratulations on the new job!

It sounds like you've already identified your weaknesses, and they are EXTREMELY COMMON - especially for really great engineers.

You used the word entrust, and this is key. It demonstrates that you have a great sense of ownership over the work, and feel personally responsible for the team's output. This is great, but now that you are the team leader and not the team itself, you need to get three additional ideas burned into your brain.

1: The members of your team are working with you toward a common goal, but they are not performing brain surgery on your first-born child. A little imperfection and inefficiency is OK. In fact, it's good business.

2: It is your job to set that common goal - which must be based on a business goal - and get the team to buy into it. Getting buy-in is, ironically, more a function of how well the individuals on your team believe you hear their opinions than how well they hear yours, so this is a great opportunity to practice your listening skills. But once you are all focused on the goal, the fact that someone solved a problem differently or more slowly than you would have will bother you less, because you will know you were doing other important stuff at the time and together you got closer to the goal than you would have alone.

3: Innovation means trying things and learning from them. The more people on your team try things, the more you all get to learn, so give them the space to try and celebrate the process as a team. Yes, sometimes that means people will try things you already know won't work, but sometimes you will learn a better way, or fail in a new way that leads to a new success. None of it will be a waste of time.

Finally, remember that these apply to your own performance on the team as well. Allow yourself the time to experiment and learn as a manager. Listening, delegating, and coaching are all learnable skills that require practice more than study, so just work at it and know that you'll get better at it.

[+] DanielRibeiro|14 years ago|reply
Agile Coaching helped quite a lot (even if you don't use Agile)[1].

A CTO of a very successful startup on the valley recommended me Difficult Conversations[2].

As long as you remember that empowering other people to do great work is very valuable in itself (as it is a multiplier), you can motivate yourself into getting to understand this side of software development.

It is not only important for tech leads, but for CTOs, and open source project leads.

Good luck on your new job!

[1] http://pragprog.com/book/sdcoach/agile-coaching

[2] http://www.amazon.com/Difficult-Conversations-Discuss-What-M...

[+] j_baker|14 years ago|reply
I generally think of it this way: a manager tells you what you have to do. A tech lead tells you what you'd be stupid not to do. You won't have much formal authority. At the same time, you hopefully won't be under much formal authority if you chose the right startup.

At the same time, you earn a significant amount of "political capital". People will probably give you a certain amount of deference. And you earn the unique benefit of having a unique perspective on something.

Don't think this can't all be taken away from you, because it can, either due to political or technical considerations. You can get marginalized by someone with an agenda, or you can lose the respect of your peers with a few wrong decisions.

The good news is that you really don't need great leadership or people skills. You just need to convince people that the benefit of having worked with you is greater than the cost of having to put up with you. People are willing to forgive the occasional foot-in-mouth incident or the occasional screw up. You just have to make sure people know what benefits you're providing them in return. And having been objectively right or gotten great results will more than make up for having accidentally hurt a couple of feelings in the process.

[+] akg_67|14 years ago|reply
Congratulations on becoming the lead. You already got some excellent advise in this thread.

I found some good advice about managing and leading teams in books:

"The Wisdom of Teams: Creating the High-Performance Organization" by Jon R. Katzenbach, Douglas K. Smith

"Leading at the Edge : Leadership Lessons from the Extraordinary Saga of Shackleton's Antarctic Expedition" by Dennis N. T. Perkins, Margaret P. Holtman, Paul R. Kessler, Catherine McCarthy.

Few suggestions from personal experiences:

About not delegating, getting your hands dirty can play to your benefit if positioned right as trying to understand what team members goes through in their activities so that you can make better decisions that are in best interests of team members.

Consider your team lead role as mentoring role and not as a "manager" role. Allow people to make mistakes and do lesson learnt type sessions.

Depending on the size of team, have lunch/ informal gathering as a team and also meet with individual team members informally at regular basis.

Watch patterns and signs in how team behaves around you. If they are quiet around you or always agreeing with you, you have a problem.

[+] devs1010|14 years ago|reply
Some of the comments below are a bit scary to me, it seems everyone things architect = manager and I work in a company where this is also the prevailing thought and I just can't agree with this line of thinking. There are a lot of nuances to developing a complex application and the longer someone gets away from coding on a daily basis the more they forget these things, they forget how to "think like a programmer", they overly abstract things and trivialize things. I can't help but realize that the "architects" who I have dealt with who no longer write code always seem to be stuck in the past, they want to use older libraries, patterns, etc that they used back when they were programming even if the prevailing wisdom of the platform currently differs. I guess the only advice is to be aware of this and don't become like this, you still should be at the code level, at least part of the time, if you are truly an architect and not just a manager.
[+] spacecowboy|14 years ago|reply
Accept that being a lead is going to be challenging. That whatever tasks you have taken on for yourself, you may or may not get to them when you want to. Accept that you will be the bridge between upper management and the technical folks and that you will be dealing with any number of issues.

Also, keep in mind that there are lots of resources out there about how to lead people and be a better leader. Look to the Harvard Business Review ( http://hbr.org ) for some good resources on how to be a better leader.

At the end of the day, as a lead, there is a process that you can follow to help you along. The process includes the following: 1) Meet with your team and work out what tasks are assigned, follow up with each team member and confirm that they understand the assignment by asking them to describe to you what they think they are doing, follow up with each team member on their assignment and measure their progress, and finally, check in with them to review their work and let them know when they are done or have completed their assignment - then start again. Use this process no matter how small or big the assignment is.

Some folks use an agile like approach to management of projects and one of the nice things out of this world is SCRUM and the concept of daily stand up meetings. One of the things I would recommend is to get into the rhythm of meeting with your team for about 15 minutes every day to check progress, see what they have accomplished and see what they are working on for the next day and to see if there are any things keeping them from meeting their goals. If you ever hear a complaint, that is a red flag and try to use whatever resources you have to remove those obstacles.

At the end of the day, you only have so much time and energy. Do the best you can and never loose your cool no matter what the situation is.

Best wishes and a great new year!

[+] five18pm|14 years ago|reply
Do you like your team members? If not, find out why and find a reason to like them. Once you develop that basis to like your team members, everything else will fall in to place. You will take interest in their activities, not just in terms of getting your work done, but in terms of what they are trying to achieve.

Talk to your team members on an individual basis frequently and in an informal setting - people are much more open in an informal setting. Keep these meetings to 5 mins. If there are more topics than can be covered in 5 mins, increase the frequency of meetings, not the length.

Never do your team member's work. Help them in every way for them to do their work, but just don't do it for them.

(Break every rule / advice that people are giving out. Finding what works for you is one of best parts of management)

[+] hkarthik|14 years ago|reply
The fact that you're even asking how to be good at this is a really good sign. I wish some of the folks that I've worked under in the past would have done the same. There's lots of good advice in this thread.

My advice is to find a way to handle the pressure from above without letting it affect how you treat your team. Technical teams are built on a tremendous amount of trust and understanding.

If you're constantly getting hammered on by your non-technical boss, try not to pass the buck and hammer your team in turn. You may find yourself in very combative situations with the nontechnical leadership, and you certainly wouldn't want your teammates to feel the same way about you. That makes for a very ugly environment, and most smart people won't stick around for too long if that happens.

[+] sriramk|14 years ago|reply
Set up weekly 1:1 meetings. Never miss them. And whenever possible, do the meetings outside, even if it is just taking a walk.
[+] martininmelb|14 years ago|reply
I came here to say exactly the same thing... so, here's my other piece of advice: Think about very good managers that you've had; what was it that made them good managers? Try to emulate that (for me it was the weekly 1:1).
[+] martininmelb|14 years ago|reply
Don't express appreciation, show appreciation. What do I mean?

Express appreciation: Hi Jane, I really appreciate that you worked until midnight to get rid of that bug.

Show appreciation: Hi Jane, I looked through the code - and you've really improved it by replacing that buggy lookup with a hash function.

Anybody can do the first and it does not take time or effort. The second shows that you've taken some interest and taken the trouble to understand what they've done.

[+] ct|14 years ago|reply
An MBA probably won't help you and may even make it worse.

The first step is recognizing there's a problem and seek help, which you've done and I congratulate you for that. I think you just have to be more patient and humble.

Even if you think you're the smartest person in the company, you have to learn that others can bring something to the table also. Just setup what the goals are of the meeting at the start then give people a chance to speak and withhold your own opinion until after you've heard everyone else talk at the end. Again don't try to interrupt too much and give everyone a chance to voice their opinion, and use it as an opportunity to try to learn something from others (ie. respect that others have something to teach you as well). And sometimes you'd be surprised at learning something you didn't expect or know beforehand that would change what you thought should happen.

[+] felideon|14 years ago|reply
You might want to simply look into reading some leadership books. Leadership 101[1] is one you can read in probably an afternoon, to get you started. From there John Maxwell as a few more books on Leadership as well.

As I haven't been in a team lead position myself, I'm not sure if any of these books can help you learn how to delegate as that seems something that would take time and practice.

I have however, worked under a few engineer-become-leaders that are simply horrible leaders, and I -wish- they would read a book like this some day and have it click. Your success as a leader can possibly be measured with how successful you are at raising leaders under your wing.

[1] http://www.amazon.com/Leadership-101-John-C-Maxwell/dp/15964...

[+] DyumanBhatt|14 years ago|reply
I tend to be of the mind to learn by doing. As many of the others have mentioned, have conversations with your team members and spend time with them. A common practice is to grab lunch with them. This will help you get to know them and become more comfortable talking and listening to them.

I would also recommend regular work oriented meetings with them. Some may disagree, but I think regular meetings to review work, and go over tasks has a lot of value. You will see when they are finishing up their work and be able to hand off tasks more readily. Also do what you can to get feedback from them on you, and don't take it personally when they are critical and learn from it.

Ultimately there is no one answer and you have to find your own style as well as a style that works for your team. A conscious effort and trial and error will be better than books.

[+] dudeguy999|14 years ago|reply
Make lists. That's 90% of the job of a manager. Always have an answer to "what should I do next?"