One of the things I like most about working at a distributed company is that I get to work with people from all over the world. Being exposed to other cultures and ways of life has helped me grow as a person. This perk can however come with its challenges as I learned after leading a number of projects with colleagues spread across multiple time zones.
Coordinating meetings, staying in sync, and maintaining momentum can be tricky at times but it’s not impossible thanks to a number of tools and processes which I’ll cover in this post. I’ll start with the brief because it’s a great starting point for every project.
The brief
A brief is a high level document that tells you everything you need to know about a project. The idea is to keep it short so that anyone can easily consume it and get up to speed with what you’re building, why you’re building it, and the current status of the project. It’s the kind of thing you want to share early in a project to collect feedback and align stakeholders on what you’re trying to do.
Everyone approaches their briefs a little differently because of the nature of their project, company, or stakeholders. I like to treat them as living documents and start with a set of questions that evolve over time as we get closer to delivery. These are the questions I used for my last project:
- What problem are you trying to solve?
- What’s your bet?
- What’s the desired outcome?
- How will you measure success?
- Who are the stakeholders?
- Frequently asked questions
Thanks to its collaborative features, Google Docs is the perfect tool for working on a brief. It makes it really easy for anyone to jump in, leave comments, or contribute at any time.
Kick off meeting
Once you have your brief in a good place, and you know what problem your trying to solve, then it’s a good time to meet with your team and kick things off. The goal of this meeting should be to determine clear roles for everyone on the team but it’s also a great time to review the brief, discuss timelines, and agree on how you will work as a team.
At Automattic, we do the majority of our calls over Zoom video chat and use a tool called Doodle to help schedule a time that works for everyone. There are times we use Slack Video Conferencing or Google Hangouts but prefer Zoom for groups of people because it has the best quality. For these types of calls, we record the meeting, take notes, and post them in a place where people, that couldn’t make the call, can comment on them at a later date.
Slack
It’s important for distributed teams to have an open line of communication so they can share their progress, stay up to date with what others are doing, and ask questions. I like to use a dedicated project channel on Slack to create a virtual home for the team to collaborate and have discussions.
We value transparency at Automattic so these are usually public channels that anyone at the company can join to keep track of progress, provide feedback, and ask questions. As good as Slack can be for teams to communicate in real time, it can also be tough for folks in different timezones to participate in conversations because things can easily get lost in the back scroll. For that reason, it’s good to consider additional commutation channels that are better at preserving decisions and facilitating asynchronous discussions.
P2
At Automattic, we use an internal network of blogs, called P2, to document decisions and communicate asynchronously. There’s a social element to the blogs so that you can @mention other folks to grab their attention or cross post your message to another blog if you’d like to share something with an entire group of people following that blog. Being able to comment on each other’s posts is where the real magic happens. At first, it can be tricky to know where you post something, or what you post on P2 compared to sharing it in Slack, but over time it starts to feel very natural.
In the context of our projects, we have a dedicated P2 to memorialize decisions made in Slack, share updates across the company, and getting feedback from people outside the project team.
Project board
Having a board where you can see every piece of work that needs to happen is a beautiful thing. When it’s done right, people know exactly what to do and do it. Momentum builds and projects get delivered. This is a habit traditionally practiced by developers but I have found lots of success incorporating the work of other team members, like designers, marketers, and writers, into the board as well.
Our project boards generally follow a common pattern with a Backlog column for new tasks, an Up Next column for prioritized tasks that should be worked on next, a Doing column for tasks being worked on, a Requires Review column for tasks that require feedback, and lastly a Done column for completed tasks. Up until very recently, our team was using Trello to manage our work but we just made the switch over to Github Projects. Both tools have their ups and downs but the move was ultimately made so we can reduce duplicated efforts with a tool that’s already part of the developers’ workflow.
Now, it would be nice if these boards managed themselves but unfortunately they don’t. In order to keep up our up to date, a group of folks from the team meet weekly to review our progress, groom our backlog, prioritize our work for the next week, and then publish a report to keep our stakeholders up to date. As the week goes on, team members pick up cards on the board, assign themselves to them, do the work, and share their progress when necessary.
Status updates
For status updates we use Geekbot for sending an automated Slack prompt that asks people a series of questions. We started out with infrequent weekly prompts early in the project and then switched to daily prompts as we drew closer to our deadline. We crafted the questions in the prompt so we could learn how people were feeling about the general status of the project, what they had completed since the last update, what they would work on next, and if they had any roadblocks. The updates were helpful for everyone to see what they were all working on and to help each other out when roadblocks popped up.
Feedback
Feedback comes in many forms and is invaluable for baking quality into your product. On the design side, we have regular design critiques where we bring designers and developers, from across the company, together to review work and offer feedback. Work is also posted in multiple formats for people to review and share their thoughts on their own time.
On the development side, we do code reviews to not only make sure we’re writing good code but also to test the work that’s being implement. Both designers and developers participate in the review process so we can work collaboratively to highlight any issues and also overcome any unexpected issues.
Collecting internal feedback is great but can still leave you open to making mistakes. This is why it’s so important to include your customers in your product development cycle. We do this by running usability studies at various stages of our projects. At the beginning, they’re helpful for understanding your customers expectations, problems, and view points. Then as the product evolves, it’s helpful seeing customers using what you created first hand to uncover any problems they’re running into. Usually five to eight sessions are enough to give you what you need.
Retrospectives
Even though there is lots of communication throughout a project, I believe that it’s important to take deliberate time to look back and see how things are going. I say deliberate because there have been so many times where things felt like they were going well until we took the time to dig in and all of a sudden we found all kinds of issues. Those were hard discussions for a number of reasons but we all felt better for having them and improved as a team.
There are a number of retrospective activities out there but we keep going back to the tried and true “Start, Stop, Continue” because it just works. We use Funretro.io as a digital board for people to add their “stickies” on their own time and then we meet as a group to discuss what everyone added. As people read through their stickies, we ask them to group them with similar topics on the board. Lastly, we vote on the topics we would like to cover and then pick the top 3 we want to action on before our next retro.
So how different is it working with a remote team
The majority of things I shared in this post aren’t unique to remote teams. As a matter of fact, I have been working with most of these methods, and tools, longer than I have been working at a remote company. There might be some minor differences in how you do things but at the end of the day, whether you work in an office or with a remote team, the key to any successful project is good communication.