Eponymous Laws

Some observations that might ring true

I’m a big fan of eponymous laws such as Conway’s law, that software reflects the organizational structure that produced it, named after Melving Conway, or Goodhart's law, when a measure becomes a target, it ceases to be a good measure, named after British economist Charles Goodhart. Seeking out my namesake, in economics there is Fisher’s equation and the Fisher effect, both of which deal with interest rates and inflation. In population genetics there is Fisher's fundamental theorem which states, "The rate of increase in fitness of any organism at any time is equal to its genetic variance in fitness at that time." In the spirit of eponymous laws, adages, theorems, and principles, here are a few of Fish’s observations. 

The more you deny, the more you implicate.

Years of troubleshooting outages have revealed a curious pattern. The more vehemently an engineer insists their recent code change isn't the culprit, the higher the chance it actually is. Let's dissect a typical scenario. You're jolted awake by a page about a site outage and scramble to the Slack channel. The incident commander inevitably asks, "What was the last change?" Often, after an awkward silence, an engineer pipes up, claiming their code, isolated to payments, couldn't possibly be responsible for a site-wide outage. This triggers my "uh-oh" meter. If they double down, emphasizing the limited scope of their change, my suspicion intensifies. By the third adamant denial, I'm practically certain we've found the culprit. Remarkably, in most cases, rolling back the "isolated" payments change magically resurrects the site. Turns out, there's often a hidden dependency that unexpectedly connects seemingly separate systems.

If you hire a skill, you will get more of that skill demonstrated

Here is another scenario that I have seen over and over again. If you hire a person in a particular discipline, you are going to get more of the output from that discipline, whether you need it or not. Let’s say you decide that your compensation plan (salaries, bonus, equity, etc.) is starting to get pretty complicated so you want some expertise. Logically, your next step is to open a requisition and eventually hire a compensation expert. This is great because you now have someone with real expertise in this space and can help sort out all the important details such as pay equity and targeted percentiles. While this is all helpful, don’t be surprised when there is a proposal to completely revamp your compensation plan. Nobody gets hired for a particular skill and then doesn’t want to demonstrate that skill. I have never seen someone get hired with expertise in a particular process and say, “this process is pretty good, let’s just maintain it.” No, we all have to change things in order to demonstrate our value.

Everyone thinks they can improve on others' works

Now, another version of this is not focused on demonstrating value but rather just disdain for work that isn’t our own. Many engineers, including myself, feel a need to rewrite code they inherit. This goes double for people editing documents. Everyone that reads a draft article, email, letter, etc. wants to change it. Sometimes it is to make it follow their logic and other times it is simply to put it into their voice. I was in a meeting the other week when someone proposed hiring a brand marketing firm to review the organization’s brand. Someone brilliantly spoke up and pointed out that if they did hire this firm, there is 100% chance they will want to change the brand. No marketer ever loved some other marketer’s work so much that they said to a potential client, “we can’t improve upon that.”

The complexity of a system increases with each new feature

This next one should be readily apparent to everyone who works in the technology field but I don’t think it has been stated outright. Software only gets more complex over time. As new features are added to a software system, its overall complexity grows, often exponentially. As new engineers are added to the team, they approach problems differently and increase the complexity of the overall code base. This growth in complexity can lead to increased difficulty in understanding, maintaining, and extending the system. Each new feature introduces new code paths, dependencies, and potential interactions with existing components. This increase in cyclomatic complexity can multiply the ways in which the system can fail or produce unexpected behavior. As features accumulate, so does the technical or product debt in terms of the additional effort needed to manage the complexity. There is no way around this increase, only ways to manage it, which requires a constant refactoring or paying down of debt, otherwise it can become overwhelming.

Change becomes harder as organizations grow

This last one, I’ve observed as I’ve watched organizations grow from nimble startup to lethargic, bureaucratic corporation. The larger an organization becomes, the more difficult it is to implement change. This inertia can be attributed to several factors, including established processes, cultural norms, and the sheer number of people who must adapt to new ways of working. As organizations grow, the complexity of communication and decision-making processes increases, making it harder to enact swift changes. This idea is perhaps the counterpart to Metcalf’s law which states that the value of a network is proportional to the square of the number of connected users or devices in the network. This idea that I’m proposing is that while the value of the organization increases so does the inertia to not change. 

These are just some fun observations that I’ve had over the years about technology and organizations. I like frameworks, principles, eponymous laws, and such because they help me organize my thoughts and make predictions about what is going to happen. Armed with those predictions, I am better prepared as a leader to guide teams through challenges. I’m sure you, dear reader, have at least one or two of these that you have noticed. Feel free to share them in the comments so we can all learn from your observations.