Six principles on building an organization fueled by questions, not answers.
A few years ago I was engaged by a company in the weather measurement domain that wanted to triple revenue, from $25M to $75M, in five years. The technical product strategy was sound. The barrier was organizational. During that engagement I came across an interview that changed how I thought about what exponential growth actually requires. Not better strategy. Not more capital. A fundamentally different operating mindset.
The source is a conversation between Elon Musk and Tim Dodd (Everyday Astronaut), recorded September 28, 2019 at SpaceX's Boca Chica facility. I extracted six principles and used them as a framework in my consulting work.
On the WSJ article. Chris shared a recent Wall Street Journal piece covering Musk's formalized five-step algorithm: Question requirements, Delete, Simplify, Accelerate, Automate. That framework is the operating procedure. What follows is the philosophy underneath it. The procedure tells you what to do. The philosophy tells you how to think.
Organizations that move fast share one trait: every person in them feels both permission and obligation to question what exists.
Everyone is a chief engineer. This is extremely important. Everyone must understand how, broadly speaking, all the systems in the vehicle work. Musk to Dodd, ~04:00
Every person in an organization needs a working understanding of the whole operation, not just their piece. Without it, people optimize their corner at the expense of the total outcome. They can't tell the difference between a local improvement and a system-level regression. This is not about making everyone a generalist. It's about making sure no one is so narrow that they cause harm they can't see.
Does your acquisitions team understand how operations absorbs the assets they buy? Does your operations team understand the underwriting assumptions that justified the purchase? Does your field staff understand why corporate made the decision they're now executing? When the answer is no, the gap between those groups is where performance leaks out.
You'll see organizational errors at your interfaces. The point between departments. The product errors reflect the organizational errors. Musk to Dodd, ~04:15
The most expensive mistakes don't happen inside departments. They happen at the handoff between them. Each group develops its own internal logic, and that logic is internally consistent. The problem surfaces when one group's output becomes another group's input and the assumptions don't match. Trace any recurring failure back far enough and you'll find an organizational seam underneath it. Not a people problem. A design problem.
When a resident, a client, or a partner encounters friction, look at the org chart before looking at the individual. Find the seam in their experience and trace it to the boundary between the teams responsible. A delivery gap almost always maps to a coordination gap.
If a design or process is taking too long, the design is wrong and therefore, the design must be modified to accelerate progress. Musk to Dodd, ~04:30
When something takes longer than expected, the instinct is to push harder on the existing approach. More people, more hours, more pressure. Musk's position is the opposite: duration is a signal that the approach itself is flawed. Slipping timelines don't call for more effort. They call for a different design.
When an internal process consistently runs long, whether it's onboarding, reporting, vendor procurement, or capital planning, the reflex is to add steps or headcount. The better reflex is to ask whether the entire workflow is structured wrong. Duration is diagnostic.
The most fundamental error in development is to stick to a design even when it is very complicated, instead of striving to delete parts and processes. Musk to Dodd, ~04:45
Every organization adds layers over time. Approvals, reports, meetings, procedures. Very few subtract. The bias is always toward addition because removing something feels riskier than keeping it. Musk's benchmark: if you don't end up adding back at least 10% of what you cut, you didn't cut enough.
Take any recurring meeting, form, or approval chain and ask: if we removed this entirely, what would actually break? Not what might break. What would. The answer is often nothing. The things that do break reveal where the real value lives.
The point at which you can properly frame the question, the answer is comparatively easy. Musk to Dodd, ~05:00
Most time spent stuck on a problem is time spent answering the wrong question. Musk ties this to a deeper pattern: people are trained to answer the question they're given, not to challenge whether it's the right one. That reflex creates teams that optimize within the wrong boundaries instead of redrawing them.
When a team is stuck, the highest-value move is usually not more resources or time. It's someone asking whether they're solving the right problem.
Instead of getting rid of something or questioning the informed constraints, the one department will design to the constraints of the other department, without calling into question those constraints and saying, 'These constraints are wrong.' You should actually take the approach that the constraints you are given are guaranteed to be some degree wrong. Because the counterpoint would be that they are perfect, and nothing is ever perfect. Musk to Dodd, ~05:10
Every constraint passed between groups carries embedded assumptions. Some are current, some are outdated, some were wrong from the start. The default behavior is to accept them and build around them. Musk's argument is simple: the only reasonable starting position is that every constraint is at least partially wrong, because the alternative, that it's perfect, is never true. The habit of questioning constraints is what prevents an organization from hardening around decisions nobody remembers making.
When someone says "we can't do that because operations requires X" or "compliance says we need Y," the first move is to find the person who set that requirement, by name, and ask whether it still holds. Requirements from smart, experienced people are the most dangerous, because nobody questions them. The best thinking from three years ago may not apply to the organization you're running today.
Source: Everyday Astronaut, "A conversation with Elon Musk about Starship," YouTube, published October 1, 2019. Recorded September 28, 2019 at SpaceX Boca Chica facility. youtube.com/watch?v=cIQ36Kt7UVg
Related: Tim Higgins, "The Playbook That Elon Musk Relies On to Make His Wild Ideas Work," The Wall Street Journal, March 2026.
Authored by Alec Maguire. Principles originally extracted during an Outermarker Solutions engagement; adapted for internal discussion.