TBM 292: Friction, Documentation, and Product Tools

Note: I wrote such a heavy post yesterday, that I figured I would balance off the week with something lighter and maybe more actionable. This week is a twofer!

My Claim: Many teams should use static, low-tech documents and manual repetition instead of specialized work-tracking tools and goal-setting products.

To make the case, I will draw on bullet journaling, a Lofi analog personal organization developed by Ryder Carroll, particularly the idea of migration. I suggest going down the bullet journaling rabbit hole, but we will focus on migration for this post.)

Migration

One of the cornerstones of bullet journaling is migration. An example of migration is copying incomplete tasks from a daily log to the monthly log for better prioritization in the upcoming month. Here's how Carroll describes the benefits of migration:

It may seem like a lot of effort to have to rewrite all these things, but that's intentional. This process makes you pause and consider each item. If an entry isn't even worth the effort to rewrite it, then it's probably not that important. Get rid of it. The purpose of Migration is to surface what's worth the effort, become aware of our actions, and to separate the signal from the noise.

Task Migration Vs. Procrastination: Do You Know The Difference?

Imagine, for a moment, that you manually (by hand, analog) copy the items in your backlog, in your OKRs, on your roadmap, in an operational plan, or a strategy doc to a new piece of paper at a regular cadence. You would be free to ask questions like, "Does this make any sense?" "Is this how I would phrase this based on what I know now?" and "Is this even worth spending five seconds to copy it over?"

Contrast this with what happens using digital "productivity" or "project management" systems. With digital systems:

1. It is too easy to keep a big list of things.

2. It is too easy to revise/delete the past.

3. It is too easy to copy/paste/move things.

4. It is too easy to make complex mappings.

5. Digital tools often force us into boxes based on their data models and interfaces.

I'm not suggesting you run a 1,000-person company off of dot-ruled notebooks, but there is an important lesson here.

State History

In most "structured" digital systems, we see the current state, not a state history. By its very nature, a bullet journal creates a state history through logging, regular reviews, and migrations. A simple to-do list might look like this:

Note how we canceled Task 4 two days ago, and Task 3 keeps getting migrated.

Another example. Say we were "tracking" the status of a project; we might keep a log of that status every month, along with our current confidence interval for project completion. 

Humans are perpetually optimistic, but at least we can reflect on that.

Once you understand this pattern, you'll start noticing opportunities everywhere. How often do you view status checks alongside historical status checks? Does your team automatically "punt" work into the next sprint without putting those things through a prioritization filter? Do you do backlog grooming here and there, or do you export, delete, and selectively pull things into a new version? Are your estimates any better than throwing darts? Does your "cone of uncertainty" narrow over time, or do new things keep getting in the way?

Think of all these tools that promise effortless syncing, connecting everything and anything, "automatic reporting," and easy updating. They sound good on paper—or not on paper—but is that really what we want?

Say/Do Ratio

Which brings me to say/do.

There's a good chance you are familiar with the idea of the say/do ratio. Quick googling led me to this quote in Inc. Magazine: "In a perfect world, your say/do ratio is 1:1, meaning you have done everything that you said you would do."

I beg to differ. In the perfect world, we'd always do the things that have the best chance of eliciting the outcomes we value—not what we said we would do at some contrived annual planning meeting six months ago.

The problem with most business settings (and with most tools) is that it is exceedingly easy to:

• say you will do something

• change your mind

• rationalize doing something else (for good and not-so-good reasons)

Say/do is meaningless without state history and a mechanism to reflect (migrate). Teams should endeavor to improve their Say→Try→Did—>UNDERSTOOD ratio. Do we understand why things changed? Do we understand why what we tried and ended up doing doesn't exactly match? Many organizations obsess about and complain about the say/do ratio but do very little to reflect on what is behind any variances.

Take this real-world example: A team presents its 2024 roadmap. If you count the number of effort end-points, you get 16 things finished in the year. But what if this team has a track record of finishing one thing each quarter? What if in 2023, they also estimated they would get sixteen things done, but ended up getting four or five things done? 

Maybe that is normal in the company—people are encouraged to set stretch goals and be ambitious. But perhaps it isn't! Maybe this team needs help. Maybe they felt compelled to do shadow work. Possibly, they have trouble pushing back. Perhaps the power dynamic is all off, and a senior executive continuously seagulls their roadmap. Who knows?

If all we can see is a 2024 roadmap with 16 "finishes," and only ever see the current state, none of these questions will be accessible or up for discussion.

Information Asymmetries

A state history also helps us understand one of the key challenges in most organizations—information asymmetries. Imagine we could see a state history of a CEO and Team:

The CEO starts thinking about AI as the team finds its stride in February/March. The CEO may not be seeing the early enterprise wins (or maybe they aren't wins in the grand scheme). The CEO considers some early sales figures, and AI is a bug in her ear. The team is full-speed ahead—eager for the first enterprise CAB. And now the CEO has AI myopia. Frustration mounts!

This evergreen problem is made worse by using tools and processes that hinder migration. My “god view” above may be overly optimistic, but say something like it existed…could the team avoid the whiplash?

So, I end with the claim that using simple/static documents and keeping a "running snapshot" of the state is likely better than fancy products that promise syncing, auto-magic updates, etc. The friction is a feature—not a bug.

We want forcing functions:

A forcing function is an aspect of a design that prevents the user from taking an action without consciously considering information relevant to that action. It forces conscious attention upon something ("bringing to conciousness") and thus deliberately disrupts the efficient or automatised performance of a task. (source)

Use migration to inspire thoughtfulness and integrate new information.

Before spinning up complex tools, ask whether using Google Docs or Google Slides (or a wall if feasible) would do the trick. Document, duplicate, migrate, and learn. Only after those systems break, consider more specialized tools.