How to Lead a Remote Development Team

Here's a sentence that will inspire both joy and terror in a software developer: "We think you should be the team lead on this project."

Joy, for the obvious reason that it's a significant promotion and an indicator that your efforts are appreciated. Terror, because it can sound like a frightening prospect to lead a remote development team.

But reality needn't be that scary. Firstly, you've been given the role because the people in charge believe that you're already showing the essential skills required to be a good team lead.

Secondly, we've written this article, which condenses the most useful and practical advice from some of X-Team's most experienced team leads on how to lead a remote development team.

The Right Mindset

Making the move from being a relatively independent software developer to being the manager of a remote team requires a different mindset. These are some of the most important mindset shifts.

Most of all, it's important to remember that your team consists of experts. They work hard and love their job. You can and should trust them to search for and find the best possible solution to any particular problem.

Your team wants to be trusted too. Your trust will be most visible in how closely you manage them. Micromanagement is almost never a good idea. Instead, tell your team what to build, not how to build it.

Be there when they need you and guide them toward the solution you want them to reach. A gentle touch. Don't force them to write code in a certain way. People program differently and that's okay.

Unless, of course, there's an objectively better way to do things. But even in that scenario, make sure that you have good arguments explaining why you want your team to write code in a certain way.

The Importance of Communication

Communication is at the heart of your role as remote team lead. Nearly all project hiccups will come from miscommunication. The importance of frequent, calibrated communication cannot be overstated.

Firstly, when you kick off the project, you need to communicate the goals and expectations of the project, as well as the work ethic you expect from your team.

Secondly, the nature of remote work gives a different dynamic to software development. You're not working together with the rest of your team in an office at the same time. Unexpected problems can be dealt with quite organically in an office, given that a team can quickly change its focus, solve the problem, and carry on. But that's not the case for a remote team spread around the world.

As such, it's worth scheduling in discovery spikes at regular intervals to better understand the hidden complexities of your project. Try to figure out what could be possible roadblocks down the line. What could go wrong and how will your team react when it does?

Finding out the answers to those questions will make you much more resilient to problems and will allow you to make better estimates for your project's deliverables, to the point where you'll be more efficient than a non-remote team that doesn't schedule in these discovery spikes.

Thirdly, make sure you define and use the communication channels that you want your team to use. Transparent communication in shared channels will almost always benefit your team (except when it comes to feedback - more on that later).

You can keep these channels tidy by tagging the relevant people when announcing something, by creating threads, and by highlighting the information that everyone needs to know. Slack lends itself particularly well for that, as you can create emoji walls that are certain to catch people's attention.

Finally, ask your team to regularly update you on what they're working on and to let everyone know if their availability changes. This is important because you all work remotely; it's not obvious when someone isn't working unless it's properly communicated.

Meetings

When conducted properly, team meetings are a good, efficient way to get everyone on the same page and to help your team understand what the next steps are. Make sure all meetings are added to your team's shared calendar and ask your developers to let you know when they can't join.

Additionally, it's important that you stick to the schedule on your calendar. Respect people's time. You should not be late to the call, nor should anyone else on your team. The calls start on time and end on time. If you need more time to discuss certain things, schedule in a new meeting.

Meetings are also an excellent way to assign action points to people on your team. Make sure that all action points are assigned by the end of the meeting. Never leave an action point unassigned.

Giving Feedback

It's worth reading my previous article on how to give better feedback. Feedback is important for the personal and professional development of the developers on your team.

If you're sharing positive feedback, do so publicly. Share good feedback on channels or public calls. Don't make it too flowery or over the top. A simple statement of what the developer achieved and the good impact it made will do.

While positive feedback can be shared in public, negative feedback should be shared in private. You never want to embarrass someone. Additionally, when someone isn't performing well, try to investigate why. There's usually a deeper reason why someone is underperforming. They're not trying to sabotage your team. Be empathetic to their situation.

This won't always be easy in a remote team, but it's worth probing a little deeper. Show the other person that you're there for them if they want to talk about whatever is on their mind. If someone wants to talk, it's usually faster to hop on a quick call instead of going back and forth over text messages.

Task Management

The responsibility of the project ultimately lies on your shoulders. That's why you should always keep an eye on the progress of the specific tasks you've assigned to developers.

I say specific tasks, because tasks should always be made as detailed and as clear as possible. If they can be decomposed in smaller deliverables, it's almost always worth doing so.

Additionally, make sure your team knows how to add tasks to the issue tracker. The issue tracker is your single source of truth and should be treated as such. A task that is not on the issue tracker does not exist.

Tools

These are your essential tools:

• A bug tracker
• An issue tracker
• A code repository
• A documentation repository

When choosing tools, make sure that they are mobile-friendly and that they do not overlap in functionality. A few examples of good tools are Slack and Google Meet for communications, JIRA for task management, and Confluence or Google Drive to document processes, flows, and meeting outcomes.

These were some of the most important tips that X-Team's lead programmers shared. I hope you find them useful. If you have experience as a remote team dev lead and have some tips yourself, please feel free to share them in the comments below 👇🏼.