Adam Lynch

I've been thinking about team leading a lot lately. When revisiting advice a friend asked for when transitioning to a team lead position, I decided to flesh it out and put it online. Most of the following will hopefully be helpful to anyone leading a team or any manager, although some will be more relevant to leaders of developers and developers transitioning into leadership roles. If it helps anyone, great. It will be a good reference for me at least. Alright, let's get to it.

Delegate, delegate, delegate!

I've struggled with this and have seen almost every person in a leadership position struggle with it as well, but trust me, it's really worth getting over. If someone can do something 80% as well as you or better, delegate! Focus on the stuff only you can do. Don't feel like you have to touch everything and be the best or most active person on the team. You're responsible for making sure everyone else does their best and grows.

If you don't delegate enough, people feel like they're only doing the boring stuff and they'll feel undervalued as a result. They'll find somewhere they can have more impact and feel more valued. You'll be stressed because everyone is asking you to make a decision. Key decisions will stall as they wait for your call. The team will already have enough dependencies, which you're trying to resolve; don't become one.

Always try to find more ways to delegate. Don't just give people work to do in small orchestrated pieces. It makes people more reliant on you. They learn less. Although it is hard when you know how to do it and they're still learning. 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. Show people how they can safely spread responsibilities and knowledge.

Make yourself as redundant in the day-to-day work as possible. Ensure the team has the skills, knowledge, experience to get things done. You don't need to have the final say on everything and solve every hard problem. This gives you more time to work on the stuff only you can do.

On the flip side, as you start to delegate more, you will become less familiar with the actual code and feel like more of an imposter. Don't let this stop you from delegating though.

Efficiency

Keep the team as efficient as possible. Protect them from distractions. For example, this also includes telling them about potential disruptive process changes being considered and meetings they'd like to be in but really don't need to be.

Emphasise knowledge sharing. Avoid someone fixing bugs related to X because they implemented X originally. Single points of failure are hard to avoid. People love to own their work. Taking responsibility is good but often leads to one person holding exclusive knowledge of something. Give someone territory and they'll likely become defensive.

Unblock the team, address issues that are holding back the team or individuals; dependencies, external issues like blocking stakeholders, lack of knowledge, etc. Reduce friction. Always look for ways to make your team's life easier so they can do their best work. Shield them from company politics, pointless meetings, and other distractions. Resolve disagreements.

Get the most out of different personalities. Understand what individuals need to perform optimally. Compromise, cultivate a team spirit. Promote continuous integration.

Determine the type of lead you will be. Don't identify yourself or become a title / dependency. This will only limit team members. The title isn't an excuse to micro-manage. Don't read into the word "lead" too much. People shouldn't be at your mercy or at your beck and call. Focus on getting to a point where everyone can learn from each other and get their best possible work done.

Keep an ear to the ground. Too much talk within the team might indicate a lack of productivity, decision making, or that they're enjoying themselves too much. If it's a bit too quiet, it might mean everyone is head down and there'll be problems once their code is integrated, or that people might not be getting along.

Communication

You have to be an excellent communicator. There's no room for negotiation here. Be assertive, be clear, and be honest.

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. Discover and minimize misunderstandings early. The same goes for your interactions with stakeholders; play your part and remove ambiguity when it appears.

This is a simple one but when messaging a team member about having a chat with them, give them a rough idea what it's about in advance.

Disagreements aren't criticism. They're healthy as long as they don't block progression or damage relationships. Don't be mean, but say what you mean, early. Make sure everyone has a fair say. There's always a better way but what is the most feasible solution right now? Try to get agreement from everyone and ensure everyone understands the outcome.

Encourage your team to challenge you, to tell you when you're wrong, but respectfully. The last thing you want is for them to be afraid to point out when you're wrong. Be your own harshest critic. Be honest when you don't know X and don't be afraid to admit you're learning. Everyone is.

You need to be serious and firm when giving criticism. 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.

We just need to stop letting people to trick us into thinking we actually CARE about the arguments we have over things we haven't researched. If we did, we'd research.

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, that they've looked at the details. Don't second guess the small stuff. 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. This is related to having a personal attachment to details ("perfectionism") but I'll leave that for another post.

Represent and protect

Represent your team. Voice their concerns and share updates with them. Celebrate and recognise their hard work and achievements. Protect your team. Be an umbrella. Take negative criticism for them and only pass it down if they really need to hear it. Having anyone as a lead makes the team stronger, no matter who it is. Someone can stand up for the team and make things happen. Under promise, over deliver.

You now represent "the man". Understand top-down decisions; you need to in order to believe in them, and to then make others believe in them. Support your superiors. If they don't understand the challenges you're facing, that's your fault. Give them more situational awareness. Support them. Make them look good.

Manage stakeholder expectations as well as internal perspectives of your team and their work. Criticise team members if they're less than nice with other teams, for example. They're representing the team. Larger organisations can be tough as not everyone will respect the work being done by your team. Avoid pointing fingers or blaming other teams. I could benefit from being more savvy when it comes to politics but that's not what I'm about. You're all on the same side, act like it. When listing our values at Teamwork, the following is often cited as a good example:

Let the other person save face, even if they are clearly wrong

Process

Don't go overboard on process. Start small, experiment, keep what works. Team members' past experiences and opinions will vary a lot. Make it clear that the process is evolving and can always be improved with a suggestion from a team member. Each team is different, you'll discover the best processes. Set as few rules as possible and strive for minimal viable bureaucracy or process.

You shouldn’t start with the Spotify model. Spotify didn’t start with the Spotify model. You shouldn’t start with Scrum. Scrum didn’t start with Scrum. You should start by identifying what you want to improve, and introduce constraints that force the improvement.

I'd recommend doing daily standups. They're really good when done properly. It should ideally be at the same time everyday, as early as possible. If everyone is in the same location, actually stand (otherwise people go on too long). If one person is remote, everyone should connect to the video call separately and ensure sound quality is good. If someone's late without notice / rescheduling it, start without them. Listen to each other, otherwise there isn't much point. People shouldn't go into too much detail or interject when others are talking. If a discussion needs to happen, finish the standup first, then anyone can stay for the discussion if they want. To sum up, keep it short and efficient.

Schedule a regular chat with each person individually. Give them a chance to highlight successes or issues. This could be related to code, colleagues, your leadership, the company, home life, etc. Listen, empathise. Make sure you're up to speed on the work beforehand; it should be about them, not a status update for you. This is a good time to give feedback but keep it light. Try to give good with the bad. These conversations are really good; you'll be surprised by what comes up or how honest people will be. A lot of the time, the person will point out what they could improve on before you even get to it.

Probably the most difficult part of the job

The role is people oriented, and people problems are not trivial. Even the toughest bugs are a lot more straight-forward to solve than "How can I keep this person happy?" Keeping morale high has to be a focus and part of that is mixing the right people. Each individual person can differ in what drives them, in their skills, weaknesses, experiences, standards, and more. 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.

You will have opinionated team members and you'll have to drag words out of others. 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 though. It's tempting to solve problems for people but you should step back and let people fail. 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. Make developers around you better. It's a sign of a great senior developer.

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 / legacy code. There are times where all of us have to do something we don't like and people like this are less likely to improve their attitude in my experience.

A new technical mindset

Even though the role is certainly people oriented, people come and go, what we build remains. You might be used to coming up with elegant solutions to clear problems as a developer, but you will now have to resolve hazy problems with far reaching solutions. Focus on the long term when it comes to a design decision. Is this solution advancing us towards our overall goals? Is it compatible with foreseeable future changes? You don't want to make a decision that makes it more difficult to make changes or add features later. Strongly consider long-term maintainability, architecture, deployment, stability, availability, scalability, and so on. Think about the whole ecosystem of apps, alignment, etc.

It's important to still be hands-on with code though. Some lessons can only be learned this way. Keep in touch, stay up to date, be respected. Identify patterns over time and keep an eye out for anyone implementing a pattern which'll come back to haunt us. Be careful when dropping the team lead role to play full-time developer on the other hand, other unnoticed issues might bubble up until they are too big to solve quickly.

In general, I'd promote test-driven development, as well as continuous integration, deployment, and delivery. Check out Steve Smith's Measuring Continuous Delivery talk if you haven't seen it. You should also measure app performance, feature usage, and so on. Don't go overboard but carefully select a few key metrics to begin with.

Let the team influence code style. I absolutely hate arguments over code style, e.g. tabs vs spaces. Discuss as a team and agree, but keep it short. Document the outcome. It shouldn't be acceptable to argue about it in pull requests; code either matches the code style or not. Plan a separate time to discuss a change to the code style if needed. Where possible, use linting tools which automatically formats code as it's written or pre-commit, e.g. Prettier.

Monitor gaps in the team and knowledge, fill them. If a new developer joins the team with valuable insights or coding style, re-align the team / integrate that.

It's easy to get sucked into the current work and dragged into the weeds but try to stay ahead of the team. Look at what's coming down the line, find problems, solutions, prototype. Steer the technical direction based on these discoveries. This, like everything else, is a lot of easier once you have great team members which you trust.

Transition and expectations

The transition is not easy. It's a lonely role and your context will be unique. Even others in the same role in different teams in the organization will have different values and problems to solve. Relationships will change. There is a change of perspective from working alongside people to managing them while working alongside them.

You'll find yourself reframing conversations not to offend anyone, more than you'd like. You need to bring positive energy even when you don't feel like it. Expect to have to give a lot of yourself, to facilitate, especially when the problem is unclear or complex. It's a bit lonelier. On the other hand, you get to see the whole picture. You get to step back and have more influence on the success of the company.

Time management is difficult. There are a lot of interruptions and context-switching. Some of these interruptions will be from other teams; everyone else has priorities and everything needs to be done ASAP, but you have to think of your priorities. The person shouting the loudest shouldn't necessarily always get your attention first.

Writing code and dealing with other issues is always going to clash. Deciding to be a tech lead means less coding, unless you work longer hours (but this isn't sustainable). There's less time to focus on a problem as a result and it's hard to measure your own performance. It's just not as tangible. As much as you'd like to shut your door to focus, you must be accessible to your team. You might find yourself coming in early, staying late, or working on the weekend. This again ties into delegating and the imposter syndrome.

What do I know?

I'm no expert and I don't get everything right. I have been leading teams for just a few years, but I have also had a broad range of experiences; all sorts of management styles (good and bad), tiny startups, large corporate companies, and more. My current role is "product lead" at Teamwork which is like a product manager, project manger, technical lead, and lead developer rolled into one.

There are far too many people to thank for their hand in my role and this advice. Managers I've had, many authors of books, articles, and speakers. Thank you! If something I said doesn't feel right, that's OK. You can read as much as you like on the topic, but a lot of it comes with experience. Feel it out. Try things, make a few mistakes, learn from them.

I'm always open to improving so please feel free to give feedback on what I've written.