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 šš¼.
Top comments (4)
Great tips for leading a team in general, the fact that it's applied to remote teams makes it all very challenging but inspiring at the same time.
Just a curiosity, you mentioned an issue tracker than you've listed apart a bug tracker too, what's the difference between them? Because usually we have a bug tracker and a product backlog, but while the first is for bugs (or issues if you want to call them like that too), the second is for tasks before they get properly scheduled. Usually we as developers know how to use them both but obviously we don't deal with their schedule and assignment to the sprints which is usually left to the producers even though they check with us priorities and time estimates before.
Good question! The way we see it is that a bug tracker is a system that keeps track of any software bugs. But an issue tracker is something bigger - it's a system that allows you to track both bugs and features and all other type of tasks that you may have while building software.
So basically a bug tracker is a type of issue tracker. A good example of an issue tracker is Jira. A bug tracker example is Mantis Bug Tracker or BugHerd.
Great read :) I have been the lead/manager for remote teams for a couple years now and if there would be one thing I would add to the great points already stated would be pair programming/availability.
When working remotely there is inherently less communication like you stated, when you as the team manager/lead make it a point to have availability for pair programming it can do wonders! Almost every weekly team sync (weekly department team sync to discuss interesting features everyone had been working on) I make it a point to note that I would love to pair on any challenging problems in the upcoming week.
Not only does this create a great line of communication between yourself and your team but it creates stronger relationships with everyone. When the team knows they can come to their team lead with challenges without being judged for it you build a healthy team dynamic. As a team lead, having consistent pairing sessions helps you stay in touch with product health and you can better manage the team.
I personally think team leads or managers should be getting their hands dirty (coding) with everyone on the team multiple times a week :)
Also I love that you mentioned a documentation repo! Great documentation can be one of the most valuable tools a team can have (especially for new hires!).
Totally agree, that's a great point Cory!