For a while now, I’ve wanted to distill my philosophy on project management and working with other people that I learned while working at SpaceX for 4+ years. I’ve tried to write this article many times, but I couldn’t find an elegant way to create a framework that “made sense”. However, I’m coming to terms with the fact that it probably doesn’t make a ton of sense. There’s probably some random inconsistencies, and sometimes I just sound like either a toxic manager or a disgruntled employee.
I hesitate to write this at all because it’s probably an incomplete re-discovery of industry practices (Agile, Lean Manufacturing, etc). That’s fine. To be frank, I don’t really care about anybody’s professional opinion when it comes to what works for me. This is what I’ve found that works well. It’s battle tested. I’ve executed on projects with ridiculous efficiency when people were on the same page with me.
This stuff probably won’t help you if you’re running Google or Amazon, but I think it should help you if you’re building physical things with small-ish teams. These are the lessons I learned at SpaceX integrating hardware, firmware, and software on really tight timelines. You shouldn’t treat this as a bunch of facts to memorize, but more so a mental model upon which you can apply your own experiences.
If there’s one thing that ties all of this together, it’s this: everything here is about staying connected to what’s actually real. Building things that work in reality. Planning based on reality. The faster you can expose your ideas to reality, the faster you’ll know if they’re garbage. That’s it.
Part I: Culture
Everything else fails without this foundation. You cannot execute efficiently if your team is paralyzed by fear, lying to each other, or playing office politics. Fix the culture first, or don’t bother with the rest of this.
Fear is the Mind-Killer
Before we get into the actual mechanics of project management, we need to address fear. This is the fear of being fired, the fear of being reprimanded, the fear of being called an idiot, or generally being anxious to share your thoughts. Office politics stem from fear or other Cover Your Ass (CYA) activities. These are, in every respect, completely useless garbage and needs to be ripped out of any team with any hope of succeeding.
Sadly, politics lives in every team. Sometimes a lot, sometimes a little. Humans seem to be completely incapable of not causing politics. It’s almost like a byproduct of digesting our food. Perhaps if you’re a well groomed person, you keep those politics to the side and managed. If you’re gross and stinky, perhaps the politics fall in big chunks and people need to work around them.
The solution to this is two-fold: toxic and political people must be removed from the team completely, and you must foster a culture of brutal honesty. We’ll come back to the honesty part when we talk about planning.
Ownership
The idea of ownership is essential when working with a team. However, it’s not something that’s top-down mandated or something that can be easily extrinsically motivated. It’s an intrinsic quality of a builder. Something they learn they must partake in, or nobody will partake in it.
When owning a product, design, or simple task, it’s important to fully understand the lifetime of the implications you are creating. Understanding what happens when your work output is used is important. It’s one thing to create a design, but it’s another thing entirely to understand all of the ways in which it will be manipulated once it exists. A good way to understand ownership is to understand what it looks like when it fails.
For example, one way junior engineers fail a lot is by not understanding that someone has to assemble the thing they designed on a computer. A builder does understand this, they are assembling it in their brain while they are designing it. They’re iterating upon the design in concert with planning how they would build it. This is considering the full lifespan of their work output, who it affects, and why it affects them.
You can own things that aren’t physical as well. For example, say you are tasked with verifying that a specific device will work for a specific purpose. Someone that’s not an owner will look at the device and do a light test. Maybe turn it on, see that it probably works, then move to the next task.
An owner, on the other hand, will take the device and get as close to the environment it will be used in. Test it while it’s in the environment, and make for sure that it will work. Chasing down the problem until they are 100% sure without a doubt that the device will work. That is what being an owner is.
Attitude
Everyone is on the same team. It doesn't matter if you work on something for 5 billion hours, and someone else only worked on that project for 5 hours. Being able to take critical feedback on your design decisions is really important.
Don't let your ego get in the way. The goal is to build the thing well, not to be right.
People Need to Be Good
This sounds obvious but it’s worth stating: you need competent people. You can have the best culture, the best plan, the best processes, but if your team can’t execute, none of it matters.
Builders are different from talkers. Builders see the path from A to B and start walking. Talkers theorize about the path. You need builders.
Part II: Planning
Planning feels difficult at first blush. Planning is actually quite simple, and must be simplified in order to work. But simple doesn’t mean casual, it means rigorous and detailed.
Bottom-Up Planning
The people involved in planning must be a bottom-up system of people, starting with the ones actually doing the ground level work. Middle management is almost always blind to what the actual work is, even if they are engineers as well. The people doing the work know the limits and all the steps to building and integrating a system. They alone can set accurate and aggressive schedules.
This is non-negotiable. If your plan is created by people who aren’t doing the work, your plan is fiction.
Brutal Honesty in Planning
This is where that honesty from the culture section becomes critical. Lying is bad, but the type of lying in planning is especially harmful. This can be explained as setting aggressive deadlines so people work faster and harder. This does not work.
If you have ever built anything in your life, you understand that there are temporal limits to how quickly something can be built. Going fast is great, within reason. Many people, especially young engineers, do not know what “within reason” is. How quickly can you source a part, or machine it, or assemble something, or code something, these are things that are hard to quantify without experience.
Setting hard boundaries on how quickly these things can be done, with experience to back you up, fosters a culture of brutal honesty which allows the plan to work, and allows everyone to move quickly. This reduces waste from re-planning and reduces waste from go-backs. Ultimately letting you focus on building.
Leadership is the most important part of growing a culture where people can be honest. Things take time, and good things take a lot of time, effort, blood, sweat, and tears. Being deaf to these needs, these truths, only hampers your team and your morale. This is a top-down culture thing. If leadership lies or tolerates lying, the whole thing falls apart.
Don’t make fake deadlines. They’re obvious to everyone doing the actual work, and they destroy trust immediately.
Meticulous Detail
The key to making an accurate plan is to be meticulous and ridiculously detailed. If you’re planning a month-long project, every day needs to be planned. A year-long project, every week needs to be planned.
The inputs a team requires, and outputs a team produces, is also essential to map to enable cross-team productivity. Through this meticulous planning exercise you will design the system, then iterate upon it. Understand bottlenecks and eliminate them. The vision will become clear, and the path will reveal itself to you.
This level of detail feels excessive until you do it. Then you realize it’s the only way to actually know if your timeline is real or fantasy.
Seeing The Path
Being able to clearly see the steps between point A, the current state of the world, to point B, the desired state of the world, is something that builders hone with incredible accuracy. If you know what I’m talking about, then you can probably visualize these steps for your current projects.
I like to call this “seeing the path”.
Some people are really good at this. They can quickly understand every step for everything that needs to be done, nearly to the point of visualizing themselves doing every step. Some people are absolutely terrible at this, completely uncertain as to the next steps to take.
Being efficient is about building this muscle, and building this muscle is about building things as much as possible. Eventually you’ll see the patterns emerge, the familiar steps, which eventually becomes building blocks in your grand vision for every project.
Seeing the path is almost an instinctual ability, but the path must be refined with careful planning. Thinking through the steps, and more importantly, where you even want to go is incredibly important. Many times, I’ve been involved in a project where we started with one idea, and through thinking and discussion with the team, we arrived at an elegant solution. With experts, this flows quickly. You can start with one idea, then swiftly move to the more elegant idea through iterative planning.
Treat the Plan with Respect
Plan well. Treat the plan with respect. Providing a clear goal for the team that everyone partakes in creating is the only way to move fast.
A good way to completely destroy morale is by acting like you planned then lying about it later. The plan is not some document you show executives. The plan is the shared understanding of how you’re going to build the thing. If you don’t respect it, nobody else will either.
Part III: Execution
This is where theory meets reality. You have the culture, you have the plan. Now you have to actually build the thing.
Minimize Ceremony
Stop having so many meetings. Meetings aren’t for builders, they’re for management. Let them waste their time. You have shit to build.
You’ve already created your detailed plan with the people doing the work. That plan can be shared asynchronously. Brief it rarely in a group setting just to make sure everyone is on the same page, then get out of the way. When issues come up, impromptu stand-ups and status check-ins work best because they are quick, focused, problem-solving conversations in the moment.
Go fast. Don’t sit in meeting rooms wasting your time. Execute. It’s time to build.
Start With Something
Just make it exist first, you can make it good later.
It’s incredibly difficult to reason about a system that does not exist. You first need to just make something. This allows you to have thoughts about it. Without something concrete, you’re simply daydreaming about something that might work.
Just put some clay on the table. You can mold it, but first just make it exist. It’s pretty hard, basically impossible, to skip to the most optimized version of a system. Many designs evolve rather than being strictly designed. You start with something, then iterate it toward better. Build the thing, see what’s wrong, fix it. Repeat.
Quality Early
When you start a project, you need to be super concerned about the small details. Getting a small thing wrong in the early stages could become hours or days of rework down the line. Be hyper paranoid right when the project starts, review your work and get others to review your work as well.
To move fast, you need quality. You need excellence in the early stages of execution. Good craftsmanship. This avoids rework later in the project, or retooling, or other running around trying to fix what was originally a simple data entry problem.
Test Incrementally
Once you have something, you need to start validating it immediately. Testing doesn’t need to be complicated.
Testing starts occurring as soon as power is applied to the first boards you’ve populated. Hey, it turns on, test complete. Testing occurs when you get firmware to talk to all of the peripherals for the first time. They talk to each other, cool, test complete.
These little, incremental, steps are small tests, but they are huge for buying down risk. That’s what testing is, ultimately. Ensuring the design has as little risk as possible in it. When you start from zero on anything you will go through this process of building knowledge about the system incrementally and buying down risk.
Sprint to Your First All-Up Integrated Test
Your goal on any project should be to fully integrate and power on the system as fast as possible. Sprint to your first all-up integrated test. I absolutely stress this part because it has burned me before.
When you get to the day you finally get to put your board with your firmware into the vehicle, the space suit, or even the toaster oven, there will be problems. Sometimes there are zero problems, actually. However, always assume there will be a massive problem that needs to be worked.
This is why it’s critical to get your hardware interacting with the other systems and harnessing it’ll interact with as soon as possible. Figure out which stupid assumption you made as early as you possibly can. If you forget everything else I type here, remember this.
Test Like You Fly
Once you have integration working, refine your test setup until it matches flight conditions.
Eventually, you should have all of the hardware talking to each other, with the flight software running, and something feeding representative flight data into the hardware. If all of this is exactly as it will be in flight, and you find no issues, then it’ll most likely work in flight.
Don’t over-complicate doing this either, you can use the vehicle itself to run these Hardware In The Loop tests. The goal is simply to model the thing that will happen, feed it to the hardware and software, and make sure it responds correctly without breaking. That’s it.
Part IV: Communication
You can have the best plan and the best builders, but if nobody talks to each other, you’ll still fail. Communication is what keeps everyone synchronized and moving in the same direction.
Keep the Comms High and Informal
A status email is good for executives, but nothing of value is going to come from writing one. Keep your comms with the immediate team super high and super informal. This means random check-ins with your fellow engineers to clear up thoughts and pseudo-formalize the next hours, days, weeks. Figure out how to mutually unblock each other.
Over-Communicate
Communication between team members is essential. That doesn’t only mean communicating with the guy that sits next to you, it’s communicating with everyone that needs to know about your part and has some hand in it. The people that will use it, the people that will build it, the people integrating it into their systems.
You need to be communicating and verifying so much that people get annoyed with you. You should be walking up to people's desks and asking clarifying questions on a daily basis. This serves as a great time to plan about when certain things are needed from each other, along with how you can help each other.
Part V: Getting Better
This is about continuous improvement. How you get better at all of this over time.
Carve Out Time to Think
It’s easy to fall into a trap of constant execution without reflection. Stop doing and think. Actually think about what you’re building, why you’re building it, and if there’s a better way.
Some of the best design decisions come from taking a step back and really thinking through the problem. This isn’t wasted time. This is how you avoid building the wrong thing efficiently.
Earlier I said most things are evolved instead of designed. That is true. However, you can pause this cycle to really scrutinize and optimize the evolved form that you have come to. Doing this regularly can help cut the fat from previous evolutions that result in vestigial parts, or non-optimal ways of doing things.
Become a Craftsman
Seeing the path, understanding ownership, knowing what good looks like, these are muscles you build through repetition. The more you build, the more patterns you recognize. The familiar steps become building blocks in your mental model.
You can’t shortcut this. You have to build things, make mistakes, fix them, and do it again. Eventually, the patterns emerge and you start moving faster because you’ve seen this before.
Finally, you should come to see this as what it is: a craft. You should treat your work as a woodworker treats a good cut of mahogany. Prepare it with respect, and in the end, a bit of perfectionism. Get a little carried away some times.
That’s it. Build things. Build them with good people. Plan meticulously. Execute relentlessly. Communicate constantly. Stay connected to reality.
Nicely written. Succinct and to the point. Thanks for sharing your hard-earned experience!
Nice