I’ve been a Team Lead, put in charge of projects with developers several times in the past few years. I’ve found myself in the position again after accepting a recent promotion. A lot of developers try to avoid the promotion to team lead because it involves a lot soft skills that are difficult to obtain or learn on the job.

Most software development teams that I’ve been a part of were are structured in such a way as to optimize a developers time, so that they can concentrate on tasks that provide the most business value (coding). This provides less time learning the necessary soft skills in order to be an effective team lead.

This had me thinking, what makes a good Team lead?

What are the skills required of a Team Lead?

That’s quite subjective, and going to have a different answer for every company. I’ve personally found the following skills essential

Communication

Being able to communicate effectively with people in a timely fashion. For developers this means that you might need to explain something in deep technical detail or write and design a process flow diagram. At the same time communicate with upper management on the progress of the 5 projects that your team is currently working on and provide estimations and projections on completion dates.

Sometimes this may also require you to “manage up”. This might be a polite email prompt to a stakeholder or client that you’re waiting for sign off on a particular design decision. Or a friendly reminder to your boss that something needs their input, they’re often busy and sometimes a little reminder is required. It’s best not to wait for manager to chase you to inquire about the status of projects your team are working on.

Project Management

SCRUM and Agile are great tools in order to help provide transparency to the business, and in my opinion is one of the core skill of a team lead.

One of the most important features of Agile that most companies overlook is that you should only have 1 backlog, and that backlog should be groomed in such a way as to prioritize the features that provide the most business value at any given time.

Having a separate backlog per project simply doesn’t work, what will happen is that you will get 1 or 2 developers dedicated to a project and you attempt to work on projects in parallel with dedicated resources. So you could be wasting time working on low value project work when they should really drop that $5 widget spinner and work on finishing that 500K feature for your most valued client.

1 backlog, 1 Team, 1 list of items that always provides the most business value at any given point in time.

Have a sprint planning wall.

It seems redundant at first blush but I personally find it hard to see large numbers of items in Jira. Walls don’t have that limitation, and also have added convenience of being able to be glanced and consulted by passing stakeholders and development managers who may not be familiar with Jira, but they can consult a wall. Developers can consult the board during daily standups and move sticky notes when they’ve completed a task.

It’s also convenient for reporting and tracking the status of multiple projects/features at the same time at a single glance. It’s not a replacement for Jira, but an additional tool to help visual and manage multiple projects.

Technical Leadership

Developers may look to you for guidance for architecture and design, coding practices, security standards, code reviews. Being able to provide deep technical knowledge and experience when dealing with developers and provide suggestions or examples lead them towards answers and enable them to do their job. And this is key, leadership is not micromanagement. It’s providing direction and giving developers the tools to find the best way to do their jobs themselves.

Managing developers

Managing a team of highly creative people is quite often likened to “herding cats”, difficult to almost impossible. Command and control management doesn’t work with creative people, it stifles their creativity and ability to perform.

So what does work?

• Trust your team knows their job – get out of the way and let them do it. Don’t micromanage and don’t dictate how something should be done. You may not be the smartest person in the room.
• Provide an environment of psychological safety – Instead of pointing fingers and blaming Joe for introducing a bug. Or asking, why did you do it way X instead of way Y. Accept that the failure was a team effort and address the process failure, people are only human.
• Know your people – know who have personality clashes on your team. Know who are subject experts, and allow them to contribute and play to their strengths
• Avoid knowledge silos – get other team members to review each others code, and move them around in tasks to spread domain knowledge around the team
• Avoid distractions – Absorb and deflect items that could distract your team. Constant distractions and context switching kills project velocity
• Give them tools – Ensure that your developers have the tools and resources to do their job. Latest versions of Visual Studio, Resharper, DotPeek, DotTrace.
• Provide a fun work environment. – Coming to work to a dull lifeless environment can kill anyone’s motivation to perform.
• Reward them for a Job Well Done – This is often well overlooked and taking the team out to lunch for completing a major project is always a winner

Getting things Done

I think this is a no-brainer, using David Allens method of Getting Things Done or GTD is essential for managing projects, people, anything with multiple moving parts.
GTD Website

Let me know if you think I’m missing anything.