Let's talk about production backlogs, how they happen, and how to prevent them.

Most pipelines start off as "push" systems: When a station or worker completes their part of a job, they "push" the work onto the backlog of the next stage.

1/?
We call the time it takes for a job to make it from initiation to conclusion the "Turnaround Time" (TAT). Assuming that everybody processes their backlog FIFO, TAT is the sum of the time it takes to do the work -PLUS- all that time spent in backlogs.

2/?
A bit of Work in Progress (WIP) is a good thing.

Starting up and tearing down workstations (even virtual ones) incurs a mobilization / demobilization cost. Also, unless you can really truly scale to zero, it's wasteful to let most of your pipeline sit idle.

3/?
Unfortunately, real pipelines always have a bottleneck - a rate limiting step that can't keep up with the others.

That's where the backlog will grow without bound unless you act prevent it.

The early symptom is that everybody is working hard, but TAT keeps creeping up.

4/?
What usually happens at this point is yelling (always the yelling) and micromanagement as people start expediting certain jobs.

This is worse, because now TAT is completely inconsistent and there are likely jobs in your WIP that will literally never finish.

5/?
Another pathology of simplistic "push" systems is that upstream errors are allowed to create extra work for downstream workers.

Unless you are super careful, you wind up putting effort on downstream error handling rather preventing the errors at the source.

6/?
The cure for most of this is to switch from "pushing" work into the next INBOX and move to "pulling" work from the prior OUTBOX.

This is a concept in both kanban and agile management.

7/?
One important thing, both in life and in pipeline management, is the concept of "enough."

Each station needs a threshold where they know they've done enough and can go work tech debt or support whoever is in the weeds.

TATs are consistent and backlogs never accumulate.

8/?
Problems back up at the station that's causing them. This (a) frees up those people to fix their own station and (b) rapidly clears the line so other people can come help too.

9/?
These are general principles. They apply to laboratory workflows, to computational workflows, and (most important) to knowledge work.

Go read Sheila Dodge's paper from 2018, "Pull for Knowledge Work." It's great.

https://dspace.mit.edu/bitstream/handle/1721.1/115364/Repenning_Pull%20for%20Knowledge%20Work_Full.pdf?sequence=1&isAllowed=y

10/?
Most organizations have a massive hidden backlog in people's INBOXes, to-do lists, and "do not erase" corners on whiteboards.

Most are stuck at "random TAT, work on whatever the bosses are yelling about, and why do -I- get stuck fixing my upstream colleague's errors?"

11/?
If you're in a position of management, this is on you to fight. It's entirely natural to wake up, drink coffee, bury your team in a pile of urgent emails, and think you've helped.

Maybe you did, but probably not.

12/?
That's the story.

All pipelines develop backlogs, escalation by yelling is terrible, and you should move from push to pull.

Also, here's a picture of a cat in a basket for reading to the end of the thread.

13/13
You can follow @fdmts.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: