Context: Every Sunday I write a mini-essay about an operating principle of Lightcone Infrastructure that I want to remind my team about. I've been doing this for about 3 months, so we have about 12 mini essays. This is the first in a sequence I will add to daily with slightly polished versions of these essays.

The first principle, and the one that stands before everything else, is to question the requirements.

Here's how Musk describes that principle:

Question every requirement. Each should come with the name of the person who made it. You should never accept a requirement that came from a department, such as legal ... you need to know the name of the real person who made the requirement.
Then, you should question it, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement comes from me [Musk]. Then make the requirements less dumb.

Here's some of how I think about it: plans are made of smaller plans, inside their steps to achieve 'em. And smaller plans have lesser plans, and so ad infinitum.

But it's hard to get your subplans right up front.

There are a bunch of reasons for this: sometimes something looks like it might be easy from 1,000 feet, and a lot gnarlier at 10 feet. Sometimes, one of your subproblems looks like it has a standard solution, but that standard solution is built to solve a bunch of issues you don't care about. The point of questioning the requirement is to de-silo your subplan, and look at a larger scope, and use that to figure out a better plan.

Most work done in most organizations is work that is best done never at all. The core of most solutions turns out to be much more elegant and simple than anyone who worked on the first version of something was able to imagine:

Space X Raptor iterations.jpeg — Evolution of the SpaceX Raptor engines. Source

Why do we have requirements at all? Of course, we have plans and subplans, but those don't constitute "requirements". As will be a recurring theme in these principles, the need for things like the "requirements", and the associated risks, rear their head when a project needs more than one person to be completed, and as such, when tasks need to be split up across many individuals, and often shudder hierarchies of individuals.

The best way I have found to set up a delegee to understand the goal of...

The Lightcone Principles