I’ve been working completely remotely for around 2 years now. In that time, I’ve experimented with different workflows and combinations of tools to try and achieve the highest level of productivity while minimising unnecessary busy-work.
Although working remotely does present us with some unique problems, most are just reformulations of problems we usually face when running any kind of project.
Making sure progress is consistent, sharing information amongst team-members and maintaining healthy relationships are not new project management problems – they just need to be handled differently when team members are not working together in the same room. Or city. Or country.
What challenges do we face managing remote teams?
Remote work has some unique characteristics. Firstly, the fact that your team is not in the same physical location immediately rules out all forms of physical communication. As well as this, team members are likely to be working different hours, and may even be located in different time zones. Finally, remote contracts are by their very nature more volatile – employees can leave (and join) your team more easily than traditional working arrangements.
These characteristics present us with some unique challenges.
Establishing effective communication channels
Making sure people know what they need to know when they need to know it is one of the biggest concerns of a remote team. It’s also worth mentioning that too much communication is almost as bad as not enough.
The priorities when managing communication amongst remote team members is to minimise information overload and keep the team focused on the important objectives. We also want a single source of truth – one place where everyone can get stuff out of their heads and into a place and format that everyone on the team can see and use.
Tracking and ensuring consistent progress
Another important concern is accurately measuring progress, and then making sure progress is consistent. We need to ensure work is getting done and the wheels are always turning. Without an effective way of tracking progress it’s far too easy to let a slow week of progress slip under the radar. And then two weeks. And then a month.
Maintaining an accurate view of what has and hasn’t been done provides us with two benefits: it keeps the project progressing and provides a constant sense of momentum, which is useful as a motivational tool not only for the team but for the project manager and/or business owner.
Creating and curating company culture
This is one of the most overlooked concerns when building a remote team, but it’s incredibly important. Creating a positive company culture is a key factor in making sure your contractors give you their best and most creative work and stick around longer than a few weeks.
One of the most important ways you should be doing this is by getting your employees emotionally engaged in your projects. To do this, you need to communicate two things: 1) that the project is something worth being a part of (serves a higher purpose and is here to stay: think long-term, not short-term), and 2) they can be a part of that bigger picture.
When a contractor stops working on your project(s) for a couple of weeks, they become emotionally disengaged from your company. It’s when that disengagement happens that it becomes psychologically acceptable to stop responding to your emails, to stop hitting deadlines and to let the quality of work slip.
Slashnode Project Management System
In my consulting business, we use a five part project management system. Each part of the system contains a set of tools and workflows that function together to deal with the previously mentioned challenges.
- Project requirements. A set of documents detailing the high-level requirements of the work that needs to be done in order to successfully execute the project.
- Product backlog. A complete record of all the individual low-level tasks that are involved in finishing the project, as well as the current state of each task (not yet started, currently in progress, finished) and any information required to complete the tasks.
- High-level communications. A medium for high-level, strategic and scheduled communication.
- Low-level communications. A medium for low-level, tactical and “always-on” communication.
- Project delivery. The “production line” where project deliverables are shared between team members, clients, customers, etc.
Note: this post is specifically tailored for software businesses, but the ideas and approach can be adapted for other remote digital companies.
1) Project Requirements
The starting point is to define the work for the team. The project requirements usually involve technical documents, reference materials, architecture diagrams and wireframes.
Balsamiq is useful for low-fidelity mockups, which I’m a big fan of, especially during the early stages of projects. Low-fidelty mockups / wireframes enable you to communicate the important high level details of your requirements without forcing you to make decisions that can be pinned down later. Sketch is perfect for more complicated or high-fidelity mockups.
Google Drive is useful for sharing because it enables you to control on a granular level who can and cannot view / edit different files. It also has a bunch of useful features like version-controlling files, and integrates nicely with Google Apps for Work (which is what we use for email, calendars, etc.)
2) Product Backlog
The project requirements define the work in a strategic, high-level and abstract way, but that isn’t particularly useful for day-to-day operations. We also need a way of keeping track of the detailed, low-level requirements of the project. This enables us to break up the larger body of work into individual tasks which can assigned to members of the team.
We also need one true source of truth – a place where all the work to be done and all the work in progress is kept track of. This means we don’t need to piece together information from different sources to know exactly what’s involved in completing a specific task or how much work has been completed. As a result, we can easily reassign tasks to different team members without redundant communication.
I recommend using Trello. It’s free, easy to use and perfect for small teams and/or small projects.
I set up the following lanes:
- Backlog: all the work that needs to be done, but hasn’t yet been completed. Cards usually include references to the requirements in Google Docs, as well as diagrams and/or wireframes of the desired outcome for each card.
- Blocked: tasks that were started by someone, but cannot be completed because more information is required or another task needs to be completed first. A major priority for the project manager is to make sure “blocked” items are unblocked and moved to “In progress” as quickly as possible.
- In Progress: tasks that a team member is currently working on. An important rule: each team member should have one and only one item in this lane at any time.
- QA: when a team member has finished a task, they move it to “quality assurance.” The project manager will then test the functionality to make sure it’s working and then move the task into:…
- Done: completed tasks. Cards in this lane get archived on a weekly basis.
A graphical depiction of this workflow is provided below.
3) High-level Communications
We need a way to communicate at a high-level about the project requirements, company vision and overall progress of the undertaking. In a typical office environment, we would use meetings for these discussions.
It may sound counter-intuitive to imply that remote teams should have scheduled meetings. Isn’t avoiding time-wasting meetings one of the most attractive arguments for turning your team remote?… but hear me out for a moment.
No – we shouldn’t have meetings as prescribed by the standard office protocol. That is: vaguely scheduled for at least 30-60 minutes, occurring in a physical meeting room with no agenda and no strict end time.
However, quickly speaking with your team a couple of times a week about prescribed, outcome-driven topics is a beneficial thing. It enables you to keep your team on-track and aligned with your vision, and provides an important relationship building opportunity.
We achieve high-level communication via two mechanisms:
The Weekly “Stand-up”
This occurs at the start of the week on Skype. Developers will be familiar with the concept of a “stand-up,” which comes from Agile development methodologies. It involves meeting first-thing in the morning before starting real work, standing around the product backlog and discussing three things:
- What did I accomplish last week?
- What will I focus on this week?
- What obstacles are impeding my progress?
Make it short. 15 minutes on Monday or Tuesday morning is good. Have a simple agenda and make sure everyone sticks to it. Take notes of any action items and make sure they’re recorded somewhere everyone can see them (In Trello, or in an email sent after the call).
End of the week progress email.
All team members send a quick (approx. 3 sentences) email to their project manager at the end of the week. The email contains answers to the following three questions (similar to the “stand-up” questions):
- What did you achieve this week?
- What problems or potential roadblocks did you encounter?
- Can you provide potential solutions to those problems or roadblocks (if any provided)?
You can see an example of a weekly update email here (specifics removed):
Date: Fri, x Jan 20xx Subject: Weekly Update From: User One ([email protected]) To: Corey McMahon ([email protected]) This week I worked on A and B. I did some thinking about C and how it should work - but it looks like you spec'ed it out. The only question I have is D? I think it might be E, but I'm not sure.
4) Low-level Communications
While the weekly Skype and email system is used for high-level, strategic purposes, we still need a way of managing the day-to-day operations and communication between team members.
While email could be used for this, I much prefer an “always-on” chat solution such as Slack. It archives all chat sessions, so team members can refer to it later if they can’t remember what the answer to a particular question was. It also enables you to create multiple “channels” for different discussion topics. A decent general channel set-up (and what we use) is:
- One channel per project for general project discussion.
- One channel per project for automated alerts. We integrate with Trello and GitHub, so any activity for the project on these channels is also reported in Slack.
- A company-wide “banter” channel for non-work related discussion.
- Individual “private message” sessions with team members for one-on-one chat. Any decisions that affect the project or team on a broader level are manually copied or communicated from the PM session into the general project channel.
5) Project Delivery
The final part of the system is actually enabling the team to deliver the project in a collaborative fashion. How you achieve this will depend on the type of project. We build software, so we use GitHub private repositories to host our deliverables.
Warning: software jargon below. Not necessary reading if you aren’t in the software business.
We use git-flow.
Team members open pull requests against the development branch (appropriately called develop) of the repository they’re working on. Pull requests always need to reference a Trello card number. This prevents team members doing work that hasn’t been defined by a project manager (if there isn’t a card for it, they can’t work on it).
Project managers then test the feature branches by checking them out locally and running through the use-cases / user stories. If there are any bugs or changes required, the project manager adds comments to the PR in GitHub, and then updates Trello as described above. If the project manager is happy with the changes, the branch is merged into develop.
And that’s it.
These are the processes I’m using at the moment to run our projects. So far everything is working well, but I’m always looking for new ways to improve them.
I’d love to hear how other project managers, developers and entrepreneurs are getting the most out of their remote teams.
So… what about you? How do you work with your remote team?
Tell me in the comments below.