Ladders and Levels

Frequently in my thinking about thinking, my philosophizing about processes, my personal projects and my daily work, I find myself using ladders and levels as models.

In prior articles (Black Swan Hunting), I've talked about the ladder of automation. At the bottom of this ladder is a process that is 100% human powered and has no assistance from any sort of technology (whether that be infrastructure, physical tools, mental tools/ frameworks, or even processes). At the top of the ladder is a fully automated process that no longer requires human input or energy to run.

What models like this hide is the complexity of the levels that you're navigating using the ladder. The ladder acts as a means of traveling from one level to another. If you want to immediately multiply human ability at the bottom level, add handles (more on those in another article). If you want to make building something more approachable, step down from the top ladder by adding in more human intervention (for example, instead of leaning entirely on LLMs or machine learning algorithms, neural nets, etc).

Understanding Levels

Levels, as abstractions, are actually much murkier than ladders make them out to be because levels contain all of the complexity that is stripped away by a ladder. Here's a brief example.

Every system that you have, however rudimentary or developed, has conditions that must be met. For example, moving from a paper-based system to an Enterprise Resource Platform (like, say, Peoplesoft) involves new inputs and outputs, which themselves may require new skills and capacities (the ability to use Excel, for example). Therefore, swapping out any process in an environment will typically have ripple effects that alter the total landscape of the environment. The entire environment isn't going up a step in the ladder, only this component and the components that feed into it or are fed by it. What you end up with is a machine with parts from different eras of technological advancement, like a Flintstone's car with an electric engine.

Anyone who has spent time in any corporate environment should be intimately familiar with this truth. Some offices still use paper. Some offices have no human that you can contact (by design). Maybe the entire process for a departmental purchase is automated until the last step which requires the CFO to physically take the company card out of his pocket and manually type the information into an order form.

Building Ladders

In order to build a ladder, there's only one requirement. You need to know a path through the levels. Notice that in my use of the automation ladder, I do not talk about the second and third order effects. It ceases to be a concise model and satisfy the purpose I created it for if you get too far into the details. It starts becoming a system (which also has its place). A ladder should be simple, easy to remember, easy to use. It's a thinking tool that helps you navigate uncertainty. Perhaps another example will help.

In the food service industry, there is a ladder for food quality. A burger is typically considered low quality by comparison to say, foie gras, caviar, or high end steak. These positions are not static though. They are dynamic. Every burger aficionado (like me) knows that there's a difference between a McDonald's burger, a Bareburger burger and a burger from Emily's ($20+, really good stuff). In other words, there's an implicit ladder there. People refer to this casually as "elevating" a burger to fine dining.

The only requirement for someone to build this ladder was an understanding of what made something fine dining, rather than fast food, and how to take a dish at one level and move it to another. Realistically speaking, the "how" portion of this formula should be understood as being directly implied by the comprehensiveness of the knowledge. That is to say that if you know your way around a subject well enough, "how" is obvious.

There are 3 discrete steps to building ladders:

1. Identify clusters - these are categories. The same way I can identify a hot dog, a hamburger, french fries, etc as "fast food" and foie gras, caviar, tartare, dry aged steak as "fine dining". Anyone with a reasonable amount of exposure is aware of the different categories that exist. Just name them. it makes things easier (more on the power of naming things in the next article). The reason I call them clusters is because you should avoid trying to name every single thing in a domain. Only name the areas where a lot of different examples cluster. For example, I've had truffle fries at a sports bar. Is it fast food or not? Who cares? The point is identifying the category "fast food".
2. Identify attributes - what makes the things in each category what they are? What defines "fast food"? What is the essence of "automation"? How do you know that something belongs to this category? You need a small collection of attributes that make this thing unique by comparison to other categories. So, for example, the essence of automation is reduction in human involvement (per instance, not up front)
3. Find paths between categories - once you have the attributes, you have a set of switches that you can adjust to change something from a member of one category to a member of another. To clarify, these are dimmer switches, not on/off switches. Building the ladder is really about charting the effects of adjusting these switches.

Returning to my example of the automation ladder, the switches I identified were human resources (time, energy, attention, willpower) and human input (data, understanding, cognitive processes, etc). I can actually build 2 ladders, one for each switch or dial but, in terms of my philosophy of process improvement, I do not think there is a good reason to save time and energy but not to save on cognitive processing, or vice versa, so I aggregate them.

Keep your eyes peeled for my article on the power of naming.