SpaceX has been one of the few private companies who have been able to break into the space launch business, with a number of firsts (full list):
While there are likely many reasons for their success, Elon Musk highlighted in an interview with Tim Dodd their process for building new features and products. It is composed of five steps:
It is worth going into each of these in more detail, and how they can relate to GitLab.
Elon says in the interview:
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. Also, whatever requirement or constraint you have it must come with a name, not a department. Because you can’t ask the department, you have to ask a person. And that person who’s pulling for the requirement or constraint must agree that they must take responsibility for that requirement.
For GitLab, one can translate this into two key actions:
These two actions help to ensure our requirements are "less dumb" and it is clear to all why a given requirement is in place.
Elon says in the interview:
The bias tends to be very strongly towards lets’s add this part of the process in case we need it, but you can basically make “in case” arguments for so many things. ... This is actually very important. If you’re not occasionally adding things back in, you are not deleting enough.
This is indeed important, especially as a company and a product scale and grow over time. As noted by Elon, there is a natural inclination to add a process or feature for every single scenario. This however leads to very sub-optimal outcomes.
From a process standpoint, decision velocity can be slowed as well as overall time to market. From a product standpoint, the UX, code, and feature set can become so complex that it is difficult to learn, maintain, and use.
As you are building new features or introducing new code/processes, ask whether this is really needed, as well as whether by virtue of this addition could we deprecate existing features/code/processes.
Then only in the third step is “Simplify or optimize”. The third step, not the first step. The reason it’s at the third step is because it’s very common, as possibly the most common error of a smart engineer is to optimize a thing that should not exist
For GitLab and software companies, one can translate this into a few recommended actions:
Elon notes in the interview:
You’re moving too slowly, go faster. But don’t go faster until you work on the other three things first. If you’re digging, you know, your grave, don’t dig it faster. Stop digging your grave, you know.
This principle aligns well with a few of GitLab's core values, such as:
Once a feature or process finds product fit or is validated to be of significant positive value, it should be a candidate for further automation. This is particularly important to do last, since spending the time up front to automate a un-validated solution to a problem is particularly risky and not very iterative.
While this may seem to be common sense as part of this flow, it is often times counter-intertuitive in practice. This is because there is a strong desire to reduce manual touches, or to launch with a great UX from the very beginning. The challenge is that this often significantly increases the iteration size, and can delay important learnings which may cause a chagne in direction.
As Elon notes in the interview:
The final step is “Automate”. Now, I have personally made the mistake of going backwards on all five steps multiple times. So I have to repeat this - yes, multiple times.