Maximum Viable Weight (and Minimum Viable Lift)

If you have ever participated in software development projects in any way, you are familiar with the concept of legacy. Legacy is something you inherit from past generations of projects, team members, and organizational changes. But, importantly, it is not the inheritance that you’re glad to receive. Usually, we are talking about legacy code and infrastructure, but it is easy to extend the same principle to team structure, communication channels, or decision chains.

Most projects, teams, and companies have to deal with some amount of legacy if they have been around for more than a few months. I’m sure you can remember a time when you joined a team and started to wonder how any work could possibly get done with that amount of technical debt, recurring meetings, and bureaucratic red tape.

In this post, I am asking two questions:

• Why is there seemingly so much of it everywhere you look?
• Is there something we can do to reduce the negative effect of legacy in our teams and companies?

Let’s find out if I can answer them.

The legacy of Venice

The medieval Republic of Venice existed for over a thousand years. It is an incredibly long time for any organization to survive, especially in the highly competitive environment of European diplomacy and power struggles of that period. We might expect the political processes of such an obviously prosperous state to be streamlined, free of any unnecessary delays and complications. And of all processes, the election of the head of state, the Doge, should be the example of efficiency.

Between the 13th and 18th centuries, for 500 years, the election looked like this (quote from Wikipedia):

Thirty members of the Great Council, chosen by lot, were reduced by lot to nine; the nine chose forty and the forty were reduced by lot to twelve, who chose twenty-five. The twenty-five were reduced by lot to nine, and the nine elected forty-five. These forty-five were once more reduced by lot to eleven, and the eleven finally chose the forty-one who elected the Doge.

Amazing. Weekly Scrum rituals don’t look so bad now. Of course, there is a reason for this system. It evolved with time to be complicated and random to reduce the influence of powerful actors. The wealthy noble families of Venice tried to influence elections in their favor and establish control over the government. If any one family had been allowed that, it would have swayed the delicate balance of power and even put the state’s existence under threat.

Could Venice have removed this threat by getting rid of its powerful families? Not likely, because in every medieval state, the wealth concentrated in small groups of people who either were noble by birth or became noble by paying for the privilege. And the more successful the state was, the more wealth was available for the families.

Every large company encounters a similar problem. As the company grows, the middle management layer grows with it. Given enough time, the interests of managers become opposite to the interests of the company as a whole. While the company wants to reach revenue targets and acquire new markets, the managers work to get more budget, responsibility, and subordinates in their department. As a result, the bureaucratic complexity in the company grows.

In a way, the famous career driven development approach also fits this pattern. If a team of software developers is successful enough to attract ambitious engineers, they will likely start new projects using flashy new frameworks that look good on a CV. Then later, some of those frameworks fall out of fashion, and the CV-driven projects become a legacy for a new generation of developers.

Lift and weight

Let me try to formulate the pattern that we arrived at just now. Each team, company, or any group of people organized for a specific purpose shares one common trait. With time, this team invents beneficial practices and instruments, just enough to reach the declared goals. On the other hand, the team will accumulate enough convoluted rituals and outdated tools to almost prevent the group from reaching those goals. In this post, I will call the first “useful” group of practices and tools the organizational lift, and the second “harmful” group the organizational weight.

I want to make an important note here. I put the words “useful” and “harmful” in quotes to emphasize that there is nothing inherently good or bad about these properties. The organizational weight is not a product of malicious actors; it accumulates naturally with time. Any team and company consist of individuals with priorities and interests, which don’t always align with the main declared focus of the organization.

Osteological Paradox

In 1957 in northern Iraq, American archeologist Ralph Solecki was excavating the Shanidar cave when he discovered a skeleton of a Neanderthal man. This was the first of 9 Neanderthal remains that Solecki’s team would find in that cave, and this skeleton is now known as Shanidar 1. The bones displayed signs of severe trauma and disease. The man who left these remains had his skull fractured near his left eye; a blunt trauma likely damaged his brain so severely that he was limping on his right leg, his right arm had multiple fractures, and damage to his vertebrae caused partial loss of function of the right arm. However, all these injuries show signs of healing, and the man died long after he sustained - and survived them, at the age of 30 to 45. Besides that, he struggled with a degenerative disease, which resulted in partial hearing loss. Still, he lived to a very respectable age for his population.

In a 1992 article of the same name, Professor James W. Wood formulated the Osteological Paradox, which questions the conclusions scientists made when studying ancient humans’ remains. When archeologists found skeletons in good condition, untouched by healed trauma or disease, they concluded that the individual must have been healthy and fit. When scientists encountered remains such as Shanidar 1, they thought that those humans had been frail and prone to disease.

But the idea of Professor Wood (if I formulate it in my own words) was that the Shanidar 1 man had to be very strong and healthy indeed before his injuries happened. Otherwise, he would not have survived them. On the other hand, someone with a weak immune system, for example, might have died very young from the first serious illness, and this individual would have left a skeleton in basically pristine condition. If most of the remains that we find from some historical period show no healed trauma, this doesn’t mean that the population at that time had an easy life. On the contrary, they likely had a tough life, full of dangers and ruthless competition for resources.

We can apply the same way of thinking to companies, teams, projects, and even large codebases. Any organization that collects significant bureaucratic overhead and any codebase that generates large amounts of legacy code without becoming obsolete and disappearing must be doing something right. It obviously achieves important goals, otherwise it would not have supported all that weight. They have a powerful “immune system,” and it is worth spending time to understand where this power lies and how to help it grow.

Minimum Viable Lift

If a company has too little lift for its weight, it falls short of its targets and has to reorganize, downsize, or even disappear. We can speak of the Minimum Viable Lift, or a necessary set of practices and assets that let a company achieve its goals. What happens if the company has too much lift, more than this minimum? If lift helps the company fulfill its purpose, can there be too much of a good thing?

Just like the excess wealth that the Republic of Venice received for its trade made its way to the coffers of the noble families, the extra lift will only serve to accumulate organizational weight.

Now we are ready to answer the question posed at the beginning of this post: is there something we can do to reduce the negative effect of legacy in our teams and companies?

I believe that the answer is yes. There is a way to achieve this if we channel that extra lift to something helpful instead. We need to make this extra lift necessary for the organization’s survival.

A team that is set in its ways, where developers are bored and are mainly working on their CVs, will likely be energized and inspired by a new challenging project. A company where red tape stalls new development will find a way to reduce weight and execute faster when it encounters a new powerful competitor. The positive effect might be so pronounced that if this competitor did not exist, the leadership would do well to seek new challenges by expanding to new markets actively. If all else fails, they might even try to invent a worthy competitor!

So there it is, the main point for which I wrote this post. It can be hard to find a reason to improve and grow if you struggle with previous bad decisions or habits that weigh you down. I have found the only way that works: the motivation has to come from outside. As you challenge yourself little by little, every time with a bigger goal, you will have no choice but to find hidden reserves that will help you learn, grow and meet the mark.