Former SpaceX and Tesla engineers revealed Elon Musk's real management rules

Two of them—Chandler Lujza, lead engineer for the Starship program, and Turner Caldwell, who oversaw metals and minerals at Tesla and directed the construction of a $1 billion lithium plant—shared what they actually took away from Elon Musk’s companies and how they apply these lessons in their own startups.

A flat structure is not about the absence of managers

The most common myth about SpaceX and Tesla is that their efficiency is explained by a “flat organizational structure.” Lujza corrects this: the point is not the absence of hierarchy, but the speed of information flow.

Any junior engineer should be able to speak directly to any member of the executive team at any time—not through a chain of managers and back. The goal of a flat organization is information flow and collaboration. If it is built incorrectly, without understanding this goal, it results in chaos.

Closely linked to information speed is the second principle: decision velocity, or the speed of decision-making. When leaders with a high degree of confidence make decisions quickly, it relieves a huge burden from junior engineers. A young specialist should not be paralyzed by the prospect of making a million-dollar decision. If a leader comes in, makes a decision, and says “let’s go,” the team moves several times faster. You cannot wait for complete information: often, you can only find out if a decision was correct after you have made it, tried it, and iterated quickly. This is always a gamble. The task is to maximize the percentage of correct bets.

The critical path: how not to turn the team into a game of kick-the-can

For Lujza, the most important operational tool brought from SpaceX is critical path management. The critical path is a task or procurement activity that currently determines the schedule of the entire project: what needs to be done to unblock the next phase or reach the final goal.

Lujza describes working with the critical path as a constant game of “whack-a-mole.” When something becomes the critical path, everyone wants to help—and the whole team rushes at one ball, like second-graders playing soccer. This is a waste of resources. The solution is small SWAT teams that attack critical tasks in parallel, while the rest of the work continues. The idea is to prevent the next problem from becoming a new critical path sooner than necessary.

In practice, Caldwell uses a specific tool: daily summaries in the format of a production shift handover. Each day, the team records three things: what was done, what should have been done, and why the planned work was not completed. Previously, such a report took an hour of manual labor. At Mariana Minerals, they automatically generate drafts from a shared database—people only edit and click “send,” maintaining personal responsibility for the content. Language models help navigate the database if someone doesn’t remember the folder structure.

Lujza adds a separate ritual: written updates via email with high signal and low noise. The owner of a specific task sends frequent updates to the team—not just to inform colleagues, but to allow themselves to see progress. Writing means thinking. Lujza always has a notebook in his pocket.

Aggressive deadlines are not about motivation, but about priorities

“Elon Musk time” is the source of endless memes about unrealistic timelines. But Lujza explains the real mechanics: super-aggressive deadlines are a tool for identifying critical paths, not a motivational poster.

Out of a thousand things that need to be done, 900 can be completed in six months. 100 cannot. This is exactly why you need to attack those 100 things. An aggressive deadline forces the team to think very deliberately about what is actually unimportant and what does not fit within this time horizon. This automatically creates a list of priorities. Moreover, “attacking” can also mean “removing the task entirely.”

At the same time, goals must have a realistic technical path to achievement. If such a path does not exist, the goal demoralizes rather than motivates. Caldwell talks about setting the right rhythm for the company: over the course of an eighteen-month project, you cannot sprint all the time.

You need a drumbeat—a regular cadence that gives people a sense of direction and allows them to celebrate intermediate victories. Otherwise, progress is invisible, and people lose their bearings.

The cause of true burnout is not long hours, but the feeling of standing still. Internal company politics, information silos, and “Lego hoarding”—which Caldwell calls the habit of teams hiding data and knowledge within their own departments—create a huge amount of idling. When the path is clear, decisions are clear, and priorities are clear—people will work themselves to the bone on their own.

Vertical integration: not because it looks good, but because otherwise you won’t survive

One of the most romanticized principles of SpaceX and Tesla is vertical integration. From the outside, it looks simple. From the inside, it is not. Lujza says directly: he and Caldwell came from places where vertical integration looks easy from the outside. But it is not.

Caldwell’s formula: every decision about vertical integration must come down to one question—does the company exist without this step? If a part does not exist on the market, if the technology does not exist, or if the cost is so high that the company cannot survive without its own production—you must integrate. If not—you should not waste resources.

Vertical integration for the sake of saving five or even fifty percent on a component in the early days makes no sense. You are not eliminating a point in the supply chain—you are expanding it. The supplier also has their own supply chain, which you will now have to absorb along with them. The risk shifts from the supplier to you.

Strategic vertical integration comes later—when the company has already grown, the team is large, and the question is reducing unit production costs. And even then, it is a long decision requiring analysis.

Mariana Minerals became both a software company and a mining company—not for ideological reasons. Software products for mining companies penetrate the sector poorly because the speed of adopting new technologies in it is extremely low. Without the mining part, the company simply would not exist. This was the binary question.

Hiring: the tougher the interview, the better the team

Tesla and SpaceX are programs with the highest number of applications in the history of technical hiring. This is why their approach to hiring is easily idealized. The reality: a candidate for an engineering position speaks with six engineers before receiving an offer and almost certainly passes a technical test that shows how they think and whether they truly possess the skills listed in their resume.

8-10 conversations before an offer is not a bug, it’s a feature. Deep technical assessment is important not just for filtering: an engineer must be able to balance authority and responsibility autonomously. A rigorous interview process additionally filters out those who are motivated specifically by such a process. A strong engineer wants to know that their colleagues have gone through the same path.

Without the SpaceX or Tesla brand, managing candidate expectations is more difficult. But those who are truly inspired by the mission—who are exactly who you need—are willing to go through this path. Caldwell adds: the process must work both ways. A candidate joins a startup with high risk, so they too must get to know the team well.

Lujza speaks separately about internships: the vast majority of people doing critical work on Starship, Dragon, and Falcon are converted interns. A three-month probationary period is the best evaluation tool that exists. Those who give their all stay. Lujza himself interned at SpaceX four times and wanted to drop out of university to stay—but SpaceX refused him, saying that such a practice is no longer used.

When to leave and start your own

Both founders joined SpaceX and Tesla when they were young. Their advice to those thinking about founding a company: do not rush.

You need to participate in a project from start to finish—preferably several times. This gives you not just technical knowledge, but a calibrated understanding of how long each stage of work actually takes. Without this, it is impossible to set goals that the team is ready to follow and deadlines that people believe in.

The second argument is trust. Companies are assemblies of people driven by a common mission. Convincing them to join you is a painful and risky process. It is much easier if you have already gone through several production cycles and understand what is real and what is not. Your authority attracts the right people.

There is no recipe for the exact moment. But there is a principle: it is better to leave with an excess of technical foundation and learn fundraising and hiring on the go, rather than the other way around. Caldwell says directly: it is difficult to imagine mastering technical competencies after becoming a founder. Learning to build rockets while working as a founder is a bad idea.