Adam Lynch, who’s currently leading the development of a new product at Teamwork (what is it, you ask? We can’t say just yet!), shares some of the biggest lessons he’s learned in his time as a product lead. First up: managing people.

I’ve been thinking a lot about leading teams lately. When revisiting advice a friend asked for when moving to a team lead position, I decided to flesh it out and put it online. Most of what I’ve learned will be relevant to any manager or team lead, but some of it will be more specific to leaders of developers, and to developers transitioning into leadership roles.

I’ve struggled with this and have seen almost every person in a leadership position struggle with it too, but trust me — it’s really worth getting over. If someone can do something 80% as well as you or better: delegate. Delegating lets you focus your attention on the stuff only you can do. As a team lead, your job isn’t to touch everything and be the best or most active person on the team. Your responsibility is to make sure that everyone else does their best and grows. If you don’t delegate enough, your team will feel like they’re only doing the boring bits, and they’ll feel undervalued as a result. They’ll look for somewhere they can have more impact and feel more valued. Not only that, but you’ll be stressed because everyone is asking you to make decisions about everything. Important progress will stall as the team waits for your call. The team will already have enough dependencies; don’t become another one. When it comes to delegation, here are a few things to think about: Always look for new ways to delegate. Make yourself as redundant in the day-to-day work as possible. Don’t just give people work to do in small orchestrated pieces. It makes people more reliant on you and they learn less. This can be hard when you know how to do something and they’re still learning, but it’s still worth it. Delegate decision-making for a particular problem to the right person. People love autonomy. Try to ask yourself if the right people are looking at a problem so the best possible decision can be made. You don’t need to have the final say on everything and solve every hard problem — trust your team’s judgment. Ensure the team has the skills, knowledge, and experience to get things done. Then show them how they can safely spread responsibilities and knowledge to others, like new hires or colleagues in other departments. And be warned: as you start to delegate more, you will become less familiar with the actual code and feel like more of an imposter. That sucks, but don’t let it stop you from delegating.

You have to be an excellent communicator. There’s no room for negotiation here. Be assertive, be clear, and be honest. When you’re talking to your team, being specific and confident in what you’re saying about a task is critical. You can’t rely on intention. People will do exactly as you say, so discover and minimize misunderstandings early. The same goes for your interactions with stakeholders. Play your part and remove ambiguity when it appears. A large part of your role will be to moderate discussions within the team. Here are a few tips for keeping things productive (and civil): Disagreements aren’t criticism. They’re healthy as long as they don’t block progression or damage relationships. Get buy-in. Make sure everyone has a fair say. Try to get agreement from everyone and ensure everyone understands the outcome. Encourage your team to challenge you. Ask them to tell you when you’re wrong (respectfully). The last thing you want is for them to be afraid to point it out. Be honest when you don’t know X and don’t be afraid to admit you’re learning. Everyone is. Be serious and firm when giving difficult feedback. If you’re too lenient, it’s harder to say something isn’t acceptable later. The culture and standards of the team come from what you tolerate and promote. Don’t spend time debating that which doesn’t warrant it. Once you have good people, trust that they’ve looked into what they’re talking about and that they’ve thought about the details. Don’t second guess the small stuff. Compromise. When there’s a disagreement over a decision, be honest about how much you care about the outcome. If it’s 2/10 for you but 9/10 for them, let it go. And a quick freebie: when you’re messaging a team member about wanting to have a chat with them, give them a rough idea what it’s about in advance. This can prevent many a freakout.

The role is people-oriented, and people problems are not trivial. Even the toughest bugs are a lot more straightforward to solve than “How can I keep this person happy?” Getting great people in your team is key. Worries about how best to educate and manage fade away and you’re left to figure out how best to delegate. Keeping morale high has to be a focus and part of that is mixing the right people. Each individual person will differ in what drives them, as well as in their skills, weaknesses, experiences, standards, and more. A great leader knows how to tailor their leadership style to different team members in order to bring out the best in each person. You will have opinionated team members and you’ll have to drag words out of others. In my experience, developers tend to provide solutions and opinions rather than facts. This can lead to heated discussions. Monitor these. Get to a solution with healthy tension and without damaging relationships. You also need to give people space to grow. It’s tempting to solve problems for people but you should step back and let them fail (within reason, obviously). Failure is part of the learning process. Notice when people are happy to stay in their comfort zone. Encourage them to improve their weak areas and clear their path. Prepare to have to explain rationales for things. Don’t get frustrated that people won’t just do what you say. Explain. They’ll learn from that. On the other hand, keep an eye out for people who have a problem with authority or taking over others’ work or legacy code. There are times where we all have to do something we don’t like and I’ve found that people like this are less likely to improve their attitude. Make developers around you better. It’s a sign of a great senior developer. This post was originally published on adamlynch.com and has been edited for the Teamwork blog. Thanks for letting us share your tips, Adam! We’d love to hear what you think — what’s been the biggest lesson about managing people that you’ve had to learn as a team lead? Let us know in the comments.