It is interesting how startups are always surrounded by myths.
I am not referring to the traditional creation myth of the startup, founded by a visionary teenager in a garage that somehow built an empire based only on their own genius and willpower.
I am thinking instead of the myth that in a startup you need to hack your way into your first version, disregarding quality processes and design guidelines, with the goal of releasing your product as quickly as humanly possible.
Then – the myth continues – if your startup is successful, you can also hire more people to rewrite the product and pay all that tech debt.
Instead, as someone that has watched closely a startup going from a small team to IPO, in hindsight it shocks me the level of organization, discipline and excellence necessary from day 0 to make a startup succeed.
While I am sure there are startups that achieved success despite ignoring all sorts of standards, I argue that most of the successful ones are actually quite disciplined from the very start.
The reality I have seen first hand is that if your startup is successful, you will never have the time to go back and rewrite the foundational pieces of the product.
You will have so much demand and so many things to do in order to scale the product and processes that you will be doing just the bare necessary work year in and year out in order to keep up.
In particular, a lot of the work done in the first year of the company is infrastructure, which is very likely to linger for a very long time. A badly designed piece of infrastructure will eat your team’s productivity day after day. Then it gets worse non-linearly with team growth and increase in the number of lines of code.
This is waste that prevents your customer from achieving higher value, and makes your product lose competition over time. It also pisses off your best talent and makes it harder for you to hire good people.
In my experience, the right way to build is to (1) obsessively simplify the product and design, which can be achieved by (2) obsessively designing the right interfaces.
Of course there are other important design guidelines that should be followed, such as the right setup for testing infrastructure, but I believe (1) and (2) above are the bread and butter of making something that can stand the test of time.
Code is something that only gets more complex over time. When you are building the foundation of your product you need to start with a very simple base, constantly focusing on how to decrease coupling, increase modularity, and get the right abstractions in the right places.
Interfaces are the touch points between modules and between products and humans. Complexity is built on these touch points. Interfaces are meant to hide complexity through higher level abstractions. As time passes, anything you expose through an interface is very hard to hide again. As your startup starts to grow, they will become written in stone.
What I have seen in successful products is extreme discipline at their inception – exactly the opposite of the hacky startup myth.
Paradoxically, ignoring basic engineering design principles will not make you go faster. Quality and speed go hand in hand. In order to go fast, you need to trust the modules you are building upon.
In my experience, what makes or breaks a startup is discipline. The same lack of discipline that will make engineers write spaghetti code will also make the product team release features, interfaces or workflows that no one will use.
In other words, you should build the minimum necessary with very high quality. This is how you achieve speed and scalability.
By building the minimum and releasing it, you ensure that your hypotheses are tested and your startup learning rate is increased. By building very high quality modular code, you ensure optionality, so that you can quickly iterate and evolve your code as you learn. Things go hand-in-hand.
Keys
- Obsessively simplify the product in all levels;
- Obsessively design clean interfaces, following the basic principles of modularity;
- Build as little as possible and release it so that you can learn quickly;
- Modularity brings optionality, because changes will certainly come as you learn;
- Your work in a startup is to build structure. Without discipline, you cannot structure things.