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

When I first landed this kind of role, I was given a copy of "Peopleware: Productive Projects and Teams ". In some circles it is considered a bit of a bible for this topic.

It's kind of an old book, but then the principles have remained the same. It also means this book isn't then laced with specific methodologies of the day or what not.

Downside is its a tad expensive on paperback, but reasonable on Kindle:

http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...

Well...I've been in the software engineering biz for a while now and go between being an engineer, an architect, and manager depending on the company and group. I don't have any formal management training and don't even have a post-high school degree. But I love building software (I started writing assembly on an Apple II+ way back when) and working with people and am in a constant state of learning.

The quick answer is that there's no easy path if you want to be good at this. You need to be aware of your natural strengths and weaknesses, and what you've built up over the years to compensate. If you can, find a mentor, or at the very least have regular lunches or coffee with folks with more experience.

It sounds like you are a technical leader with management responsibilities, which is a very tough position. A lead/architect position without management duties usually means that you are involved with all technical decisions in the group but don't have direct reports. When I'm an architect, I expect the majority of my time will be writing code with maybe 30%-40% of my time split between formal meetings and hallway conversations. I will not take an architect position that has no hands on coding - it's a recipe for failure. An architect/lead will need to understand the business and technical needs and help drive things forward so both sides are happy. Look for quick wins here to keep things moving and 80/20 solutions. Also know when to stand your ground on things that you know are wrong - be able to communicate your reasoning for both engineers and non-technical folks. That role will also need to have strong technical vision and the ability to communicate that vision so other engineers will be able to follow the path. Figure out the types of engineers and what they need to get their jobs done - some like diagrams, some like talks, some like code examples, some just need a few lines in an email. Conversely, you'll need to be able to help the business side understand the technical side. You'll also have to know your team and help with things like pushing things through to avoid engineer navel gazing, balancing NIH attitudes, breaking ties on proposed solutions, slotting in engineering driven changes that destabilize things, helping the engineers understand why they can't rewrite a key component of the system without showing the business value, helping the business understand why adding a fifth story to their building won't work because really have a bicycle, etc.

Architects are expected to be "big dawgs" in terms of technical skills, so it's ok to be opinionated and try to out-think others. Your own style will come into play and you need to recognize it and be ok with how you work - you might be the type who doesn't suffer fools lightly and because you see the solution before anyone else, you just make your vision happen and ram it through. Or maybe you have a high end team and you need to listen to the other ungodly smart people around you and do more consideration. You do need to pay attention to other engineers and business folks, and listen to them.

A good manager requires an addition set of skills. Management is really a career restart because you're really going down a whole new path. The things that got you to the management position aren't the things that will make you a good manager. Being the smartest person in the room does not a good manager make. A good manager creates an environment for others to succeed. A good manager listens a lot and doesn't try to come up with the solutions. A good manager recognizes that the right idea will present itself because the team is awesome. Try to come up with as many options at possible decisions points. If a tiebreaker is needed, a manager should be able to argue both sides convincingly and not take sides (unless one side is just flat out wrong, but hopefully it won't come to that). A good manager will let problems and solutions come up from the team. Managers need to be aware that each person is different and adjusts to each person. Depending on the group, they also need to have a slightly more balanced view of the business then an architect. It does require some politiking as well - you shouldn't go into a meeting for a big decision without knowing where people stand ahead of time. Managers also have to deal with the 'kindergarten' issues like ruffled feathers, misunderstandings, bruised egos, etc. You'll need to know when someone is just venting versus needing your action. And people have lives that impact the team as well - people get divorced, have kids, get sick, have people die on them, switch genders, come out of the closet, find Jesus, etc. A good manager makes a personal connection and gets to know each person's story. This lets you figure out where each team member is coming from and then how you can make sure their needs and values are met at work. People are happy when what they want out of life lines up with what the company needs. Managers need to know when someone on the team is causing issues and maybe isn't working out. Letting someone go is tough, but usually it should be obvious to everyone involved that things aren't working out. It also involves bearing bad news to both your team and other teams. Telling the CEO that your team fucked up and caused customer level issues is rough.

Let's see...what else...hiring the wrong person is orders of magnitude more difficult than delaying a hire. Be super picky when hiring, even if the executive staff is pushing you hard to fill those reqs.

Engineers like to solve problems, so presenting things in the form of a problem can be a useful approach.

Even if you have a solution in mind, start from the top and lead people through. Let them come to the same conclusions you did and when they do, them tell them the pros/cons of each decision.

Sometimes you have to be the alpha dog and make a decision that someone heartily disagrees with - you need to understand their position, be able to echo it, and stay the course.

You cannot take on other's emotional issues - you can be aware and offer help, but you can't internalize them.

Try not to play favorites - this is tough because you'll find people that you connect with easier.

Put yourself out there, let the team get to know you as a person so that connection is better.

You need to keep in mind that you might have to fire anyone on your team at some point, or give them feedback they don't want to hear, etc. So there's a fine line between becoming friends with folks and being their boss.

Have fun with it, I try to keep a sense of play with me because that's part of who I am.

I dunno - that's it for me - this was kind of a lot of stuff without much structure, but I wish you the best of luck. This is a tough change for an engineer but the fact that you're asking these types of questions shows that you care and are willing to change to be better.

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.

Congratulation first.

Managing people is easy—but being a manager is not about managing people.

You have to be aware that managing is not as satisfying as coding and your goals have totally changed from now on.

- Learn to listen—that's so crucial—they're tons of techniques to get a better listener. Listening can be boring but these techniques enable you to listen hours (even with a smile on your face) without getting bored. It's so damn important that I stress it again: you should listen 95% and talk just 5% (from now on meetings aren't fun or a relaxing break, they become hard, boring work).

- Always 1-to-1 meetings—always. Every meeting with more than two people is worthless, try to avoid them, if you can't just keep them short and full of small-talk, fun and non-sense but without decisions. Harsh words, but leading is not anymore about cookie-cutting talks with colleagues. That's one of the big downsides of leading.

- Don't focus too much on your staff—look that they are happy and motivated (most important) and they have always challenging work, that's it. Don't try to be all the time around them—if they need help be there. Don't change your communication, just be yourself, but don't think they are your friends. Focus now on next steps within the company—you are now doing first steps in management and your work changed from working yourself to networking, to give and take and last but not least to power politics (if your startup is >100 employees). Look that you spend more time with peers from other departments and higher level peers in your company. If you can't progress or your company sucks in less than 12 months, look that you spend a lot time outside your company (there're lots of ways) and move on.

- Don't use tactics or manipulative techniques even if you are good in it. People always feels there's something wrong. Be yourself but keep distance.

- Get a mentor or coach with leadership experience in highly volatile environments, preferably outside the company

- Because working oneself is still most fun, look that you keep coding on private projects, even while in office (there're lots of ways). That's good for your own motivation and keeps your coding skills fresh. Otherwise you burnout after 6 months of all the meetings, mails and bullshit. That's important because from now on you will slowly loose close relationships within the corporation, upcoming relations are different, more political and it's important to stay grounded, meet lot of people (again leave your company often, go to meetups, because there you can just be yourself and that makes you happy; if you don't do this you'll quickly degenerate and get isolated because the working contacts are less and less true relationships). To officially code yourself is not an option anymore (which is sad) because after the first bigger mistake your management will tell your that you are not able to lead your folks when they see you coding with them (which would be better but non-technical management and c-level just don't get it)

These are all only very small hints without giving you the big picture which would take more time and there is no book giving a really deep understanding (I've seen many books before I had my first leadership position, none of them is written by real leaders).

If you want more advice: renmarksky at live.com

I like your advice, except for the insistence on 1:1 meetings only. When there's a dispute on the team, the best option is often to grab a meeting room with a whiteboard and hash it out right then and there. Trying to mediate via 1:1 meetings or e-mail threads often just lets the dispute fester and poisons interpersonal relationships among team members.