5 Recurring Laws You Should Know
5 Recurring Laws You Should Know
Gall's Law, Occam's Razor, Parkinson's Law, Conway's Law, and Pareto's Principle
My observations in tech have shown that these 5 laws present themselves in various, different situations and it helps to be aware of them. These are useful for creating mental models, observing our environment, and to communicate our thoughts more effectively. When thinking about how to map out our world and create a reference point to anchor on for various concepts, knowing these laws will help you and those you work with do that.
Who should read this? You are building products, managing programs and projects, working in a cross-functional organization, are a founder, are in a leadership position, an engineering manager, a product manager, TPM, CTO, or architect.
#1: Gall’s Law
What it is
Gall’s law states “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system. “
When to use it
This is the most effective way to build products and pretty much anything. Build a simple system first, and improve it over time. Don’t overbuild, build to spec to match the requirements you are trying to fulfill now. A simple solution is preferred over a complex one.
For example, if you are just starting on the path to continuous integration and continuous delivery, you do not want to build out your entire rube goldberg machine to fulfill future requirements that solve problems you don’t have yet. Start with the most basic capability like building an artifact from source control, then introduce additional complexity as your requirements dictate.
This doesn’t mean you shouldn’t consider the future, you absolutely should and what your next moves will be. However, customers, markets, and worlds will change and you don’t want to build for a problem you don’t have yet.
#2: Occam’s Razor
What it is
Occam’s razor states: “Entities should not be multiplied beyond necessity” and paraphrased as “the simplest explanation is usually the best one”. This is the classic “Keep it simple stupid” (KISS) principle.
When to use it
When deciding on something or introducing solving a problem, the simplest solution is usually the best one. Don’t overcomplicate and over-engineer what you’re doing and fall victim to analysis paralysis. Pick the simplest solution and run with it.
This ties in closely with Gall’s law above where Gall’s law is stating to match the complexity of the solution with the complexity of the requirements and Occam’s Razor is focused on decisions. Use data to determine what the simplest solution is, eliminate assumptions, and execute it. Test and retest your assumptions throughout the execution process, iterate, and adapt as needed.
#3: Parkinson’s Law
What it is
Parkinson’s Law states the time required to perform a task tends to extend to all the time available to perform it. Its name comes from the man who invented it: Cyril Parkinson.
When to use it
This is a common anti-pattern observed during estimating and leads to overestimating. When given more time than needed, that time will be filled with things like “gold plating” that aren’t necessary to deliver the feature. This doesn’t mean estimating as low as possible and incurring technical debt, but it does mean making estimations lean enough to avoid Parkinson’s Law.
For example, if you are a product manager or engineering manager, you are familiar with the idea of “pointing”. A story point generally represents a “person day” of work give or take a few hours and includes buffer time. Instead of arbitrarily giving buffer time and bloating estimates leading to Parkinson’s law, seek to give engineers and developers confidence by:
Minimizing uncertainty
Eliminating confusion
Using a “Modified” Fibonacci for estimating user stories and tasks is one way to help do this. Avoid being too precise and aim for accuracy when estimating. Estimating doesn’t need to be perfect, just accurate. Provide a high and low estimate, and meet somewhere in the middle.
#4: Conway’s Law
What it is
Conway’s law states that “organizations will design systems that copy their communication structure.” E.S. Raymond stated it this way when referring to software engineering: The rule that organization of the software and the organization of the software team will be congruent; originally stated as ‘If you have four groups working on a compiler, you’ll get a 4-pass compiler’.”
When to use it
This is often seen when an organization pushes into too many silos to deliver “products” when there is a “platform” at play. This is commonly seen in hyperscaler cloud providers where teams are aligned vertically to “products”, however, customers use them together in the form of a solution. The implication of this is that sometimes your “platform” can come off looking like a leaky abstraction.
The natural implication here is that if you want your customers to view you as a platform, then organize it as such. If you want your customers to view your products individually and stand alone, then vertical silos may be required. Either way, there are trade-offs in how you manage cross-functional communications, product launches, go-to-market, sales, support, and marketing. This is the common push-pull I’ve observed in companies trying to get the best of both worlds:
Vertical organization (e.g. hyperscaler clouds): Faster time to market, autonomy, lacks economies of scale and integration into a platform, the field is required to unify the products into a platform for customers, team empowerment
Layered, integrated organization: Slower time to market, releases in lockstep, better economies of scale, communications, common thread from product to field to customer, and stronger unification in go-to-market
The bottom line is that if you want to present a unified platform to customers, you must change your organization to match your platform vision or suffer from the inefficiencies of cross-functional coordination and risk fragmentation of your products.
#5: Pareto Principle
What it is
Pareto’s principle states that for many outcomes, roughly 80% of consequences come from 20% of causes (the "vital few"). More commonly known as the 80/20 rule.
When to use it
I most recently saw the usage of the 80/20 rule in regard to ARR. 80% of the ARR comes from 20% of the customers. This is a good way to describe your longtail customers as the ones accounting for 20% of revenue. This varies per company, but it is relatively true, especially in enterprise SaaS products. This is a good rule of thumb to apply to a Minimum Viable Product (MVP). You can fulfill 80% of the users’ requirements with just 20% of the functionality.
There are variations of this everywhere. For example, Google has the 70/20/10 rule1. This was a principle that everyone should spend 70% of their time on their core job, 20% as part of another team, and 10% on something blue sky.
Use the 80/20 rule as a heuristic to gauge where you should prioritize and apply your effort. When you understand what your 20% is to get 80% of the benefits, you can focus your efforts on executing that 20% and making it great.
My Ask
Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!
Like this article by using the ♥︎ button at the top or bottom of this page.
Share this article with others.
Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it
https://www.forbes.com/sites/quentinhardy/2011/07/16/googles-innovation-and-everyones