Managing Inertia

In Simon Wardley’s business strategy methodology, Wardley Maps, there are a class of behaviors you can take in all contexts to improve your ability to act strategically and improve your chances of success. These are called doctrine, universal rules that one should use across contexts. By analogy, in war, you have a doctrine to train your soldiers to shoot before you go into battle or in chess, you should learn the moves of the pieces before playing your grandfather. Doctrine isn’t a sliver bullet but it is guiding principles broadly applicable to multiple situations.

These doctrine are applicable to certain broad categories of activities you might take: Communication, Development, Operation, Learning, Leading and Structure. One of the key ones in Operation that intrigues me is Manage Inertia. This applies to the broad category of operating the business, of doing the day to day things that allows progress to be made on a variety of fronts. A formal definition of inertia is the resistance of any physical object to a change in its velocity. In business, the physical object takes on other definitions and could be a team, a process, a piece of software, or any number of other constructs. The fact that inertia exists in your business is A Good Thing. It’s a sign of success because without past success, continuing to do the same thing would be pointless. It is the fact that inertia rises out of past successes that creates a paradox and the need to deal with it. Much like your brokerage telling you that past success is no guarantee of future performance, Tesla notwithstanding, business success in the past must be often disregarded so that change can happen and the business can evolve.

Inertia in business manifests in particular ways. Organizational units that have achieved success in the past will be unwilling to try new things or learn new processes. Software that has become successful will over time become ossified as more features are added to it in its current structure, cementing design decisions into place. Processes like Scrum or Six Sigma fix initial problems and then are never revisited for examination. The paradox here is that the business landscape is always changing. Businesses must adapt in order to have continued success but they have tendencies to stay the same. This is how the brash startup can disrupt an established player in a vertical. The startup lacks the inertia of the established that acts on every part of the business to keep it from changing for its own good.

Often, certain elements within an organization will, consciously or not, chafe against the inertia and push to make radical changes. In the software landscape, this is often expressed as rewriting some piece of the business’ software after a period of time because technology has moved on and improved. In the best case, this often is a push out of the development teams who see improvements to technology and methodologies and want to do things better. In the worst case, it can be a lack of good business strategy that allows a rogue element to begin a project without guidance or a clear road map. Typically, it’s a little of both.

These rewrites can in fact be successful. With enough engineering firepower and good leadership that focuses on business value and quick wins, rewrites can be done in a way that leads to a rapid evolution of the existing software. However, more often than not, none of that is true. The business focuses engineering talent elsewhere leaving the rewrite understaffed. Management, somewhat out of touch with the landscape as well as the day to day activities, prefers to just sort of hope things will turn out ok. Hard decisions are avoided. The organizational inertia towards the success of the past weighs heavily. This inertia is far more powerful than the average engineer or engineering manager understands.

Other organizational units that interact with the working system have developed rules and processes for that interaction. Over time, through the success of the software, they themselves have become successful which leads to inertia from a different quarter. The marketing team has learned to use the software for its benefits. The business insights group has learned how to get data out and into the hands of stakeholders in a reliable manner. The business executives understand the vocabulary and the predictability of working software. All these sources of inertia work against a rewrite and must be managed thoughtfully and strategically or else the project is doomed.

So we have a paradox. The business must change in order to adapt to an evolving landscape. But the business must not change because what they are doing is successful. Navigating this landscape takes planning and must be done constantly as maintenance on existing systems, no differently than the oil must be changed in the car. Managing this inertia, while a general doctrine, involves critical thought applied to a particular context. There is no silver bullet. Perhaps you can reclaim your software. Perhaps a rewrite is the best plan. But if so, all the sources of inertia that act on the organization must be taken into account and mitigated. You cannot suddenly change a significant chunk in a successful business. The business reached a stable state through time and evolution and a sudden rupture in that stability will rarely succeed.

This management of inertia involves consensus and partnership across organizational units. The irony of course is that the drive for change often arises because one organizational unit has grown tired of the existing inertia and seeks to overcome it by moving alone. However, in a successful business, there is no alone. All units are connected, however tenuously, and the smaller the business, the stronger the bonds between units. So these moments of punctuated equilibrium where a unit thinks they can rapidly change something that the entire business relies on are largely doomed to failure. Conway’s Law cannot be ignored.

How then can we ensure inertia won’t kill us over time? Good strategy goes a long way. By analyzing the issue and developing policies that guide teams’ actions, inertia can be used against itself as small successes help teams develop confidence in their ability to manage change in the organization. A policy that says “we will always be on a framework version within one major version of the current accepted version” will guide teams actions in their planning process and insure that improvements in technology work their way through your system. A policy of “As a team, we will spend one week a year exploring the landscape of our current technology stack” will help sharpen skills and invites broad participation. Policies are critical to guide behaviors and actions. Without them, there can be no consensus on how to move forward.

Overall, the management of inertia is a function of good management. This seems trite but is critical. By defining strategies and policies that guide actions across an organization and then enforcing these policies over time, inertia can be prevented from becoming ossification. Without this management over time, software will grow in size and complexity to a point where changing it becomes perilous and rumblings of replacement will grow louder. It is unlikely at this point that excellent management will suddenly leap out of the fire to guide a difficult project to success. As in health, it is always more advisable to take small steps over time rather than have heart surgery as a strategy. Managing inertia must be consistent and well-guided to allow the business to evolve as circumstances warrant.