The Algorithm, Part 2

Last week, I posted about Elon Musk’s The Algorithm. I love its five steps, but I had to deal with some dissonance when I compared The Algorithm with my own Method R. Why, for example, is “question every requirement” the very first thing in Elon’s algorithm, but it’s not mentioned in my How to Make Things Faster book until page 93?

Well, I’ve figured it out.

The issue is context.


My Method R context is that I’m stepping fresh off an airplane to help a customer solve a problem—or maybe a bunch of problems, like in the Forty-Nine Grievances chapter of How to Make Things Faster. The first thing you have to do in this kind of a situation is to make sure that you’re looking at the right problem. By “right problem,” I mean the problem that’s the most important to the business.

I mention that explicitly because—guess what—I’ve seen a lot of people screw that step up, and when you start off by looking at the wrong problem, you’re doomed.

Elon’s starting point for The Algorithm is later than that. In his context, he already knows what the business’s most important problem is. Elon may not even be aware that identifying the next problem to go work on is actually the result of a process that itself might deserve scrutiny one day.

So the first thing I have to do when I engage a customer: make sure we’re looking at the right problem. The second thing I have to do: make sure we’re measuring properly.

The measurement problem is not just something I made up. It’s a central theme of The Goal, where Eli Goldratt illustrates the treachery of cost accounting.

People who measure wrong usually fail at solving important problems. Bad measurement practices are incapable of supporting clear, strong decisions that are necessary to create momentum behind an idea.

To recap:

  • If you’re not looking at the right problem, you’re doomed.
  • If you’re not measuring the right way, you’re doomed.

Both of these things have to be right, before you can execute step 1 of The Algorithm.


Let’s look at an example.

Imagine that there are 49 problems that need solving. One problem, let’s call it P1, is the result of a dumb requirement that can probably be deleted. Another problem, P2, is the result of a process whose cycle time you can speed up.

So, which problem should you work on first?

Let me remind you of Elon’s The Algorithm:

  1. Question every requirement.
  2. Delete any part or process you can.
  3. Simplify and optimize.
  4. Accelerate cycle time.
  5. Automate.

And on each step, he carefully says to make sure you don’t begin this step until you’ve completed all the prior ones.

So then the answer is obvious, right? The Algorithm says you should always do step 1 first, which implies that you should work on problem P1 first.

But P1 is not necessarily the right answer.

What if problem P2 is critical to the business, as in you’ll go out of business this Friday if you don’t solve it right now; and P1 is nowhere near life-or-death?

Then you’d better work on P2 first. The rule that covers it is this:

You should always work on the business’s top-priority symptom first.

How to Make Things Faster, page 39

So this is the context where How to Make Things Faster begins. I want to make sure that people are using the “most important problem first, no matter what, even if it’s hard” algorithm, which is Method R. Not the “easiest remedy to implement first” algorithm, which is the approach taken by most of the people I meet.

Making these points clear to the reader takes some time, which is why the technique of deleting dumb requirements doesn’t appear in my book until page 93. There’s just a lot to cover before we can get where we’re deleting requirements.

Deleting Dumb Requirements

Now, deleting dumb requirements is definitely a thing on its own, but you might find it fun to realize that deleting dumb requirements is just a special case of a more general thing, a technique called filter early. Filter early is an optimization pattern wherein you get rid of unnecessary “stuff” (information, processes, parts, …) as early in an operational process as possible.

It works like this.

Imagine that you’re called by a database administrator (DBA) team to fix the performance of a program. They tell you that this program is slow because it spends 90% of its time executing a million disk read calls. There are only two ways to make such a program appreciably faster:

  1. Make the million read calls execute more quickly.
  2. Change something so that the program doesn’t require all million calls.

The second way there is almost always better than the first one, because the fastest call is no call.

But you’re not going to be able to make this second thing happen by focusing your attention on the disk drive. It’s just doing the job it has been commanded to do. The way to make the program not need to make the million calls is to change something about the caller of the disk drive—maybe a system parameter, maybe a database index, maybe the source code for the program itself, maybe something else.

Once your context is shifted to the question of “Why does this program require a million read calls?” other questions come into play, like “Why does this program run once a minute? The data changes only once per day?” …Things like that. Once those questions are on the table, you can bring even more aggressive questions into play: “Why does this program run at all? The data it reports is available real-time in a simple online form?”

When you reach the point where you’re debating the very existence of a program, you’re questioning its requirement. Questioning a requirement is the endpoint in a natural progression of asking questions that reach further away from the implementation technology (the disks, the parameters, the code, …) and closer toward the business.

But Politics

So then, why is “question every requirement” not always the first step in the progression of question-asking that might ultimately result in deleting a dumb requirement?

Well, let’s play this out. Here’s the kind of thing that happens in reality:

  1. You’re assigned to figure out why some program is so slow.
  2. You’re introduced to a database administrator (DBA) who will help you.
  3. You ask the question, “Why is someone running this program in the first place?”
  4. The DBA answers something to the effect, “I have no idea; it’s above my pay grade.” Maybe even, “I don’t even work for this company; I’m just a contractor.”
  5. The person in the IT department who suggested hiring you asks, “Look, I thought you were supposed to be good. Can you help us with our disk problem, or not?”

You see the problem?

When you own the place, yes, “question every requirement” is absolutely the right first step.

But you can’t necessarily start questioning requirements if you’re plugged into the wrong level. You have to be able to communicate with the level of the people you have access to. You may have to earn access to people higher up in the organization before you can ask questions about requirements.

Earning access to the right people is a separate skill that’s not the same as the technical skills that make you good at optimizing stuff. That skill begins, as I wrote in last week’s article, with being curious and connecting with the people that you’re serving. The 25-page section on politics in my How to Make Things Faster describes lots of other ideas.





One response to “The Algorithm, Part 2”

  1. Chetan Avatar

    I just stumbled upon this blog post via Twitter. Its fascinating stuff. I just ordered your book ‘How to Make Things Faster’, looking forward to learning more.

Leave a Reply

Your email address will not be published. Required fields are marked *