U.S. Army, Army 10-Miler - 2010 - AUSA - FMWRC - United States Army - 101024, https://flic.kr/p/8MPazf
Tempo. Most people are familiar with it in the musical sense. It’s the speed, cadence, rhythm that the music is played. It drives the music forward - and pulls it back.
But there’s more to tempo than a musical beat. In life, as author Venkatesh Rao described in his book, “Tempo,” it makes for some of the most memorable moments as it shifts faster or slower. In war, like in business, tempo - the speed at which you can transition from one task to the next - is a critical component for victory.
In the words of United States Air Force Colonel John Boyd, when you consistently operate at a faster tempo than your enemies, you create fear, instability, demoralization and chaos.
When a fighter pilot constantly gains tactical advantage, the enemy is forced into a perpetual reactive mode, forced to follow every move. In business, in some cases, there’s an advantage to be the first mover. When a company launches a new product first, the competition is in a similar reactive mode, and starts looking over their shoulder instead of looking ahead. The first mover didn’t have the idea first, but they were able to act faster than the competition.
Being able to get a product into the market first, however, doesn’t always mean you’re the faster company. If it takes you two years to get from 1.0 to 1.1, but your competitor is up to version 5 of their product, it’s likely your competitor will come out on top.
Think back to cycle time, which I covered in post 12 - The New Normal: Mean Time to Reaction. Cycle time is about conducting the same activities and shortening the time needed to go "all the way around the loop." Tempo is about switching from one kind of activity to another, and how often you are able to do that. It’s the speed at which the company moves between sensing the need for a new product and actually makes it happen.
No single person nor department owns tempo. Somebody can’t just shout, “I now control the tempo,” and take charge. If you operate at a faster tempo than your cycle time allows, then you’ll get thrashing. The rate of tempo emerges organically as companies move around that action loop of sensing, deciding and acting.
Companies that properly structure both the combined system of people and technology, which I jokingly call carbon-based and silicon-based components, have the greatest opportunity for a fast tempo. They can react to changes in the market and proactively change the market itself.
You’ll never achieve a very fast tempo by remaining a member of the Brontosaurus Club, which I described in post 5 - The New Normal: Protected Asset or Disposable Inventory. Those behemoths rely on outsourced software development and use languages and tools that call for monolithic architectures. Lugging around gold-plated anchors will never allow them to rise to the top.
They aren’t winning. They won’t win.
Just look at Amazon’s move into the cloud-computing space. A decade ago, Amazon, operating at a much higher tempo than its competitors, won the cloud space before the co-location and managed hosting companies could react. In fact, Amazon could even pick new enemies and beat them before the opponents even knew they were in competition.
Many of the other concepts I’ve covered in previous posts move organizations to the same outcome - a faster tempo.
Amazon is winning thanks, in part, to internal processes that allow for team scale autonomy. A smaller team, the so-called “two pizza team,” says Amazon founder and CEO Jeff Bezos, gets jobs done more quickly without the noise of extra dependencies. You can read more in post 9 - The New Normal: Team Scale Autonomy.
Evolutionary architecture is one. Consider a private equity company I’ve worked with. The firm has about 40 different trading desks that go after different strategies and markets. Each one has a development team building the applications that they use to trade.
A big centralized system - common for most other companies - isn’t practical here. Anything any group did to the system would risk harming all of the other groups, resulting in large failure domains. It would require a slow release cycle because you couldn’t deploy it all immediately, which would force a stop in trading. Releases would have to trickle out each night.
Instead, the firm’s trading apps are very small and focused. They are built by a team that’s usually sitting right next to their users. When they need to make a change, the turnaround time is quick - about five minutes. The failure domains are very small. If they make a mistake, all of the other desks are still trading.
The safety built into the system allows each of the desks to operate quickly. That’s not by accident. It’s deliberate. And you have to work to maintain evolutionary architecture because the natural tendency of software systems is to grow more and more coupling between them, like synapses between neurons.
Evolutionary architecture isn’t the only requirement for a speedy tempo.
Continuous delivery, the ability to enact changes quickly at low risk to the firm and its users, is another. Disposable code allows you to change direction quickly.
As I wrote in post 3 - The New Normal: No Silver Bullet, agile and Lean development also push the tempo faster. They encourage fast and flexible response to change, but they aren’t the complete solution. With Lean, users also need to be careful that they don’t over-specialize their current value streams at the expense of their ability to change them or create new ones.
All of these systems in place have something in common. They help set a faster tempo, but you can’t pick and choose your poisons. You can’t speed up tempo by just doing one of these things in isolation. You have to do all of them a little bit at a time and incrementally. It’s vital to resist the temptation to fall back into familiar and comfortable habits of mind and organization. And, be wary of senior-level staffers coming in from traditional organizations. They’ll perceive this system as chaotic and unmanageable.
If you start taking your existing IT organizational structure and applications and just start doing continuous delivery, you will fail. Horribly. Same goes for agile development or team scale autonomy. If you have large failure domains, team scale autonomy isn’t possible.
Anticipate and embrace failure - It is going to happen. Unplanned services outages or even just a bad flu season are going to hit your organization. Stop bracing for it and start embracing it.
Aim for Antifragility - Resilient architectures are no longer enough. Success in a resilient paradigm means that the system is highly stable. But when it does break, nobody knows how to fix it. By comparison antifragile loves uncertainty and risk. If it breaks, how to fix it is a known operation. If it breaks a lot you create systems that fix it automatically.
No Silver Bullet - Agile development can be effective at the team level and still not contribute to antifragility. Antifragility must be a property of the organization as a whole. Agile is necessary but not sufficient. Lean is good, but too much of it will make you fragile. Neither of them offers tools to make the organization more capable of withstanding failure— becoming antifragile. They are simply pieces of the puzzle at the micro scale.
Minimize Risk by Maximizing Change - Build safety into the architecture and the organization. Look for tools, platforms, and patterns of interaction that allow independently varying components to be deployed at any time. Microservices are one approach, but not the only one.
Disposable Code Inventory - Code is a liability. A risk. If you fear your code it is time to move out of the dinosaur age and move towards adaptive systems, where small inventory and disposable code allow us to change direction swiftly.
Embracing Failure - Expect failure. Plan for it. Inject it. Your organization must adapt and find ways to continue when any given person at any given time could be gone for a few days. Architect your organization and infrastructure to minimize the impact of bugs and personnel. Strive for an infrastructure that makes it safe to fail through small failure domains.
Evolutionary Design - Microservices development follows an evolutionary model. They are not designed from on high or in isolation. They grow and change, with new services splitting off from ones that already work. Easy-to-use services with useful features will get used more frequently. Those that are hard to use or uninteresting attract few users. Services that gain users survive, while services with few or no users should die. If you design a service that can never be replaced, then you’ve failed.
The Right Tools - Choose the tools that allow concise expression of ideas, the composition of multiple ideas for higher leverage, that make the general solution easier than a specific special case, flatten data and metadata into a common level, and let you treat code as disposable inventory, reducing risk and inertia.
Team Scale Autonomy - Eliminate dependencies between systems, components and teams so each team can move quickly within a small failure domain. A team structure with enough autonomy that people can move at different speeds at different times.
Data Leverage - The New Paradigm: Data Orientation. The whole approach of OOP - writing and annotating classes rather than simply working with the data as data - introduces fragility into the system. In contrast, working with data as pure data streamlines development and enables change. Data orientation powers the new, maneuverable microservices architectures.
Failure Domains and Safety - When failure domains are large and overlapping, you will not sustain team-scale autonomy. When the system does not provide safety, you will not sustain team-scale autonomy. Put the two factors together and you get an exponential increase in the cost of an incident. Therefore, if team-scale autonomy is desirable, you must work to make the failure domains as small and independent as possible. This is not a one-time transformation effort. It requires ongoing work.
Mean Time to Reaction - The ability to react to the environment - whether a competitive threat, or to become a disruptive competitive threat to others - requires both micro level and macro level considerations. At the micro level you have team scale autonomy and an antifragile infrastructure. At the macro level you have an organizational structure and philosophy that mitigates political infighting and languishing budgetary cycles. In this way you can integrate IT and business and use change as a weapon against competitors.
Tempo and Maneuverability - The culmination of each of the previous sections is an antifragile infrastructure, autonomous high-velocity teams, and an organization that is attentive and responsive to changes in the market. A company that operates at a higher tempo than the competition and can change direction faster to take advantage of opportunities and mitigate risks.
You must do it all, all of the time, but it’s OK to start small. Start integrating each of these strategies slowly and keep doing it.
At first glance, this may seem like an overwhelming list of traits, requiring an unrealistic amount of change. This kind of change can begin at the team level. It doesn’t take a complete wholesale shift across an entire company to begin making changes.
If you remember that we tend to overestimate change in the short term and underestimate in the long term, a new normal is possible.
Read all of Michael Nygard's The New Normal series here.