Hedgehog in the Fog

How To Divide and Schedule Work When Building Something New

People suck at predicting the future unless it closely resembles their past experience. Even worse, people systematically overestimate their predictive ability.

“I know that and take it into account,” you may say. Science shows that even if you are aware of the bias, you are still over-confident of your ability to predict the future. There is a entire article on Wikipedia on the topic: Overconfidence Effect.

If you work on a team that is creating something new, something that did not exist before, this is bad news. It means that you will consistently work on the wrong things while thinking they are the right things.

Good teams employ processes that minimize the extent of this problem. These teams force people to frequently check their work against reality and course-correct. This article offers a couple of suggestions for how to divide and schedule work in order to maximize the amount of feedback.

Dividing Work: Specialization vs Output

Specialization leads to increased efficiency. This idea is so powerful that we intuitively divide projects into tasks by type of work. For example, an analytics project might look like this:

1. Create a database
2. Collect data
3. Build dashboards
4. Train users

This is an effective plan, but only if you know exactly what the end result should look like. In reality, you never know, even if you think you know. People suck at predicting the future.

A better list of tasks may look like this:

1. Build the first chart and show it to users.
2. Build the second chart and show it to users.
3. Build the third chart and show it to users.

The project will take longer this way. More time will be spent on communication. People will have to work on things they are not the best at.

But in exchange, you will get faster feedback. As soon as you have the first chart ready, you can show it to the end users and evaluate the solution. You will learn what you did right and what you did wrong. Then, you can adjust your project plan. You will get better outcomes faster.

Dividing work like this forces people to think about the end result. Instead of seeing the outcome of the work as “data in the database,” a person sees it as “a chart that helps with decision-making.” This places the work into the right context and makes it easier to spot bad plans.

To apply this principle to your team, develop a rule: every completed task must be demonstrated to end users. If this is impossible, use the best available proxy for the end user: a Product Owner or a similar role. If your project has a task that cannot be demonstrated, you should revise it.

Planning Work: Individual Capacity vs Project Capacity

What one programmer can do in one month, two programmers can do in two months
— Frederick P. Brooks

The more people you add to a project, the less effective each of them is. Unless you take into account the value you gain from faster iterations. This is not intuitive and is hard to measure, so people tend to ignore it.

When building something new, you need to get feedback as quickly as possible. This means you should implement projects as quickly as possible. Therefore, you should add as many people as you can to the most important projects. The more time project spends in implementation, the more the environment changes, and the more you go in the wrong direction.

When scheduling work, most teams look at the list of people available and decide who has enough capacity to work on a project. The limit we apply is the ability of the individual to handle multiple projects. This is scheduling based on individual capacity.

To minimize the waste of time, you should invert the question. Look at the list of projects ordered by importance and ask “How many more people can we add to the most important project?” Do not allow anybody to work on the second most important project if they can work on the first.

The effects of switching to planning by project capacity include:

• The amount of tasks that get done will go down. This is a tradeoff.
• The frequency with which you receive feedback will go up.
• Knowledge will be shared among the team better.
• The quality of the outcomes will go up.
• The bus factor will go up.

In the process of dividing and scheduling work, you make tradeoffs between efficiency and learning. You should choose learning more often than you feel comfortable. Remember that you are right less often than you think. Build systems that prevent you from becoming a victim of this bias.