This Is How We Manage Projects on a Fully Remote Team

Lessons learned managing cross-functional projects on a team of 60 people spread across 23 countries

We don’t have full-time project managers at Doist. In fact, up until recent years we didn’t have any kind of formalized project management system. When you’re a team of 20, that can work (more or less). When you’re a team of 90+ working from 33 different countries, things start to fall apart quickly.

We started experimenting with a system we call Doist Objectives — DOs for short — centered on project-based squads (a concept we adapted from Spotify’s product teams). Each squad is a temporary, cross-functional team that works toward a specific goal for one 6-week cycle (a time frame we borrowed from Basecamp).

At the beginning, some squads worked well and delivered on time. Others…well, didn’t. We found that a key factor in a project’s success was having a meticulous squad leader who takes responsibility for coordinating and moving a project forward. The only problem is that none of us have a project management background. To make matters worse, we don’t do well with bureaucratic processes… It’s just not in our team’s DNA.

Since starting to work in squads, we’ve had to ask ourselves what we want project management to look like on our team:

Is it possible to effectively manage a project in a lightweight way without getting bogged down with complicated methodologies and GANTT charts?

How can project management be adapted to a remote team setting where the majority of communication happens asynchronously?

When project management isn’t your whole job, how do you keep it from taking over your whole day?

We don’t have all the answers yet, but here are some of the lessons we’ve learnt so far:

Note
Learn how the best distributed companies manage big projects in our online handbook, Remote Projects 101: The Remote Guide to Project Management! See the strategies that companies like Hotjar, Clearbit, UiPath, and Help Scout use to take ideas for inception to execution.

Assemble your squad

First and foremost you need to get the right mix of skills and input to complete the project. Taking the time to formally assemble your squad has two purposes:

First, it ensures that the teammates who are needed to complete a project are included in the work from the beginning. Nothing slows a squad down like adding people midway. One of my biggest failures in managing a project came from not gathering the appropriate team to complete one of my squads.

We were creating new screens to help people celebrate when they reach Todoist Zero (no more tasks for the day). Since the project was built around illustrations, I assumed that I only needed to work with our illustrator, Yin, from Taiwan. Turns out we also needed a product designer (Portugal) to incorporate the illustrations into the page and developers (from Taiwan, Russia, Austria, Greece) for each platform, who could identify platform-specific constraints in the design phase.

Coordination was chaos. Details were missing. New changes had to be decided upon and communicated to the whole team at the last minute. Developers were crunched for time and had to account for those changes as they went. My oversight at the beginning almost tripled the time needed to complete the project.

Needless to say, I learned that it’s worth the time up front to assemble your whole team and make sure that everyone is kept up-to-date on developments from the start. Make sure to get your teammates’ input on who should be included. (And who shouldn’t be. Nothing slows a project down like too many cooks in the kitchen.)

The second benefit of assembling your whole squad at the very start is to help everyone plan their time, evaluate their workloads, and identify roadblocks early on.

As a squad leader, your number one goal is to create an environment where your team can do their best work without feeling overwhelmed and frustrated. This all starts with ensuring that work expectations are reasonable and your teammates haven’t been assigned to too many squads. Of course, unexpected things will come up; you’ll need to stay alert and help shift work and deadlines when someone’s workload becomes unmanageable. But clarifying who will be involved in which projects from the start will go a long way in heading off stressful bottlenecks.

Your squad members are the most important asset to a project’s success. Who you work with, how you support them, and how well you facilitate communication will make or break your project.

Kicking things off with a spec and a meeting

At Doist we try to communicate asynchronously as much as possible — it’s a requirement for successful collaboration on a remote team where everyone works in different time zones. One exception, however, is kicking off a squad. A full-squad video meeting at the start helps curtail issues before they become full-blown problems. If run well, we’ve found it’s worth the time invested.

Before the kick-off meeting, I draft a spec that covers the squad goal, scope, and timeline, and send it to the team. (Here’s an example spec with some links removed.)

  • A goal identifies what we’re working toward as a squad. For example, “Create a Todoist Zero experience that delights users when they complete all their tasks for the day.” This ensures that we’re all on the same page and allows us to start thinking about how we’ll measure the project’s success.
  • The scope is critical to completing the squad in 6 weeks. Some of the projects include features that could be improved extensively. However, we need to ship something to users before the end of the cycle. To do this, we have to decide the highest priority changes to work on before the design exploration starts. Following the example above, the scope might be “Create and implement 6 different illustration-based Todoist Zero screens on all Todoist platforms”.
  • The timeline is there to help teammates know what they will work on at what point in the 6-week cycle. Project dependencies become apparent when they’re placed on a timeline. For instance, the designer knows that their mock-ups need to be completed by December 5 in order for the developers to have enough time to implement it by December 15. An initial timeline is essential for coordination, but it shouldn’t be a source of stress. The dates will inevitably change as the squad progresses.

Based on input from the team during the meeting, I’ll make any necessary changes before finalizing the document. This way everyone is clear on the problem we’re solving, what success for the project looks like, and what needs to be completed when.

Since our remote team has a natural aversion to meetings, we have a few basic rules to make sure the ones we do have are efficient and productive:

  1. Schedule as few meetings as possible. We don’t have weekly stand-up meetings for squads. However, at the start of a squad I do find a time on everyone’s agenda that can be blocked off over 6 weeks. That way if we need another meeting as we progress, we already have a time slot blocked off to have it. When we don’t need the meeting, we don’t have it.
  2. Have an agenda and stick to it. Sending out an agenda beforehand keeps the meeting focused and allows people to prepare questions and input ahead of time. The agenda should set a clear goal for the outcome of the meeting. For example, “Decide between 3 proposed UX solutions to improve Karma goals and streaks”. As squad leader, it’s my responsibility to keep the meeting on track. If someone starts to go off-topic, I simply say “That’s a great point that we should come back to later, but we need to make X decision now.”
  3. Make meetings short. Focus can get lost very quickly in meetings; having time pressure helps me steer the conversation back to the agenda. I schedule 45-minute meetings, but aim to finish them in 30.
  4. Make attendance optional. I’ve only started experimenting with optional attendance, but I think it will lead to more productive meetings. With the agenda ahead of time, teammates can assess whether their presence is needed or not. Depending on their workload and schedule, they can choose to attend or just catch up on what was decided afterwards on Twist.
  5. Document action items and decisions. Written communication is the lifeblood of a remote team. I always draft a short synopsis of what was decided and post it in a Twist thread with all the relevant teammates notified.

Organizing tasks and communication with a Todoist project and a Twist channel

Unsurprisingly, we use our own tools to manage our squads — we designed and built them in a remote setting for remote collaboration.

Todoist is our go-to tool when it comes to project management. We’ve created a project template that gathers all tasks related to setting up and coordinating a squad over a 6-week cycle. When a new cycle begins, I create a new project for each squad I’m leading and import the template into each one as a starting point.

Based on the initial timeline, I add all project-related tasks to that Todoist project ­along with due dates and assign each one to the responsible team member. I add a link to the squad spec in the project comments so everyone knows where to find it. If there are documents or mock-ups that teammates will need to reference for specific tasks, I attach them in task comments. That way, all the squad members have to do is check their Today or Next 7 Days views to see any upcoming project tasks they need to work on. (Learn more about organizing projects with Todoist.)

While Todoist helps us keep track of specific tasks and deadlines, Twist keeps all of our project-related conversations organized and easily accessible for everyone no matter what time zone they’re in. The biggest challenge in coordinating a project on a remote team is that communication has to happen asynchronously. There are definitely times it would be faster to just walk over to a teammates, ask them a question, and get an answer in a minute. But of course, as a project leader on a remote team, you can’t.

However, asynchronous communication is also one of the biggest assets in managing a project. It allows team members to disconnect to focus on actually shipping their part of the project without worrying that they’ll miss something important. We designed Twist exactly for that kind of asynchronous communication.

At the start of the cycle, I create a new channel for each squad I’m leading and invite everyone who will be involved. I then create threads to discuss each specific aspect of the project.

This way all communication for the project is in a single place. Everyone in the channel can skim the threads, see what topics are being discussed, and find the information they need. However, you can choose which members will actually get notified about a new thread or comment. This reduces noise while ensuring the relevant members know what’s going on.

Like I said before, 95% of our coordination is done online. Meetings are a rarity so it’s important that all tasks, deadlines, decisions, and conversations are clearly documented, organized, and accessible to everyone. With a Todoist project and a Twist channel, team members are usually able to find all the information they need without having to ask for it.

Keeping the project on track and handling common roadblocks

Managing a project is like taking care of a baby — turn your back for a second and it will be crawling straight for the edge of the stairs and sticking its fingers in the nearest socket.

If you’re leading a project, you can’t just assign some tasks and deadlines and let things run themselves. Fortunately, if you have a system for checking in on the project status and keeping everyone on the same page, managing your project doesn’t have to become your full-time job.

Posting a weekly project update

At Doist, we create a dedicated “Squad Snippets” thread in the squad channel where updates can be added week after week. Here’s what we include in each update:

  • What got done that week
  • What’s coming up for next week
  • What’s on schedule/what’s behind and any deadline changes (make sure date changes are reflected in the Todoist project too)
  • Anything that’s blocking the project from moving forward

To prepare the weekly update, I skim the Todoist project and the Twist channel. If the status of a particular piece of the project still isn’t clear, I’ll ask the responsible team member for an update on the relevant thread.

Keeping your project management tasks in Todoist too

While I use the squad project to get a quick overview of everyone else’s tasks, I also keep track of all project management related tasks for myself too. This keeps me from going crazy trying to keep track of all the moving pieces in my head and helps me be more efficient so managing the project doesn’t take over my whole day.

Here are some of the ongoing project management tasks I add for myself in Todoist:

  • Follow up with a team member in 48 hours if I haven’t heard back (with a link to the relevant Twist thread)
  • Respond to a Twist thread later (also with a link to the relevant thread)
  • A recurring task to post the weekly update

I also keep my own Squad Status project in Todoist where I have each of my squads as a task. I use the task comments to note everything that’s left to do to complete the squad. I consult each squad task twice a week and update it with the current status of a project. It helps me to keep myself on track too!

Staying within scope (or even reducing it)

Over the course of a project, some things are likely to take longer than expected. 6-week cycles go fast. We like Basecamp’s philosophy that you should adjust the scope, not the deadline:

“It’s all about looking carefully at a feature and figuring out the true essence. Not what can it be, but what does it need to be?”

Keeping your squad’s original goal plus the final deadline in mind, you need to decide what to take on and what should be left for a later cycle. This often means saying no to really awesome ideas, or leaving out something from the original plan. It can be helpful to keep a running “nice to have” list in Todoist or in the squad spec to come back to if there’s time later or in another cycle.

Making sure decisions get made

Sometimes the solution is obvious and decisions are made quickly. Other times people will disagree on the right course of action and discussions will drag on forever. As a project leader, you may not always be the “decider”, but you are responsible for making sure decisions get made efficiently.

When there’s disagreement, I usually leave some time for debate on the Twist thread. It may be a couple of days or a week depending on the importance of the decision and where we are in the cycle. When I feel further discussion is no longer productive, I’ll post on the thread saying that we’ve discussed enough and empowering the best person to make the decision. For example, if we’re disagreeing on a specific element of design, I’ll ask the project’s design lead to make the final decision. If it’s not obvious who should make the decision, I’ll make it myself while being careful to explain how I decided on that direction.


Project management can sometimes feel like a distraction from actually getting things done, but it’s completely changed the way we work as a remote team. Over the past year, the simple strategies outlined above have increased the amount of new things we’re able to ship and decreased the stress involved in getting there.

We’ll continue experimenting to find better ways of balancing the communication that’s essential for keeping projects on track and the deep focus required to produce work we’re proud of.

If you have any questions about how we work together to get things done at Doist, reach out on Twitter @doist or let us know in the comments below.

Lucile Foroni

Lucile Foroni dreams in cycles and squads from New Zealand by way of Lyon, France.

Bring order to your work and life

Join millions of people who are finally feeling the relief of getting organized.

無料で始める