Project management tips and strategies I’ve learned over 14 years of working with remote teams.
I’ve been working remotely in some form or another for almost 14 years. First, as a student freelancer collaborating with another student in a different city(Oxford and Reading, respectively) then in an Oxfordshire office while my boss was in NY, then with a team in Granada(after I moved to Madrid), and now with a team split between the UK and Brazil, with me in Madrid, still.
Project planning for distributed teams is different from in-house in a couple of ways, and are mostly related to the subtle ways we rely on being visible to give and receive feedback.
For example:
In an office, when you overload people with work, you can see them not bearing up well. Workers can rely on their state being noticeable to someone eventually. With remote teams, you rely on people being able to communicate if there is a problem. Newer team members may not be experienced enough to know what they can or can’t take on in a timeframe, and some members may feel judged if they admit they are struggling with something.
At the coffee machine, you may overhear a colleague comment on a problem they are having with a project, and you might mention it to your manager, who has a great relationship with their manager, resulting in improved work relations, or improved project outcome. Remote team members rarely have spaces to get that kind of“lucky” or indirect assistance.
In an office, when someone comes in feeling unwell or dealing with a life situation(even a positive one, like being back from maternity leave), we tend to to synchronise with them by de-prioritizing tasks(“don’t worry about on any of the X tasks..just focus on Y for today”). We also tend to notice people’s energy, expressions and focus level, and lower our voices subconsciously or become quiet if we sense the mood is tense - this is why passengers in cars are less distracting to drivers than mobile phones on speakerphone, one study found. Remote team members may suffer the effects of disconnections between their current state and that of their presumed state. Like the speaker on speakerphone: we’re simply not able to see and respond to what’s actually going on right now.
In a traditional open plan office, exchanges are often overheard, so if someone is unintentionally insensitive or a little intense, someone will probably tell them they’ve been a little rough. The other person gets support and advice on how to stay professional or turn the relationship around. In remote teams, many chats are had in 1-to-one slack chats, or in project or team specific groups. The only way to get support is to“snitch”.
1. General Principles for managing remote teams
Here are some general principles for planning work with remote team members so things stay healthy, communicative and respectful.
Use a project management tool for the majority of communication. This keeps most communication visible teamwide and avoids“getting bullied by DM” or missing something important because it was said while you at the dentist.
Allow people to assign their own deadlines where possible, determine when is best for feedback, prioritise their own tasks and create & close their own tasks. Making it so only a manager can create, assign and close tasks will suck the energy and motivation out of a team and limits executive thinking.
Have a video chat after or during discussing the weeks tasks, so people can weigh in on tasks that affect them. If your team is across multiple timezones, use comments in your task manager to work out if something should be clarified or discussed in a meeting. A good rule of thumb is: if it’s not clear within two comments, discuss it in a video call.
Don’t create information silos: have all information available to all team members. You may not think the graphic design/copywriting/support team care about that feature on the next sprint, but they may have an important insight or perspective .
Don’t virtually“hover”behind people by asking them to be“online” on slack, or asking to see work before they feel it’s ready(unless they’re your junior and you’re training them).
Instead, ask them to set times they feel they will be able to show you design work or work in testing. They’ll develop a better sense of their own turnaround time this way, and get better at delivering work that’s ready for feedback.
If estimates of demo delivery and readiness for demo repeatedly fails to happen as expected, I’d recommend encouraging that member to use a timer like toggl for getting a sense of their own turnaround time to self correct future estimates. They don’t need to share their hours with you, but they should learn to estimate accurately. There are many other reasons that might affect delivery time, outside of a poor grasp of time. Some may even be your fault(gasp!). Others are to do with team dynamics. If turnaround estimates continue to be off track, it’s time to encourage them to suggest ways they could be better helped, if they are experiencing problems with anyone(ask if they’d like to swap working with X for Y for a period and measure how they react) and to help them learn be more restrained on what they promise to deliver.
If you’re going to work with someone, trust them. Please do not use software that screen captures their desktop or use website blockers to“check they are working”. Nothing makes grown ups act like rebellious teenagers more than signalling they can’t be trusted. Besides, they can use their own ipad/mobile to access those sites anyway.
Don’t judge apples and oranges. Some people’s tasks might mean they complete a lot of tasks per day or push a lot of code to the codebase, while others may need longer to solve something that was started by someone else in a deeper way than just patches, or to iterate through design styles, or find a narrative or spin for that campaign that’s unique and arresting. Some designers are more restrained in holding out on giving“previews” before a design is ready for show; another might show a rougher work in progress, expecting their manager or coworker to“see where they are going with it”. Psychological safety is so important for doing quality, well thought out, work.
Have information on communication expectations and prefered ways of contacting others and being contacted all in a team-wide board or in something like confluence. This board isn’t the 12 commandments: it’s there to be discussed openly as a team and evolve as you grow.
So that was a lot to take in.
But the first step is actually simple: start with questions. Then gather answers.
2. Making the“unknowns” known
As a manager, here are some things to tease out and make visible amongst your team members will help them collaborate more respectfully and with less friction.
I know people roll their eyes at the term“onboarding”, but for if you’re building a team, it’s a good idea to have an onboarding/ welcome to the team board to help orientate new team members. You can link to a google form to allow them to answer these questions without having their answer visible to everyone in a comment, too.
Credit: the following two lists are adapted from this“Know Your Team” post. They are an excellent resource on leadership in general.
A. Establishing work hours and availability
What timezones are everyone working in? How will this be communicated?
What are the expected working hours each person has? What should the overlapping working hours for folks in different time zones be?
If you need to be offline to run an errand or are in a meeting, how will that be communicated?
How will it be communicated when someone is on vacation or traveling?
Are there any times team members should not be disturbed?
What’s the expected response time to messages? Does that vary depending on what the message is, or the channel that it is delivered?
Remember: ask questions from the team and write the group preferences in a way that allows discussion & feedback.
I aim to use work management tools that allow for communicating and respecting all of the above. Since I advocate asynchronous work,(and to be honest, given the time difference between me and most team members) being out for a short time isn’t critical. It’s more important to say if someone is out for most of the day or all day.
Here’s an example of how I communicate timezones, work hours and contact preferences.
My asana profile for a particular client workspace and the channels they use. Each workspace I’m on in Asana can have custom information. Notice how I use the name field to include my time zone so it’s immediately visible to everyone in that workspace when I’m assigned a task or when I comment. In the pop up or profile page, I set my work style and communication preferences.
Project management tips and strategies I’ve learned over 14 years of working with remote teams.
1. General Principles for managing remote teams
2. Making the “unknowns” known
A. Establishing work hours and availability