Tempo

   

A meandering, initial, word vomit exploration of tempo.

In Boyd, a key part of John Boyd’s warfare strategy is being able to have faster decision-making tempo than your opponent.

Initially, this comes from his experience as a fighter pilot. In a dogfight, it’s critical to be able to outmaneuver your opponent. On offense, this lets you take down your opponent. On defense, this can save your life. To outmaneuver your opponent, you need to react to your opponent, outpace them, and eventually overwhelm them.

This idea—tempo—has suddenly connected a number of seemingly-unrelated concepts I’ve had.

Connections

This idea of tempo is everywhere, though sometimes it hides behind something else. Let’s connect some of them, rapid-fire style.

Well-Oiled Machines

A phrase that always catches my ear is “well-oiled machine.” It comes up here and there, frequently around groups of people working with one another.

This phrase intrigues me because it’s one of the phrases you’ll hear across unrelated disciplines. Ray Dalio sets this as a target in Principles. Stephen Colbert has also used this phrase to describe the production of his show. I don’t remember hearing it about the Toyota production system, but I imagine it would also be used there.

The implied meaning—despite having so many different pieces, all of these systems come together to produce a result. In particular, things “click.” The elements you need are produced as you need them, and things are humming along.

This happens because the system, and its individual components, are operating on a shared tempo.

Software Engineering

This is the domain I’m most comfortable with, and tempo implicitly comes up all the time.

Feedback Loops

Especially in the context of devops, tempo is the concept behind feedback loops. The idea is that quicker feedback loops allow more rapid development and learning.

The biggest example of this is with code reviews. While I’m personally a huge offender, it makes a world of difference if you get back to a code review in an hour rather than a day.

Accelerate

In devops literature, the idea of tempo shows up in a number of other places as well. A big one is Accelerate, which has been gaining adoption over the past few years.

Accelerate presents four key metrics to use to determine the performance and health of a software team:

  1. Deployment Frequency
    How often your team(s) deploy your code to production.
  2. Lead Time For Changes
    How long it takes for a change to reach production.
  3. Mean Time To Resolution
    Given an issue, how long does it take to get things back to a stable state?
  4. Change Failure Rate
    What percentage of changes result in breakage?

Notably, three of these four metrics relate to time and tempo. They are about pace. The faster your tempo is for each of these things, the more likely it is that your software organization is running well.

Phoenix Project

Continuing with devops literature, a lesson of The Phoenix Project is that fires introduce unexpected work. Unexpected work kills your team’s ability to produce anything.

Unexpected work is a tempo-killer.

Business

Estimation

Everywhere in business, we want to be able to estimate things. How much time to complete a project? How much money will a new product bring in?

There are many factors to estimation, and tempo is one of them. We estimate how long a piece of our estimate will take, then we extrapolate that to get our full estimate. The assumption is things are operating at a regular, predictable cadence.

We also see tempo show up in methodologies. Agile is a big one here—we tackle a project sprint by sprint, where each sprint is on the order of a week or two.

It’s a continual process of doing some work, assessing progress, and then recalibrating for future work. Tempo.

You can go further as well—the daily stand-up is also a manifestation of tempo.

Overhead

Similar to unexpected work, overhead is also a tempo killer. Everyone knows this—it’s a common complaint that large businesses increasingly struggle to move fast.

Three common sources of overhead: communication, bureaucracy, and meetings.

Communication overhead happens when we have to be redundant in our communication to get everyone on the same page and moving in the same direction.

Bureaucracy frequently happens through process. While process can be good, it can also be bad when the process is arcane or inefficient. Formalizing a process multiplies the impact of that thing, and sometimes that impact is operational overhead.

Meetings are a combination of both communication and bureaucracy. They have their value, but poorly-run meetings are a waste of time.

Onboarding

You can think of onboarding as ramping up someone’s tempo.

A new hire knows almost nothing about operating in your company. You start them off on a slow tempo, with minimal tasks. As they pick up each one, you introduce more and pick up the pace.

Habits

Habits are also a form of tempo. Whether it’s good or bad, it’s a recurring behavior with some kind of predictable trigger.

Continuing this analogy, creating or breaking a habit involves your ability to establish or disrupt tempo.

Utilizing Tempo

Okay, there are tons of examples that involve tempo (even loosely). What are the important things to control with tempo?

My initial thoughts here: it is not important to set a specific tempo.

The important skill is to be able to shift tempos.

Set vs Shift

To expand on this, execution depends on your ability to shift tempo. Setting tempo (a.k.a. goal setting) is important, but it isn’t the main challenge if you want to be excellent.

To rephrase, setting a tempo tells people where to go. But it doesn’t necessarily expose the important things you need to go to get there. Shifting is the day-to-day, setting is the final result.

Shifting tempo requires a deep understanding of the things that are contributing or harming your tempo. You have to be able to identify them. Then you have to find ways to improve them.

Shifting Tempo

So, then, what are our tools to shift tempo?

In a nutshell, anything that allows us to sustainably and reliably increase/decrease the amount or rate of output will allow us to shift tempo. Note also that shifting tempo doesn’t always involve making things faster (although typically, this is what you want).

Pressure

First, an organization’s tempo does not change without some form of pressure. There must be some incentive to change. This comes from all sources.

It can be external—a business need or a mandate necessitates change. These tend to be most obvious and the most visible influencers on tempo.

Ideally, a lot of the changes comes from internal sources as well. This is where individuals and teams hold themselves to higher standards. They perform tempo-changing work because they understand how it improves tempo in the long term.

Eyes, Hands, Brain

Anyone who has ever run a team understands that the team members are your eyes and hands. You rely on them to see issues and fix problems.

A significant part of tempo shifts involve your team member’s ability to do this. If they can’t identify or can’t execute, issues remain undiscovered or unsolved. This creates a false sense of tempo, which is popped when the issue surfaces.

A key addition, for tempo, is having team members make decisions as well. Your team always has the opportunity to decide and act faster than you. They’re on the ground; you’re not.

This doesn’t happen automatically. In order for them to be able to make these decisions, they must know what the objective is. If they understand the objective, they have the basis to make decisions when obstacles come up. The ideal outcome is that your team is able to thoroughly address obstacles on their own.1

Team members aren’t just the eyes and hands. They’re also part of the brain.

This isn’t to say that others aren’t involved with decisions. It just means the team must be included too.

Sustainability

There’s always a pull for tempo to settle where it’s most comfortable. A sleepy coffee shop is not going to crank out cappuccinos. They don’t have to.

Additionally, operating at an unsustainable tempo will create burnout and ill-will.

So, tempo changes have to be done with an eye for sustainability. This includes intentional tempo increases, as well as unintentional slowdowns (such as added bureaucracy). The easiest way to make something sustainable is to minimize the human effort required for upkeep.

That’s all for now. While it will likely be some time before I can work this into a cohesive philosophy, I expect it to guide a lot of my future thinking. I hope, within a few years, I’ll be able to turn this into an operating guide of sorts.

  1. An important distinction: you don’t want to hear about problems because your team resolves problems independently, not because your team is hiding them from you. ↩︎