In graduate school I took a software engineering class which was essentially a colloquium. The professor would select relevant topics, provide suggested reading materials, and then the class would meet to discuss. Through the semester long class a broad range of software engineering topics were discussed, but one topic has come back to mind many times through my professional career.
As I remember it, we discussed the conservation of organizational momentum. However, I cannot find any material which references this topic. The fourth of Lehman’s laws covers the conservation of organizational stability, which is semantically similar yet conceptually different. Perhaps through discussion our class conceived of the conservation of organizational momentum, or perhaps I am simply misremembering. Regardless of how I came to think of this subject, it is a topic which I have considered on more than one occasion, and it is a topic which deserves further consideration.
Lehman’s fourth laws states that the average effective global activity rate in an evolving system is invariant over the product’s lifetime. This is essentially stating that the time it takes to add a new feature to an evolving software product is consistent throughout the product’s life. It is worth noting that this law is meant to apply to applications which evolve to solve real-world problems, not programs with mathematically fixed specifications or other hard theoretical limits. And, this concept makes sense. The time it takes to deliver a product feature will be dependent upon the processes used to deliver the project. And, processes which work tend to remain in effect.
Stable organizations probably don’t just produce predictable software results. The processes and habits that inform the rate of software delivery likely inform other aspects of the organization. What is the culture of an organization other than the collections of processes and habits that the organization uses to deliver its goods and services.
Lehman was implicitly describing an organization which primarily delivers software. His laws were envisioned at a time when software was still made by highly trained specialist who were largely segregated from other areas of the business. In the almost half a century since his laws were envisioned software has blanketed the world, and thus the majority of businesses. And, what happens to company’s software when its culture is informed by the non-software producing lines of business?
It seems reasonable to assume that the practices which inform an organization’s culture are the practices which have made the business successful in the market. An organization is going to keep doing what works, and the judge of what works for a company is its market share or profitability. So a business will continue doing the things which make it succeed, and if the business is not a software business, then they things that make it succeed are not necessarily the things that make software projects succeed.
The first idea behind the conservation of organization momentum is that the practices, processes, habits, or culture that has made a business succeed in the past are the things that it will rely on to succeed in the future. The second idea is that the lines of business which make the organization succeed will have a larger influence over company culture. When the company becomes large enough to need custom software to enforce its ways of doing business at scale, it will employ the tactics which have made it successful up to that point.
If those practices rhyme with software development best practices, then success will be easy. But, as is often the case, the software development team may need to follow a set of best practices which diverge from company culture. This is why it makes sense for non-software producing companies to buy small software companies when they want to bring software development in-house. They are not buying the company’s IP or the company’s people per se, they are buying a culture which has been proven to be able to ship software. The key in this scenario is that the purchasing company doesn’t attempt to force its way of doing business onto their new software department.
Even for pure software development companies, the conservation of organizational momentum can be a limiting factor. A team which is highly capable of creating gaming software is unlikely to have the culture to make it successful at creating software for medical devices. The culture of shipping quickly and fixing bugs latter is not what is desired for creating software which could be involved with life or death decisions.
I have consulted numerous companies who were struggling to continuously produce quality software. Regularly shipping working software is hard. Even a high performing software team can flounder if the culture around it is not supportive of software delivery. I have seen many cultural anti-patterns, but there are a few which pop up a lot.
There is “let’s just knock this small feature out now for a quick win.” This seems to happen frequently in organizations which succeed through quick action, such as sales or relationship driven operations. The first problem is that many features which seem small actually are not. But, the real problem is that requests like this tend not to get fully fleshed out. These features either take longer to complete than guestimated or they bring unintended consequences. Planning is a key part of software development, and organizations which do not rely heavily on tactical planning for their core business struggle with problems like this.
A related problem is “some VIP needs this feature ASAP.” This seems to happen more in organizations with a culture that relies heavily on deference to “superiors.” The problem is the same as above, planning is required to produce quality software. Requests like this can of course be pulled off on occasion. However, when these asks are cultural, the software team will not be able to keep pace. They will get burnt out sprinting towards random objectives and will not be able to implement required supporting technologies.
There are many other cultural anti-patterns, those are just a couple that I have seen very frequently. And, it’s important to note that this is not just a business-side problem. If the software leaders do not understand the culture of the business into which they must integrate, then they are unlikely to implement the correct systems for the business. Tech people really like to do what they know, it makes sense for their career. But, sometimes, the technology stack that they know is not right for the business. Organizations with quick-win or deference cultures are going to need software frameworks which support quick iteration. Of course there will be trade-offs, but the software organization more likely to be successful if it properly aligns to the business.
So, regardless of how I came to understand it, the concept of the conservation of organizational momentum is a real phenomenon. A key for success when leading software development efforts is appreciating this concept, understanding the culture of the business, then planning systems that will integrate accordingly. I have seen many people attempt to change the culture of organizations, some places hire consultants to perform agile transformations, and these seem to rarely succeed. I have also seen software leaders who attempt to simply ignore the organization and do their own thing, this also tends to fail. The real answer is recognizing organizational momentum exists, and then acting pragmatically.
Christopher
