The Right Amount of Work

At Doist, our teams are grouped by function. We have an Android team, a Design team, a Marketing team, etc. The way we execute projects is in month-long cycles, each project should ideally be defined in a way that it can be implemented within one month.

Most of our larger projects require deep coordination between teams. When we want to ship the Dark Theme, each platform team participates, as well as design, product, marketing and support. Understanding the concerns and interests of each team ahead of time is key to make sure we build on each other’s strengths, as opposed to blocking each other.

When we implement a feature like the Dark Theme, different teams have very different perspectives on what the feature means. Windows 10 already has a lot of built-in support for theming, making the implementation relatively straightforward. On the other hand, the web has no inherent notion of dark/light theming. This means a lot of up-front engineering work and possible complications. Catching these interests ahead of time is challenging but has the potential to get much more impactful work done without working more hours.

How can we make sure that all teams have a chance to voice their concerns and needs? More importantly, how can we integrate all the sometimes-conflicting interests into one plan?

As a company, we have strong interests to find the right level of ambition each cycle:

• Too little work will reduce our pace of innovation and slowing our overall momentum. It will also trigger some uniquely colorful Reddit comments 😅
• Too much work will cause a decrease in quality of our products
• Too much work can result in a situation where we are 85% done on all projects but can’t ship anything. The emoji we use for this project status is “🙄”, which sums it up well

Getting to Yes, a well-known book about negotiation, offers a few surprisingly applicable ideas for finding a good planning process. The book author’s notion of principled negotiation plays to Doist’s strengths:

• We always want to make sure that the direction we’re heading works for all parts of the organization
• We judge ideas on merit only, position in the company doesn’t play a role
• We try to source feedback from as many parts of the company as possible

Using the idea of principled negotiation, let’s try to imagine how the project selection process could look like.

I. Setting an objective performance baseline

An objective standard for how much work can the team execute per cycle is key. Without a fair standard everyone can agree on, what is fair quickly becomes subjective.

“Let’s execute on this, the barista at Starbucks wrote a heart on my coffee cup in the morning, so I feel very confident it’s doable.”

“That’s way too much! My cup said Jane instead of Jan, so I feel insecure. If there was less work, I could go to the barber and this wouldn’t happen. Let’s be more realistic here.”

To set a fair performance expectation, we need to know how much work teams usually execute per cycle. There are many ways to approach the problem, from tracking how many hours projects take, to T-shirt sizing, to story pointing.

II. Collecting Interests

With the performance baseline established, let’s understand the teams’ needs.

• What are the projects the product team considers the most key?
• Does the team need to work in internal projects to e.g. improve QA?
• Are there any external commitments we’ve made?

A 3rd party will be effective at collecting the needs of everyone in a timely manner. Let’s call this person the coordinator. Gathering the needs during 1:1 sessions could be one way to ensure that nobody feels constrained and shares all their interests.

For project suggestions (needs of e.g. the product team), the coordinator needs to have enough data to understand the size of the project relative to the performance baseline.

III. Creating a Proposal

Once the coordinator collects all the interests, it’s time to seek agreement on what projects should be executed in the next cycle.

The One-Text Procedure seems like a great fit. It’s expressly designed for multi-lateral negotiations. Here’s the basic mechanic:

1. The coordinator creates a rough draft that might satisfy a reasonable number of the concerns
2. The coordinator presents the draft to all teams and asks for critique. Teams cannot edit the draft, they can only provide criticism. That way people focus on advancing their interests instead of offering specific solutions
3. The coordinator collects the criticism and creates the next version of the draft. They again present it for critique. This step repeats a few times (let’s say one draft per day over a week)
4. After a few iterations, the coordinator announces that the draft is the best they can do under current conditions and recommend it for acceptance

When the coordinator presents the final proposal, everyone should have strong incentives to accept.

• The proposal is built with an objective baseline in mind.
• All stakeholders have been a part of the process, so understand the maximum has been done to meet their interests given the constraints.

Wrapping Up

While the proposal above is suggested as a package, implementing individual components can be a boon on its own.

On our Windows team, setting a performance baseline helped us in several ways. First, it enables to see storms brewing on the horizon. When we see that we’ve overcommitted a few weeks ahead, we can decide to de-prioritize some work. This is still painful, but at least we can increase the chance that we’ll deliver on the most critical projects. Second, it enables us to have more objective discussions about our performance as a team and how to improve it.

The same benefits could be reaped at the product level. Understanding ahead of time that we’ve been to optimistic can allow us to turn all resources on the most critical projects to make sure we ship them. It’s not ideal, but it can still be a sizeable win, especially if there are dependencies between projects.