Pull work, don't push it

The Overlap #36

The Overlap is a newsletter somewhere between product development and organizational development. It comes out every other Wednesday.

I’ll be taking a break for Thanksgiving. The next edition (and last one of the year!) will come out on December 15th.

Source

Kanban is about maximizing flow and focus.

We can boil kanban down to three simple practices:

1. Visualize your work

2. Pull work (don’t push it)

3. Limit work in progress

Many teams do 1). Tools like Trello, Asana, and Notion make it easy.

Few do 2) and 3).

Today, we’ll talk about 2) — pulling work over pushing it.

Pull work (don’t push it)

Most teams push work. Pushing work prevents your team from managing themselves. Your team becomes dependent on you (or whoever is pushing work) to get work done.

Pulling work enables self-management. Pulling work makes your team not dependent on you. Pulling work encourages your team to get work done.

Let’s say you’re a product manager working with three developers: Ourelia, John, and Nancy. This is what your kanban board currently looks like.

Most product managers will notice two things:

• Nothing is under the Done column

• There’s still a lot under To Do

“Nothing is done! And we still have a lot to do! Let’s assign Ourelia and John more work!”

“Ah, that’s better.”

The problem? Ourelia and John now have to switch between tasks, disrupting their flow. This might lead them to take longer to complete the work.

And technically, they aren’t “Doing” their new Task — they’re still working on another Task!

The product manager just wants to see more tasks under Doing. This reassures them that they’re “making progress.”

But as a smart product manager, you decide not to do this.

Instead, you encourage your team to pull work when they can take on a new Task.

When John and Ourelia complete their Task under Doing, they pull a Task under To Do:

This is a big difference from pushing work onto John and Ourelia. They both manage their own workload. They aren’t dependent on you to get work done. They feel trusted.

Requirements for a healthy pull-based workflow

To bring a pull-based workflow to your team, you’ll need to make sure of a few things.

1. Tasks need to be clearly articulated. Any team member should read the Task card and have no questions about the task because the info is all there. Avoid writing vague tasks! Templates help. They’ll save you from having to answer a ton of questions later.

2. A shared definition of what To Do, Doing, and Done is. Get clear with your team on what each column means. I like To Do as tasks that we haven’t started, Doing as tasks that have been worked on, and Done as tasks we completed. Doing ≠ tasks that people plan on doing, Doing means tasks that have evidence that they’ve been worked on. These definitions may not make sense for your team. Find what does.

3. A shared definition of what adding your face to a card means. A good default: face on a card means that this Task is being worked on by that person. I generally avoid multiple faces on one card because it often blurs who is doing what on that task. Tasks are collaborative by default, but it helps to have one steward accountable for moving that work forward. That steward can pull others to help them as needed.

4. Consent from the team to self-manage! Let your team know that you don’t intend on pushing work onto them. Invite them to pull tasks from the To Do list into Doing when they have capacity.

“I could never see this working for juniors”

Yes, this type of workflow will challenge folks who haven’t worked in this way. But teach them. Your job as a product manager is to foster a self-managing team, and that means taking the time to coach!

Say a junior team member finishes a Task and doesn’t know what to work on next. Ask them: “Which of these tasks feels achievable to you? What kinds of tasks do you eventually want to be able to do on your own?” Come into that conversation with some idea of what they can work on, but help them direct themselves towards a task they can work on.

Pulling work is a practice, not dogma

Consider pulling work as a practice, rather than dogma. Practices are aimed towards principles. In this case, our principles are self-management, autonomy, and flow. When the practice no longer gives us the principles we want, we change the practice.

Pulling work enables self-management, autonomy, and flow. If it inhibits self-management, autonomy, and flow, then that might be an opportunity to change the practice so that it enables those things.

Again, kanban boils down to three simple practices:

1. Visualize your work

2. Pull work (don’t push it)

3. Limit work in progress

This essay was all about 2). In our next edition of The Overlap, we’ll talk about 3): limiting work in progress.

See you in two weeks,
–tim