moving fast

“Moving fast” is a core narrative in our collective tech culture. It is a score we keep: the more we ship, the better we’re doing. And yet, there’s very little advice on how to achieve fast movement. If any, it’s “use a productive tech stack”. That’s a partial solution to the technical problem. However, an organisation has many inputs, tech potentially being one of them. There are many levers to pull when attempting to increase velocity.

The most interesting lever I’ve come across was via a blog post by Patrick McKenzie (of patio11 fame). In it, he speaks of his time at Stripe. He had this to say about Stripe’s ability to move fast

If you’re already some version of a fast moving company, at a first approximation “just choose to move faster” is a ridiculous claim. Yet, I’ve heard it echoed by others. Even so, the path from choosing to move faster and moving faster in the real world is not a straight line. It’s not obvious what levers we have at our disposal.

Broadly, there are two ways to move faster. The first is reducing complexity, the second is really as Patrick opines, just choose to move faster. The former is simple. Take software development: if you’re building a web app, use a productive framework such as Ruby on Rails, Django or Phoenix. They peel away layers of complexity, leaving you to worry just about building. The net effect is moving faster. The latter on the other hand, is complicated.

There are two types of work: deep work and managerial work (for lack of a better name). Paul Graham popularised the idea (or possibly invented it), discussing the difference between the schedules of makers (e.g software developers) and managers. Makers require substantial blocks of time to do deep work. Managers engage with teams and stakeholders, their work days are a collection of meetings. In makers-land, choosing to move faster is a cost-quality-time trade-off. The cost of speed is either an increase in labour hours, a reduction in scope or an appetite for shortcuts. In managerial-land, choosing to move faster is a choice of operating cadence and a matter of prioritisation. That is, it’s a choice about when to do work. Take for example a meeting with a deliverable. If it’s me, I’ll be naturally inclined to have a turnaround time of a week. There’s slack built into it to ensure I have adequate time. An organisation with a high operating cadence will ask: “why not tomorrow or the next day?”. The answer may very well be: “I can actually do it by tomorrow”. The choice of when to do work is pulled closer to the present day, purely by choice. Indeed, one can only employ this if there is breathing room in the cadence. Once it is little to none, it becomes a matter of prioritisation.

My feeling is that most of the delta in choosing to move fast comes from reducing slack. It is much simpler (and potentially less harmful) to choose to do so. In the words of Patrick, it’s the choice to “set the operating cadence to run”.