Maximizing Throughput

One way to frame work is that it involves choosing skills to acquire, questions to answer, tools to use, services to sell. And then completing them.

A lot goes into e.g. building a tool. You need to identify a relevant ontology, generate a plan, stress-test the plan, code each component to spec, adjust the prototype to meet spec, raise problems to supervisors, communicate progress. These steps may not appear alike. Perhaps, you think, coding each component to spec is 90% of the entire task in terms of time/energy/complexity. This very well may be true for some projects.

But for many others you’ll only find that to be the case if you have a skill issue. The flip side of making good architecture decisions, scoping projects, and AI code gen leverage is that the ratio of value delivered to time spent coding is driven to infinity. And if 16 hours of coding is enough to create massive value, then every 16 hour span of coding will get planned and communicated. Tomorrow, Copilot +++ might shrink that down to 4 hours. If it gets further shrunk down to 4 minutes, I am going to assume that coding is not 90% of the task for you.

Each of these steps requires skills (meta rationality, rationality, engineering metis, clear communication) and resources (time, energy, focus, emotional placidity, etc). Because the steps are sequential you become beholden to the theory of constraints. One step will hold up the rest, and any improvements to other steps will worsen process performance until the step is improved.

”Actually, I’m not beholden.” Skill issue. What you’re saying is, each step proceeds with roughly the same amount of friction. No step bogs you down, no skill particularly escapes you. If this is true, great. Now, dump twice the energy and focus into the process. Some steps will get faster by a lot; others, won’t. The pain of moving at lightning speed in 6/8 steps only to be hamstrung by the two that didn’t improve much will eat you alive - and there we go. Back to constraints.

The paradox of maximizing throughput is that few things take you too far too long. Lift one constraint, 2 others appear. There’s no one quantity like focus, energy, or time that is always an accelerant; in fact, dumping these into a tightly constrained process mostly produces frustration and distraction. Hence the only skill that will take you far is your ability to quickly detect a binding constraint, and identify how to lift it.

That’s the game.