Personal Danban, Part 1: The Iron Laws

Better Questions is supported by readers like you. If you get value from my writing, consider becoming a supporting member. Exclusive content, weekly deep-dives, free beta-access to future courses and more. Thanks.

----

Productivity systems and I have had a checkered past.

I've tried them all: every journal, every planner, every app.

I've tried GTD, the 12 Week Year, the Four Hour Workweek, Bullet Journaling, Zen Habits,  Agile Planning.

If it promised me higher output and less stress, I've tried it.

Time and again, I would spend a few months with the system before abandoning it and moving on to something else.

But then...something changed.

I stumbled onto a personal productivity system that seemed to really work for me.

It was based on a just few simple principles.

In fact, the whole system was SO simple, SO basic, and SO cheap to implement that it made me susipicious.

"Surely this can't really be working, when so many other, more nuanced systems, have failed?

But here we are, several years later...

And I'm still using the system, more or less unchanged.

I call it "Personal Danban."

(Because I am an egomaniac.)

In this email, I'm going to do my best to explain the three basic principles this system is based on.

In next week's email, I'll show you how to build your own version of my system with the materials you have laying around.

You'll be able to start experimenting with the system yourself almost immediately.

Sound good?

Good.

Then let's examine the three underlying principles, otherwise known as:

THE IRON LAWS

(One of the unstated rules of Personal Danban is that everything must be named as dramatically as humanly possible.)

LAW NUMBER ONE: Visualize Your Work

Even if you're not explicitly involved in "knowledge work" the way I am, it's likely that the tasks you are responsible for have become less and less "tangible" in some way.

Projects need to be broken down into component parts. Those component parts inevitably turn out to be more complex than expected. People toss tasks onto your plate in passing, via email, text, and chat. It feels as if you're juggling balls, but half of them are invisible, and you're on a skateboard that's going down hill and one of the wheels is falling off.

Human beings were simply not meant to hold a lot of information in our heads. When we try, we inevitably end up missing appointments, forgetting tasks, and telling our friends that we totally meant to text them back six weeks ago and totally thought we had texted them back but it turns out we hadn't. Sorry!

We KNOW we're not good at keeping these running to-do lists in our head, too. And BECAUSE we know we're not good at it, we experience a low-level hum of background anxiety when we're asked to do it.

Tonianne DeMaria Barry and Jim Benson, in their excellent book Personal Kanban, call this "existential overhead." It's a kind of perpetual worry over did-I-leave-the-oven-on, but about everything.

The fastest and easiest way to get rid of this existential overhead is to visualize your work. Get it out of your head and make it tangible again, storing the data in your environment, rather than in your grey matter.

Doing this allows you to quickly survey all your work at a glance. You don't have to remember what you're doing or what's coming up...you simply have to look at wherever your work is visualized.

There is something strangely calming about this. Some mental muscle in the back of your head just...relaxes.

That, by itself, will make you more productive.

LAW NUMBER TWO: Limit Your Work In Progress

This one is simple:

You may only work on 2-3 tasks at a time.

That's it.

No multi-tasking, no breaking from one task to go quickly work on another.

You can choose whatever 2-3 tasks you want to currently work on, but you may only work on those tasks until they are done, or you switch one of them out for something different.

This is one of the rules that seems much easier to implement than it actually is.

The nature of our modern working environment is that we stop working on, say, an essay for our weekly blog, to quickly check in on Slack, or email, or texts, or Twitter, etc.

Note that it's totally fine to do those things. But if you're doing those things, you have to consciously give up your ability to do something else.

Forcing this kind of deliberate choice makes us far more careful about the types of task we take on and how we plan our time.

When your number of tasks is limited, even in this seemingly arbitrary way, you begin to change how you estimate what you can get done. You become a bit more cautious about taking on new projects, and a bit more realistic about your own capabilities.

As a result, you end up more focused on the types of tasks that really matter.

This, by itself, will make you more productive.

LAW NUMBER THREE: Ignore Local Optima

Eli Goldratt liked to refer to the "illusion of local optima."

This was the idea that, by optimizing every individual element of a system, you would get the highest possible output from that system.

Imagine, for example, a telephone support office.

They have three "elements" of their system:

The ticketing software, where requests for help come in from the company's website;

The support staff, who read the tickets and respond as necessary;

...and the managerial staff, who assist when the support staff are unable to close a ticket.

Let's say that the number we most want to optimize for is closed tickets per hour. That's how this company measures success. Perhaps we're not happy with our current performance. We're averaging only 25 closed tickets per hour with this team, and we think we can do better.

Someone who believes in the illusion of local optima will assume that the way to get the highest possible closed tickets per hour is to get the highest possible output of each of the three elements:

- The highest possible number of tickets from the ticketing software;

- The highest possible number of closed tickets from the support staff; - The highest possible number of assisted tickets from the managerial staff.

While that sounds good on paper, in reality it will likely result in a dramatic decline in performance.

Why? Because different elements of a system function differently, and have different rates of output.

Let's say that by optimizing our website, speeding up the ticketing process, and making the interface more intuitive we were able to increase the number of tickets per hour from the ticketing software to 50.

And let's say that by improving our procedures and speeding up communications, we are able to improve the closed tickets to 40 (a big improvement!)

We've also retrained our management staff who handles the toughest tickets, and they can now manage to close 5 tickets per hour.

What's the result of all our improvements?

Well, in hour 1, our ticketing system opens 50 tickets.

Our support team closes 40.

That leaves 10 tickets for the management team, who is able to close 5.

That means we've got 5 tickets still waiting in the queue. Not bad!

It doesn't stop there, however.

In the next hour, 50 more tickets are opened, 40 are closed, and 5 are assisted; now there are 10 open tasks in the queue, 5 of which are now two hours old. Uh-oh!

The management team gets together and decides they're going to just focus on the oldest tickets, clearing out their queue. They close out 5 of those tickets in the next hour, but of course, in that time the support team has passed on 10 more tickets, so now they've got a backlog of 15.

This continues until the backlog is so unwieldy that management brings a few of the support team members to help them address the backlog. Of course, that lowers the number of tickets support can close per hour, which creates a new backlog to deal with.

Now, by the time the team gets around to some of the older tasks in the queue, the people in question have moved on or left in anger. That means that there's now confusion over which tasks need to be dealt with at all.

Meetings are called. Rules are changed. Solutions are tested...all of which increases the amount of non-critical work the team is responsible for, further lowering their output and increasing their backlog.

We made every individual step better, and everything got worse.

This is what the illusion of local optima is all about.

In reality, there's usually only one thing you should improve about a system at any given time:

The Constraint.

A constraint is simply the thing that most limits the system's output.

In our example above, our problem wasn't how fast our website handled requests for support, or how many tickets the support team closed.

Instead, our problem was managerial staff. THEY were the limited factor, only capable of handling five tickets an hour.

Thus, when we sped everyone else up, all we did was create a massive backlog at the managerial stage.

If we want to improve the system as a whole, we need to find and alleviate the constraint.

Anything else will have either a minor or negative impact on the whole.

To bring this back to Personal Danban, any productivity system we use over the long-term must have a simple and intuitive way of spotting our own constraints.

For each of us, there is some resource - whether it be time, money, a state of mind, access to someone else, etc - that puts a hard limit on what we can achieve.

Maximizing our effectiveness is all about finding those limits and removing them.

That's exactly what Personal Danban does.

Next week:

How it works, and how to build one for yourself.

Yours,

Dan

SOMETHING COOL TO READ:

LinkedIn's Alternative Universe.

Piercing and hilarious.