Management

Elon Musk’s Engineering Principles – The 5 Step Process

Christian Scheb

There’s this interview with Elon Musk, showing around the SpaceX rocket production facility in Texas. There’s a lot of talk about rockets and stuff, though in between he’s giving some fascinating insights into the design process and the principles he’s following. The “5 Step Process” as he calls it. Wanted to write it up for myself, so I though I can share it here as well.

The following is a collection of what’s said during the interview, content composed from the subtitles. Did slight adjustments for readability.

<quotes by=”Elon Musk”>

I have a rule just implement rigorously is the sort of 5 Step Process.

1) Make your requirements less dumb

  • Your requirements are definitely dumb. It does not matter who gave them to you.
  • It’s particularly dangerous, if a smart person gave you the requirements, because you might not question them enough.
  • Everyone’s wrong, no matter who you are, everyone’s wrong some of the time.

2) Try very hard to delete the part or process

  • The bias tends to be very strongly towards “let’s add this part or the process step in case we need it”.
  • If you’re not adding things back in 10% of the time, you’re clearly not deleting enough.
  • Whatever requirement or constraint you have, it must come with a name, not a department. Cause you can’t ask the departments, you have to ask a person and that person who’s putting forward the requirement or constraint must agree that. They must take responsibility for that requirement. Otherwise you could have a requirement that basically an intern two years ago randomly came up with and they’re not even at the company anymore. And actually there’s no one at the department that currently agrees with that.

3) Simplify or optimize

  • The reason it’s the third step is cause it’s very common, possibly the most common error of a smart engineer, to optimize the thing that should not exist. Why would you do that? Everyone has been trained in high school and college that you gotta answer the question, convergent logic. So you can’t tell a professor “your question is dumb”. You will get a bad grade. So everyone, without knowing it, they got like a mental straight jacket on that is they’ll work on optimizing the thing that should simply not exist.
  • There’s another important principle, which is that you really want everyone to be chief engineer. So if everyone is chief engineer means that people need to understand the system at a high level to know when they are making a bad optimization.

4) Accelerate cycle time

You’re moving too slow, go faster. But don’t go faster until you’ve worked on the other three things first. If you’re digging your grave, don’t dig it faster, stop digging your grave.

5) Automate

I have personally made the mistake of going backwards on all five steps multiple times. Literally I automated, accelerated, simplified and then deleted. Automating was a mistake. Accelerating was mistake. Optimizing was a mistake. We just deleted and just bypassed this $2 million robot cell as a complete pile of nonsense.

Bonus

I think, currently a factory is underrated and design is overrated. So people generally think that, in this Eureka moment you come up with the idea and that’s it, now it’s good. But we design like this: literally a thousand percent, maybe 10000% more work that goes into the manufacturing system than the thing itself. Basically the amount of effort that goes into the design rounds down to zero, relative to the amount of the effort that goes into the manufacturing system.

And if this was not true, I’d be like “1000 Raptors [rocket engines] please. – Oh, you can’t make them? Oh, okay :(“

So this is like just very fundamentally underappreciated. If people have not been in manufacturing, especially manufacturing of something that’s relatively new, then they don’t understand. They think the design is the hard part, and they think production is like a copier or something like that. This is completely false. I can’t emphasize enough, I’m trying to correct the misperception that design is the hard part. It is not the hard part.

</quotes>

References

Lessons learned at my former company – Part I

Christian Scheb

It was the 13th of November, when I made the descision to leave my current company. I can remember that date, because according to my browser history, it was the day when I’ve choosen the song for my farewell mail (we had the tradition, that everyone who’s leaving links to a song in their last email). Some days passed until I’ve finally realized, that this was the moment, when I’ve switched my mindset from “keep going” to “I’m leaving”. After three tremendous years, I will quit my job as a lead developer and reach out for something new. Propably one of the hardest decisions I had to make.

Since then, I was often thinking about what happened in those years and what I’ve personally lerned from it. So I’m doing this post mostly for myself to recap, but maybe a former colleague or someone else will find it useful. Maybe you’ve made similar experience. So, this is about my lessons learned, as a member of a startup, as a developer, as a team lead. Let’s start with number one.

1. Know Your Limits

Let me tell you a story, a “war story”, that took place in the first months of the company, when everyone had that pioneer spirit. For me it was the most intense time at that company. The time when some individuals, who haven’t worked together before, became a team.

It was early 2012, when we just had licensed our first game and announced it to the press. The date for the closed beta release had already been choosen (for the non-gamers: closed beta is when a game is released to the public, but only for a limited amount of users). The plan was though, but it was possible. Unfortuately we got more and more into trouble, when some of our partners struggled with delays. The game developer needed more time to deliver the server software and we had similar problems with other service providers. We had to wait, until we received something to work with. It was only four weeks to prepare everything for launch – and nothing was ready. No game servers with the game running, no website, no account management. Everything needed to be built within those four weeks.

At that time we’ve been only two people in the tech department. Me, responsible for development, and my colleague, responsible for IT. So we did, what everyone working in tech is doing in such a situation: crunch time. It wasn’t a problem for us. We’ve been full of power, everyone was euphoric about our first release. Usually we started working at 10 a.m. like everyone else. All the other colleagues left at around 7 p.m. and the best part of the day began. No one randomly popping in and asking for stuff, we were able to concentrate on our tasks, at last. It was us two and the CTO sitting together and pushing forward. The atmosphere was nicely startup-ish, we ordered food, had a few beers and when everyone needed a break, we played a session of Minecraft and continued after an hour or so.

Our valley on the Minecraft Server
Our valley on the Minecraft Server

We’ve usually been exhausted late at night when everyone went home. For the next weeks we continued like this, almost seven days a week. Going to work, working, food, working, food, working, going home, sleeping, going to work… Looking back, I have to admit to myself that it was totally insane. I litterally had no life. Laundry piled up at home, the fridge was empty, but at least I’ve learned a lot about Berlin’s night bus lines.

Berlin Night, shot at 16.02.2012 at 2:30 a.m.
Picture shot on the way home, 16th of Febrary 2012 at 2:30 a.m.

So why am I telling this? Because at that time I’ve permanently exceeded my personal limit. I was so fueled by the challenge of making it happen, that I didn’t care about myself. And as usual, if you drive above the limit too long, something will go wrong. In my case it was the result of me being totally wasted by the previous weeks, suddenly all that pressure fell off on the launch day and I made a decision I’d have better thought twice.

Although it was kind of harmless, many month later it made me realize, that exceeding your personal limit is a real problem. It may be ok from time to time, but you should make sure not to exceed it for too long. Otherwise you will most certainly harm yourself. A former colleague of mine did not get off that lightly – he got a burnout and needed to start a therapy. That’s certainly an experience nobody want’s to live through.

Today’s working environments make it easy to reach your limit and going further. Therefore it is even more important than ever to be aware of your personal limit and – that’s equally important – you have to be able to realize when you’re exceeding it. I’m not saying you have to avoid it under any circumstances. Sometimes it is necessary to give 120%. But if you see yourself permanently running at 120%, something is wrong and you must not hesitate to change it. I can’t tell you what to do, because it strongly depends on your indiviual situation. For me the solution simply was to keep an eye on myself and to force myself into some spare time away from the workplace, instead of doing extra hours just for fun, when I had no plans for the evening.

Altogether, find a healthy balance between work and leisure time. Oh, that sounds so much generation Y 😉

To be continued…