Good Engineers Ship Quickly
Why Startup Engineers Need To Emphasise Speed Over Quality
Many engineering teams fall into a bias towards quality.
It comes from a good place. What if x happens? I’ve seen something similar go horribly wrong! Are we sure this is good enough?
Startups need to prioritise speed and shipping over and above focusing on quality. This is essential to survive and thrive.
If done correctly it is a superpower that allows you to play offence to challenge great entrenched companies playing defence.
A Culture Of Speed Is A Startup’s Biggest Advantage
When IBM was the giant, the startup were Apple and Microsoft.
When Microsoft was the giant, there was Google.
If we were talking in terms of quality and resources, a startup could never defeat a giant incumbent.
Yet in the hundreds of years of corporate entities the constant has been that big corporations peak then stutter while smaller, weaker but more nimble competitors take their place.
This is arguably almost always due to speed of execution.
The burden of supporting millions, hundreds of millions then billions of customers lead to compromises and discussions slowing down execution. Agonising over small decisions and tradeoffs to ensure that decisions don’t break experiences for countless of customers. This doesn’t mean the teams that who do this are wrong — they are right most of the time — for there is always a tradeoff to be made and a risk in some shape or form.
But that’s the problem. If you are always slowing things down to preserve and defend you will stop playing offence.
Engineering teams need to embrace speed and play offence.
“One of the biggest advantages that start ups have is execution speed, and you have to have this relentless operating rhythm.” — Sam Altman
Pitfalls Of Quality To Avoid
1. The Quality Boogeyman
There is a general tendency for engineers to overvalue a fear of low quality over shipping code.
But in a startup this is a luxury you rarely have. By hesitating shipping code you are not only putting you and your team unnecessarily behind, but also contributing to a culture of overthinking.
It can also be an excuse for some actions for example: let’s not ship today because it’s risky. Let’s wait until x.
It results in gatekeepers. Unnecessary processes. A culture of a fear of shipping.
Quality can only be determined if you know what it is you are specifically wanting to achieve. You need to factor security, reliability and scalability. But these things cannot be the ends justifying pushing out execution.
If you don’t know a clear why linked to the present, then you are likely overthinking and you need to actively fight against this.
2. The Lessons Of The Past Are Tools Not Rules
There is almost never a situation where there is a 1:1 mapping between what you have seen before and now. As Mark Twain said “History doesn’t repeat itself, but it often rhymes.”
The customers needs, team is different, the resources and time constraints are all different.
Especially in a startup context it’s essential to focus with an open mind as to what is needed.
It can be tempting to argue for a solution based on arguments that you had seen before work well elsewhere. But we need to keep in mind that all contexts are different. We need to make a distinction between a good idea and a good idea fit for the current context.
The lessons of the past are simply tools to help us problem solve the present. The fact that something happened in the past does not in themselves justify your actions to follow it blindly in the present.
The future is not guaranteed. In fact as startup you are likely to fail. This dread of failure needs to drive us to be pragmatic and constantly put ourselves in a position to iterate.
“The most important ‘speed’ issue is often not technical but cultural. It’s convincing everyone that the company’s survival depends on everyone moving as fast as possible.” - Bill Gates
3. Beware Of Using Past Experiences As A Crutch
Experience can get in the way. I’ve seen this both in myself and others that I genuinely respect a lot.
If you are not careful past experiences can become a crutch and a glass through which everything is viewed rather than truly going from a place of identifying what is needed. At X this happened and saw Y so we must to do Z.
We are all not immune to this.
I am not saying experience is not valuable, it most definitely is but we need to use our experiences to help solve problems in the present and not to recreate our experiences of the past.
We do not learn from experience… we learn from reflecting on experience. - John Dewey
4. You Can’t Predict The Future
You can’t predict the future. No matter how hard we try or how clever we think we are.
Whatever decision you make, you will almost always need to revisit at a future stage.
If your startup is thriving you will most definitely find out new needs of the customer that drastically changes your codebase’s foundations. You will find scalability flaws or reliability issues that result in patching or even reworking.
When you are small there are very few truly big issues you need to delay shipping to get perfect.
If you work to a perfection that has no end, you will do the same every time leading to delays at all points.
But if you are clear on your needs now and emphasise quality that is essential it will allow you to ship quickly and foster a culture of speed.
Practical Tips For Engineers To Ship Quickly
- Know the why — you should know why a feature is being built, for whom, and for what purpose. This should give you a clear idea if a task is must do or a “nice to have”.
- Be ruthless in prioritising — There are a million different things you could be adding in. Knowing what makes a difference and what doesn’t is essential to a great software team. Identifying and Articulating this is a responsibility for everyone in the team.
- Don’t nit pick — if you are nit picking clearly say so and don’t block PRs. If you block for a reason clearly articulate it and then fact check yourself.
- Gravitate towards shipping daily, not weekly — There may be genuine reasons why code is taking days and days to finish but it should be few. Working on iterating with smaller pieces of code encourages a culture of speed and good code reviews.
- Prioritise reviewing code — Code should be reviewed and merged as quickly as possible. The culture of urgency in a team is arguably based on this foundation.
- Don’t be afraid of mistakes — You can’t guarantee that you won’t make a mistake by spending unlimited time on it. Sometimes you just need to make a call and move quickly. And if that leads to consequences that you didn’t foresee then you need to learn and add that into your toolkit.
- Don’t identify with your past code — Code from the past was based on past decisions. They should influence your decisions eg. conventions, patterns that made things faster or better in some way. But they don’t stop you from making decisions now. Don’t hold stubbornly for the sake of rules. You are free to make the decisions based on what you know now just as much as individuals in the past made their decisions.
Hi I’m James, a Front-end software engineer from New Zealand. I’m passionate about user experiences and making a positive impact through software. I’m also a huge history aficionado. Feel free to connect with me on twitter, substack and dev.to :)