Just One Man

Things have been hard lately - I won't lie.

There are incredible downward pressures on my primary business. That's forced us to go "back to the drawing board" on multiple levels at once. No obvious answer to our problems exists; innovation is required, and innovation requires time.

This period of instability happened to coincide with a period of experimentation in the rest of my life. That meant more projects, more changes to my schedule, more expectations, more commitments - personal and professional.

In other words: I've been really, really busy, with all the stress to show for it.

It is common in these situations to try and solve the problem by throwing money at it. Hire a nanny, hire a team, "hire" new software that promises an easy fix. But money is tight in tough times, and these are tough times (at least, they are if you work on the internet).

So: what to do?

Fortunately, there's a tool for figuring this out. It's called the Theory of Constraints, and its core insight is both simple and profound. Which is:

In any system, there is only ever one constraint at a time.

By constraint, we mean the element of the system which most limits the output of the system as a whole.

As a result, all attempts to improve the output of a system should focus on the constraint - and only the constraint. Or as Dr. Eli Goldratt, the creator of TOC, once said: "Improvement anywhere other than the constraint is a mirage."

So, if we need to get more done with less....

...we need to identify the constraint, subordinate to the constraint, and then elevate the constraint.

Identifying the constraint is just that - figuring out which part of your system is currently limiting your output.

The constraint could be a particular process (like invoicing clients), or a team member (like your account manager), or even a piece of equipment (like a machine producing a certain part).

If, for example, my team as a whole is capable of onboarding ten new clients a week...

...But I need to be present on their onboarding call, and I can only handle five calls a week...

That means the system as a whole (my business) can only onboard five clients a week.

My schedule - and in particular, the onboarding call - is the constraint.

Once we've identified the constraint, we need to Subordinate the rest of the system to the constraint.

That means "teeing up" the constraint in such a way that maximizes its output.

For example, could I handle more onboarding calls if many of the questions I ask new clients were handled before the call? Sure - that might cut call time in half, meaning I could handle ten calls a week instead of five.

Better yet - do we really need me to be present on the onboarding calls? Could we cut the onboarding calls from the process altogether?

Rather than spending any extra money at this point, subordination is all about making sure we're getting the most out of what we already have.

Finally, we Elevate the constraint. This is where we spend money, time, or other resources expanding the capacity of the constraint.

Note that this is the last stage in Goldratt's process, but it's typically the first thing people do when they want to improve a system. Throwing money at the problem feels good (in the short term, anyway), but unless we've followed the first two steps, that money isn't going to be as impactful as we would like.

Maybe we hire an extra onboarding manager, so now we double our capacity for calls. Or we hire Dan an assistant, taking other tasks off his plate and making more time for strategy calls.

Either way, it's unlikely that, after all that, the onboarding call is still our constraint. Now it's likely that the constraint has moved somewhere else, and we start the whole process over again.

Theory of Constraints sounds simple in theory; it is often much more challenging in practice (do you really know all the individual elements of the system you want to improve? Do you really know the capacity of every one of those elements?). Still, I find it an extremely useful framework whenever I'm feeling crunched for time, money, or both (as happens to be the case right now).

So: what did I do, in real life?

Well, I knew I was the constraint, since I had a ton of tasks and projects (all of which could be extremely valuable) building up in my backlog. Tasks piling up in front of a particular person are a strong indication that person is the constraint. That took care of identification.

The first thing I did was cancel as many commitments as I could. I stopped booking so many podcast interviews. I stopped going to some coaching calls which were helpful but not necessary. I handed off some tasks I was handling to other members of my team. I even blocked Twitter and Instagram on my phone to try and waste less time. All of these are examples of subordinating the rest of the system to the constraint (my time).

Finally, I elevated the constraint by investing resources. I started working some extra hours (early mornings and some weekends). I hired an assistant (the incredible Madeleine) who immediately started tackling several important but time-consuming projects (like moving the business onto cheaper versions of the software we were using). I built out some automations and AI agents to handle rote tasks (like doing research on podcast guests and writing up client reports).

All of this has enabled me to get significantly more done in the same amount of time, which in turn has allowed me to focus on the single most important thing I do: innovation...the single biggest bottleneck of all.

If you're in a similar situation, try running through the Identify, Subordinate, and Elevate process. You might be surprised at what you're capable of.

Yours,

Dan

COOL STUFF I'M READING:

Bayes is not a phase. A really useful introduction to Bayesian reasoning (as well as why some people don't like it). I'm trying to be more Bayesian in my day to day life and enjoyed this one.

Bayes is not a phase

it’s forever but weird to argue about

DYNOMIGHTdynomight