What gear are you in? 🚗

In which I torture a car-based analogy

👋 Hey.

I didn’t know whether to post this week. This newsletter seems remarkably unimportant in comparison to the many important events over the past few weeks. Ultimately, I decided to write out of personal enjoyment. With this lens on, I hope it brings you a small amount of happiness.

First, I’m matching donations to charities that support Black Lives Matter related causes (up to £500, but if I see higher demand, I’ll up it). Please let me know if you’ve donated by tweeting me, and I’ll match it.

Second, if it’s your first time reading, here’s a little refresher. The goal of this newsletter is to discuss techniques for building better software and being more effective in high growth companies. I mix in longer form content — think a short blog post that you could read in 5 minutes — with some of my favourite links.

Over the last few weeks, I’ve covered:

• The power of proposals

• How to tame Slack

If you’re interested, I’d love for you to subscribe. Just hit the button below.

---

What gear are you in? 🚗

The majority of UK cars are sold with a manual gearbox. In this type of car, the driver must make conscious decisions to change between different gears. Each gear behaves differently, and is optimised for a certain purpose. Low gears give immediate acceleration power. High gears allow you to efficiently travel long distances. Driving in 1st gear down the motorway will certainly destroy your car. Attempting to pull off from the lights in 5th gear will mean you get nowhere.

I think there’s a tenuous analogy with shipping software here. Let’s imagine that the gears of a car represent the timeframe we’re optimising for: for example, the next two weeks, vs. 2 years from now. Lower gears represent caring about speed in immediate time periods, higher gears represent speed over distant time periods. We can shift between gears to optimise for speed over different time horizons.

I think there are four gears worth discussing at fast growing companies:

• 1st gear: immediate term, 1-2 weeks

• 2nd gear: short term, 2-4 weeks

• 3rd gear: medium term, 1-3 months

• 4th gear: long term, 3 months+

The analogy isn’t perfect, but I think it’s enough to work with! Let’s get into it.

Gear choices should be conscious

Optimising for speed over one timeframe, usually means slowing down on speed on another timeframe.

For example, optimising for immediate term speed usually means that you’ll be slower over the medium term, as you repay technical debt incurred. Imagine the classic case of just trying to get something working in time for the launch of a new product.

Optimising for long term speed usually means being slower in the immediate term: being deliberate and focused with your choices means that you have to let immediate term fires burn.

Which is the right choice? There isn’t a single right choice. There’s only good judgement, given the circumstances.

Gear choices should be conscious

Like a manual car, the gear that you’re in should be a deliberate decision. You should switch gear when the circumstances encourage it.

How do you decide which gear to be in? Should we care about the next two weeks, or optimise for the long term? Somewhere in between? It’s hard to tell.

I think it’s a weighting of the following factors:

• Culture: the eternal ‘move fast and break things’ comes to mind here. Some companies have operating in a certain gear baked into their DNA.

• Existential risk: companies that live or die by continued high growth usually need to optimise for speed in shorter time periods, than companies that are profitable — stop the presses!

• Morale: if you, or your team is burned out by months or years of working in ‘low gears’, then it’s probably best to choose a higher gear and give your team a break.

Low gears

Some very short term things are worth optimising for, at the expense of longer term speed. The most common case is the existential risk of the company, or the possibility of extreme upside if you react in a short term manner.

For example, imagine you’re a business-to-business SaaS company, in competition with another firm for a large contract that would transform the trajectory of the company. You should 100% optimise for speed over the immediate term. It’s often worth being extremely nimble: doing what you need to do to close the deal — be that adding new features or tweaking things quickly in reaction to client feedback.

Once you’ve won the deal, you can repay some of the debt you took on to do this.

Default to medium term speed

I spent a good chunk of 2019 running the Data Engineering team at Monzo. My manager — the VP of Data — was excellent. One thing that always rubbed off on me was his blend between immediate pragmatism, combined with a focus on medium term speed. One of the mantras was ‘slow down to speed up’.

In data science, it’s very easy to optimise for immediate term speed. Run a query in BigQuery, spit the results out into a Google Sheet, and hack together a chart. We’ve all been there. But, if your work is useful, people will ask you to update it, or make changes to it (this is a compliment!). Optimising for immediate term speed means that the knowledge from your analysis is trapped in a sheet that you’re not able to update easily. Knowledge becomes siloed. Data science teams turn into BI teams.

Instead — the team are explicitly encouraged to optimise for medium term speed. This means spending an extra few hours to make this a self-serve data model in Looker, so anyone around the organisation can use it, and mess around with the data to their hearts content. Computers automatically update the results. Previous data models are re-used for new analyses.

I think there’s a real lesson here. In steady state operation, it’s best to optimise for medium term speed. You then combine this with a long term vision of where you want to be, changing course as you receive new information.

Optimising for long term speed in high growth companies is challenging

It's tough to make predictions, especially about the future - Yogi Berra

I don’t know what I’m having for dinner tomorrow, let alone what is happening in 3 months time.

In startups, it’s hard to have the luxury to optimise for something that will make you faster in 12 months time. Re-platforming is an occasional example of this, but even that is fraught with problems.

You should have a vision for where you want to get to and principles you won’t break, but it’s hard to directly optimise for being quicker over this timeframe. This doesn’t mean that you don’t know where you’re going: speed and direction are different.

Applying this knowledge

This is all quite abstract, I know. How does this help you do your job?

Leaders:

• Be clear with your team about what gear you’re in: people having different expectations about time cycles is a common cause of conflict.

• Be mindful of how long you have been in that gear, and whether it’s still the appropriate one.

• Let your teams know when you’ve decided to change gear, and your thought process for doing so.

Engineers:

• Explicitly ask what gear you are in! It helps you calibrate how you need to work.

• Be wary of organisations that are always optimising for immediate term speed. Chance of burnout is high, and quality is likely to be low.

---

Best of the internet 🔗

Every week, I collate some of my favourite links to share. Found something cool, or built something great? Send it to me by replying to this email and I might include it in the next edition. 📧

Writing strategies and visions - Will Larson

Will discusses how to write two types of document: strategies, and visions. Visions are aspirational, long term documents. Strategies are practical approaches to specific problems you face. Based on what we just discussed, it’s extremely topical. As an aside — Will is fantastic. Go spend a few hours on his blog.

Shipping is your company’s heartbeat - Darragh Curran

Darragh espouses the many benefits of shipping quickly and continuously. I agree wholeheartedly.

FrequencyReducesDifficulty - Martin Fowler

‘If it hurts, do it more often’. This is the central theme underpinning Martin’s post, which blends well with the ideas laid out by Darragh. For example, shipping once a month is exponentially more painful than the sum of pain incurred shipping once per hour. I’ve seen this proven time and time again. If it hurts, do it more often.

---

That’s all from this week’s High Growth Engineering. If you enjoyed it, I’d really appreciate it if you could do one of the following:

• Share it with a friend that would find it useful.

• Follow me on Twitter: @sjwhitworth

Want to have your say on what I write about next? Just hit reply.

All the best,

Stephen