Doist Objectives: Our System for Managing Work on a Fully Remote Team

When I joined Doist in 2016, we were a fully remote company of 40 people building and supporting two products. All without any kind of formal project management system.

If you had an idea you wanted to work on, you could find developers and designers motivated to work on it with you, put a team together, and get started. There was no clear process for turning an idea into a project, getting all of the resources necessary to see it through, and no timeline for executing it. For example, on my first project — revamping Todoist Onboarding — I worked with Pedro Santos, one of our Android developers, and Panos, one of our product designers. It took six months to ship anything that our users would benefit from.

The freedom to execute the project the way we wanted was exciting, and it worked when the team was relatively small. But as the company grew it was clear that this ad hoc, grassroots approach to project management wasn’t sustainable. Projects would start without any clear understanding of what was expected, how long it should take, what resources were required, or if those resources would be available for implementation down the road. Launching new features was particularly difficult as it required developers for each platform — iOS, Android, Web, and desktop. When projects conflicted with one another, no one knew what work should be prioritized. Projects sometimes dragged on for months or stalled out entirely.

As a company, we’re naturally suspicious of process and bureaucracy. We try to prioritize individual autonomy as much as possible. But we needed a more organized way to build a roadmap everyone could get behind and ensure adequate resources to execute that roadmap from start to finish.

After a brief (failed) flirtation with OKRs, we decided to take elements that resonated with us from several other companies and systems — Basecamp, Spotify, OKRs, agile — and adapt them into the way that we wanted to operate as a company. In 2017, the Doist Objectives (DO) System was born.

The principles behind the DO system

The aim of the DO System is to efficiently ship high-quality work while preserving our teammates’ motivation and well-being. It is both a reflection and an application of our values:

• Independence: How do we align the company around the same high-level priorities while at the same time giving individuals as much autonomy over their work as possible?
• Communication: How do we ensure timely, clear communication around work without getting in the way of the work actually getting done?
• Mastery: How do we make room in our system for individuals’ learning and growth in their craft? How do we ensure that process doesn’t get in the way of deep, focused work?
• Ambition & Balance: How do we create a system that allows us to ship high-quality work efficiently and hold each other accountable to deadlines without leading to unnecessary stress and burnout?
• Impact: How do we build a system that aligns what people are working on with what will have the greatest impact on our North Star metrics?

With the DO System, we have found a system that allows us to grow and thrive as a company while reflecting and reinforcing our values.

How DOs work

Each DO represents a clearly defined project we work on in a DO cycle. DO cycles are each four weeks long.

A bigger project might require up to three DO cycles before shipping something to users, though each cycle has a defined scope of what will be achieved in order to track progress and stay accountable to a timeline.

Each DO has a squad that includes all of the team members necessary to complete the DO from start to finish without other inter-dependencies. For example, the Todoist Boards DO squad included a product designer, an Android developer, an iOS developer and a Frontend developer. They didn’t need any external resources to build Boards.

For all new features, a support specialist and product marketer are also added to the DO to provide feedback, support beta testing, communicate product changes to their teams, and communicate those changes with our users when we’re ready to launch.

Each DO has a Squad Leader who serves as project manager, ensuring that the DO stays on track, that decisions are made efficiently, and that roadblocks and delays are communicated to the wider team so adjustments can be made. Anyone can be a Squad Leader.

Each DO has a dedicated Twist channel for all conversations relevant to the DO and a Todoist project to keep track of specific tasks, assignees, and deadlines. Squad Leaders check in with the DO Coordinator at the midway point and at the end of the DO cycles — a simple “yes” we’re on track or “no” we’re not for XYZ reason. Other than that, squads are generally free to manage their work however they see fit. Squad members may ask for input and feedback from teammates outside of the squad, but they have ultimate decision-making power over their work.

Different types of DOs for different types of work

Over time, we’ve found that different types of work require different types of DOs:

Agile DOs

When a DO requires building a new feature entirely from scratch, we’ve started experimenting with what we call Agile DOs. Instead of starting with a clearly defined spec and scope of work for each cycle, these agile squads start with a much more general goal and set of requirements from the product team. They then have a time budget of a certain number of DO cycles to decide on a solution and ship something to users. The exact number varies depending on the size of the project.

This way of working gives squads greater independence and autonomy over their work, letting Doisters build something from (almost) scratch with minimum guidelines and requirements. Not only can squads execute more quickly, it’s also just more fun to be a part of solving the problem rather than simply implementing a predetermined solution. We used agile DOs to ship Upcoming View and Boards last year and the results were tremendous in both the speed and quality of execution.

Improvement DOs

When shipping under time constraints, squads have to make hard decisions about what to include in the first version and what can be left out for a later version after we’ve been able to get real-world feedback.

After big feature launches, like Boards, we tentatively plan for an improvement DO ~three months after launch when we can see how our assumptions held up, identify patterns in user feedback, and tweak the design or add new functionality accordingly. It helps the initial DO squads make difficult tradeoffs knowing that they will have a chance to come back for a second version.

Bundle DOs

We occasionally schedule Bundle DOs that include several smaller improvements that take a few days each to implement. Bundle DOs give us a chance to focus on polishing features that already exist rather than building new things from scratch.

Exploratory DOs

For big, open-ended projects where the desired outcome is unclear — for example, redesigning Twist — we might schedule an Exploratory DO with a cycle dedicated to exploring all of the possibilities, weighing pros and cons, and deciding on a direction that can then be split up and scoped into future DOs to refine and implement the design.

Internal DOs

The DO system was originally created to make sure each cross-functional project had the resources across teams to complete the work. However, we realized that a lot of work at Doist happens internally on a team, often by just one individual. That internal work needed to be made visible in order to properly assess available resources and ensure that we work transparently across the company. We now include Internal DOs in DO planning.

Personal DOs

Each Doister is also encouraged to undertake one Personal DO each year. They work with their manager to define a personal side project they want to take on, what they want to learn from the project, and the impact that learning will have on the company. While they may have other ongoing work during that time, they aren’t added to any other DOs. Personal DOs are a way to put our Mastery value into practice, helping people dedicate uninterrupted time to explore their interests and prioritize their personal growth in their field.

How an idea becomes a DO

The design, development, and marketing Team Heads build out and maintain their own roadmaps of projects they want to accomplish in consultation with their teams. For those projects to be executed on, they need to be turned into DOs with a scope and a spec.

The scope defines what the DO will accomplish within a given timeline and the resources required to do it. It’s tied to a specific DO and DO cycle.

A spec is a more detailed outline of the problem and proposed solution where the squad will document its work, solutions explored, decisions made, and potential future improvements. The scope is tied to a specific DO/DO cycle while a spec is a living document within our company handbook that can be revisited and updated as needed in future cycles.

Sometimes the work to be done is clear and turning it into a DO is fairly straightforward. Sometimes an exploratory DO is scheduled in order to accurately scope the work to be done.

The product team (a cross-functional team with members from design, development, and growth) meets each month to decide which product DOs will be prioritized and consults with all team heads to set timelines based on the resources available. DO planning isn’t an exact science and how we decide on our roadmaps could be its own article. For product DOs, we prioritize projects that fit within high-level themes we’ve set for ourselves (e.g., “Todoist Next”, “Todoist Foundations”, “Todoist Teams”, “New Twist” etc). These themes stretch from a quarter to a year in length and act as our North Star, aligning each team and DO with our bigger vision for our products.

Lessons learned and changes made

At the beginning of the DO System, we encountered a lot of bumps in the road. A large percentage of DOs became “rollovers” as initial deadlines were missed and one or more new cycles had to be added to finish the work.

There was a general lack of availability, commitment, and accountability as well as a lack of timely and effective communication around project statuses. We suffered from prioritization of different projects clashing together, DO ideas being poorly defined when they were turned into DOs or spanning unreasonable lengths of time. There was also a lack of focus on polish, platform-specific features, learning through side projects, and other important work that didn’t fit well within the DO system.

As a consequence, people were stressed out. We’ve made several key changes over the years to make the DO system work for our team:

Shortened DO cycles from six weeks to four weeks for greater focus

We started out with six-week cycles similar to Basecamp, but found that four-week cycles force greater focus on what’s absolutely essential to complete the DO and allow us to be more agile in shipping and improving features.

Squads will always use the full amount of time you give them. The more time a squad has, the more they’ll try to improve the feature. That isn’t necessarily a bad thing, but we prefer for squads to get something out in beta and in front of users early and often to test assumptions and refine solutions based on real-world data, rather than perfecting something in isolation without feedback. We always have the option to schedule another cycle if it makes sense product-wise.

No more than one DO per Doister to prevent conflicting priorities

At the start, people often worked on multiple DOs at the same time. It split people’s attention, led to unclear priorities as to which DO should take precedence, and ultimately created unnecessary delays and stress on the team.

We instituted a general policy of no more than one DO per Doister to ensure greater focus, cut down on context switching, and ensure clear priorities. It’s not a rigid policy, but a guideline we follow unless there’s a good reason not to.

No more DO “helpers” to avoid “too many cooks in the kitchen”

We used to assign “helpers” to squads to provide feedback and input, but we found it slowed DOs down and added unnecessary context switching for helpers who would have to stay up-to-date on what was happening with the DO. Now we only include a helper if a specialized task is required — for example, a small change to the backend team — that only takes a couple of days of work.

While the squad can ask for feedback when needed, it’s not a requirement. This increases the independence and autonomy of the squad and keeps DOs from getting bogged down in consensus-based decision-making.

Clear, straightforward communication guidelines to catch issues early

One of the main causes of delayed DOs were communication issues. When things weren’t going to plan, people weren’t communicating what the issues were or adjusting expectations so the team could prepare for a delay. We introduced three simple guidelines that helped improve communication across the board. Squadmates need to:

• Answer a DM or a @mention within 24 hours
• Post weekly snippets to check-in every Monday
• Raise a red flag as soon as they encounter an issue that they know will delay the squad

These felt right as they respected our values and our remote setting — we can’t and don’t want to expect people to be always on and respond to messages right away — but still created a framework for everyone to know where the work stands throughout a DO.

Limiting DOs to 3 cycles or less to prevent project fatigue

We found that after three cycles of working hard on something, project fatigue starts to set in, affecting the squad’s energy, motivation, and mental health. We try to limit even our biggest product changes to three DO cycles though we might add a fourth in order to avoid shipping subpar work.

Design and development working in tandem to prevent unnecessary delays

At the start, we organized DOs in a waterfall fashion with a design cycle, followed by an implementation cycle (or two). This meant that design worked mostly in a silo before handing off to development. When implementation began, we often had to re-work the designs for things the design hadn’t accounted for. We shipped more slowly because development only started working on necessary foundational changes after design was finalized.

Now design and development work hand-in-hand from the start. The squad organizes the timeline such that developers can start working on aspects of the DO that don’t require final mockups while design iterates on mockups, gets feedback, and finalizes the design. For example, in implementing Todoist’s Upcoming View, one of the DO requirements was that users be able to scroll infinitely through due dates on all platforms. While the designer worked on refining the UX and UI design, the developers were already working on changes to ensure that the infinite scroll would be fast and smooth.

Rotating team “heroes” to triage more reactive, non-DO work

The DO system worked to set high-level priorities, but in practice it meant DO work was often prioritized over bug fixes and smaller improvements to our apps. In order to prevent costly context switching and allow people to focus fully on their DOs, we came up with the hero system.

Each DO cycle, one member of each team becomes the “hero”. As our head of frontend development Henning explains it:

“[The Hero’s] main responsibilities are to communicate with the support team, triage bugs, file them in our bug tracker, and fix the most urgent ones. On top of those tasks, the Hero takes care of smaller platform parity improvements, to ensure that our various apps don’t diverge too much, as well as refactorings, to improve the general health of our code base.”

Each DO cycle, we update the Twist Hero groups with whoever has the role for that month. That way the rest of the team can tag the hero group in relevant threads and know that the right person will be notified.

Henning wrote a deeper dive into the heroes and related “housekeeping days”, if you’re interested in learning how we balance the deep work of DOs and more reactive work like bug reports as a team.

Staying flexible to prevent burnout

Even with these improvements, we still have delays, at but they feel more manageable. When a squad leader flags a potential delay, we assess the situation, decide if we need additional time for the squad to finish the work, or if we can deal with the additional work in a separate DO cycle. Sometimes we decide we don’t want to prioritize whatever is causing the delay, and we add it to the roadmap for future improvements.

Estimations are just estimations. It’s not an exact science, and delays are sometimes unavoidable. The difference is that we now have delays of a few days when before we had delays of months.

Our priority has always been to preserve our team’s mental well-being, not to burn ourselves out meeting arbitrary deadlines. For example, when the pandemic hit, we switched to two six-week cycles instead of three four-week ones to give people more breathing room. That flexibility allowed us time to adjust and we still shipped more, higher-quality work in 2020 than we had in previous years.

What’s next for the DO System?

Any process we adopt at Doist is here to serve our people, not the other way around. That means no aspect of the DO system is sacred. If at some point, it no longer serves our team, we’ll gladly get rid of it or change it.

As we keep on scaling the teams and executing on more DOs, we want to automate recurring tasks within the DO system as much as we can. Again, our focus will always be on getting the work done, not managing the work to be done.

We also want to invest in continuous education and support for squad leaders with resources, feedback, retrospectives, etc to help all Doisters improve as leaders.

Ultimately, whatever improvements are made, the aim will always be to build the best environment for our people to build successful products, by giving them more autonomy, independence, and space to be creative and effectively execute on their wildest ideas.

Curious to learn more about how we work? Start here:

• Async-First Communication: A More Inclusive, Productive, & Humane Way to Work by Doist’s Founder & CEO
• How to Build Trust on a Remote Team by Doist’s Head of Marketing
• [Internal Memo] No Kings: How Do You Make Good Decisions Efficiently in a Flat Organization? by Doist’s former Head of Backend Development