How to ship fast
A lot has been written on how important it is for startups to ship fast. Less has been written on how to ship fast.
We are far from perfect at Equals. But we have shipped a lot of high-quality software, quickly. I’ve developed a set of principles for moving fast over the last ~12 years I’ve been building software here, at my last startup, and at Intercom. These are intended for a founder/leader audience.
1. Protect momentum
Momentum is the lifeblood of startups. When you ship every day, it lifts everyone’s spirits. When a project is constantly delayed, it’s soul-destroying. The key to shipping fast is never losing momentum. Once momentum is lost, the context in our heads starts to fade, teams lose energy, and the end becomes blurry. Once momentum is lost, it’s difficult to get back.
Protect momentum at all costs.
2. Beware of prioritization
Time spent on prioritization is the canary in the coal mine for not being close enough to your customers. The discrete task of prioritization should take almost no time. Only work on Important things. Sort those Important things into “Do now” and “Do next”. If you are only working on Important things, the order does not matter too much (and don’t spend time debating it). If what’s Important is not obvious, you are not close enough to your customers. If you need to run an exercise, you are not close enough to your customers. If you are not close enough to your customers, priorities will change as you get input from customers. This will cause thrash, and you will lose momentum.
3. Stay close to the design
Going down a wrong path is expensive. As a concept gets fleshed out, it becomes a design, and people get attached. When the design changes, people get confused. When you start building, there’s a nagging confusion in the back of your head about which way you should be doing things. Never mind the time wasted going down the wrong path itself. All of this causes lost momentum.
The only protection against this (that I’ve found) is to stay very, very close to projects in the design stage. In practice, this means you must meet with your designers every single day, for at least 30 minutes per individual. Maybe longer.
4. You should be wrong sometimes
There is no such thing as a perfect decision. It’s far better to be wrong 20% of the time and to decide quickly than it is to always be right. If you are never wrong, you are deciding too slowly. So much time is wasted in startups looking at data trying to make perfect decisions. Use data for finding questions, not finding answers. Confirm your answers by staying close to customers and by shipping.
5. Only doers can plan what you work on
Software engineers want to commit to a timeline and meet or exceed expectations. This means they pad estimates, consciously or unconsciously. Padded estimates aren’t free – work will always expand to fill the time given. This makes for flabby projects. And flabby projects kill momentum.
Steve Jobs talked about how the major thinkers are the major doers. Leonardo didn’t have a strategist planning his future paintings. Those that plan must also do. Those that plan must have the knowledge and the credibility to push back on estimates from those doing the work. Those that plan must understand the systems their teams are building in. When your planners are also doers, you avoid flabby projects, and you protect momentum.
(Our head of engineering and I commit code every week. Sometimes, a lot of code.)
6. Always plan the How
Every project longer than a day must have an engineering plan, no exceptions. There is nothing more guaranteed to blow up a project than realizing weeks (or months in) that a requirement was missed. Realizing that your approach won’t work at all! That you’ll have to backtrack – and say goodbye to any momentum. This is easily avoided with a written plan. The plan should detail how each requirement will be implemented. The plan should be written by the engineer responsible for the work. By enumerating each requirement and how to implement it, you see the whole picture. You see how the puzzle pieces fit together. You ensure that part A and part B will work together. You ensure you don’t backtrack later.
7. There is no quality vs. speed tradeoff
One of the great lies in software engineering is that you have to choose between shipping quickly and shipping at a high quality. It’s bullshit. With deep focus and care, the best engineers can consistently do both. It’s an active decision. Conversely, taking time to “do it right” almost never works and usually results in worse code. Poor quality slows down future development. Poor quality causes bugs that need to be fixed. Avoid letting talk of this tradeoff seep into your organization – it’s a great momentum killer. Ship fast. Ship quality. You can choose both.
8. Capture inspiration
Moments of inspiration are rare. They are special, fleeting, and fragile. Letting these moments slip by because you already decided to work on something else is a mistake. When you feel inspired, pull on the thread. Allow your team the same grace. These are the moments when you can accelerate months in days.