Through the Stack 2-08 (Week 13)

This is "Through the Stack," a weekly focus on a topic and links relevant to Lead developers (actual or aspiring) working with an internet-related product.

Many lead developers, tech lead, and staff engineers have their hands in many projects and influence many layers in their organizations. As such, they work Through the Stack: from Strategy, through Operational to Tactical work. This newsletter reflects those dimensions.
If you have comments or content to suggest, please reach out to us by email.

This week ...

We focus on one big topic: the Pareto principle. Often unknown or overlooked, I think it's an interesting concept to keep in mind as CTO and here as an engineer in general.

Nuggets that kept me thinking

Yet, before covering the main topic, I want to refer to a few links and content I spotted in my feeds that kept me thinking.

• This thread on Twitter: got me thinking about how many don't know what they don't know or prefer to have someone clarify the fog of war and help them along the way.
• @peregrine on Twitter shared a post from Fly.io on how to use Elixir to build a static site engine: an interesting topic and a great practical case to learn Elixir too.
• Ben Yoskovitz in his Focused Chaos Newsletter: "Cold investor outreach is an Increasingly Viable Way to Raise Capital".
• This post on AlloyDB and what it means for customers willing to migrate from PostgreSQL (OpenSource, with a large developer community).
• This drop-in replacement for Redis and Memcache: Dragonfly.
• "Numbers to know for Managing (Software Teams)" from Stay SaaSy: I'd say it's "food for thought" mostly but interesting to ponder.
• From 2020 but still, a good read, especially related to our recent review of It's your ship and our post on pedagogy and organizational cultures: Pull The Andon Cord.

On the Pareto principle

With such a topic, let's start with a quote from Wikipedia:

The Pareto principle states that for many outcomes, roughly 80% of consequences come from 20% of causes (the "vital few"). Other names for this principle are the 80/20 rule, the law of the vital few, or the principle of factor sparsity. – Wikipedia

In other words:

The Pareto principle, also known as the 80/20 rule, states that roughly 80% of effects come from 20% of causes.

That sounds a bit difficult to grasp, in my opinion. Let's add two concrete examples.

It is an adage of business management that "80% of sales come from 20% of clients. – Wikipedia

But how does that apply to us in the software engineering world?

Let's work on this definition a bit

This reflection comes from reading Arvid Kahl's book: Zero to Sold. In one part, A. Kahl refers to the Pareto principle as an argument to founders to prevent them from looking for perfection in what they are building.

His argument is (summarized): do 80% of the features because that'll be enough to validate your idea and will take a lot less time than trying to reach 100%.

This points out the other side of the coin in this principle: if 80% of the result (the product) comes from 20% of the work, the remaining 20% will cost us 80% of the work. While the first part of the principle tells you, "look how fast you can get something that largely fits the bill", the second part tells you, "look how much more time it'd take you to finish it".

And, of course, this is iterative: from the remaining 20%, 80% of those will take 20% of the time needed to do the rest. So if you find that the feature is something the customers want, you can add up a bit more work to try to improve it, and so on.

Three key takeaways

After some years, as I keep hearing about it and reflecting on it, I've found the principle to help prioritize, cutting any temptation to let a scope creep and decision paralysis.

Here are three takeaways that can be useful to software engineers and leaders:

1. Help with focus and prioritization: when deciding which features to prioritize, engineers can use the Pareto principle to identify the 20% of features that will deliver 80% of the value to users. Focusing on these key features first can deliver the most impact with the least effort.
2. Avoid scope creep or over-engineering: for example, engineers can ask themselves whether adding extra functionality or optimizing code beyond a certain point will deliver significant value or whether it's better to stop at a certain point and move on to the next task.
3. Cutting through decision paralysis: based on those previous two, engineers can use the Pareto principle to determine which choice is likely to produce the most out of the less effort. This will help break any decision or analysis paralysis.

Overall, the Pareto principle can help software engineers make more informed decisions about what to do and how far to go when implementing a feature, allowing them to deliver the most impact with the least effort.

Helping along the broader picture

As pointed out in previous posts (such as Failure Factory), there is a need to have clear objectives to organize our work and efforts. Having a clear North Star and OKRs (or something equivalent) will help tremendously when using the Pareto principle in any of the three takeaways previously listed.

1. Identifying what has the most value for users: this can only be seen if there are OKRs and a North Star. Without an idea of the product's aim and how, at the moment, we are directing our efforts to go there, it will be challenging to identify what has the most value for users.
2. Keeping the scope reasonable: similarly, we want to keep the scope of a feature in line with our objectives and key results. The questions to ask ourselves would be, "is the work we have done until now enough to match our key results?" and "is it reasonable to invest more time now to move even further?".
3. Busting out of decision paralysis: again, if we can compare the amount of effort needed for two projects and relate that to OKRs, we can more easily cut the Gordian Knot.

To conclude

Years ago, I had trouble seeing how the 80/20 ratio could be used for my work. But nowadays, I can see how it can be an excellent companion to many work decisions.

Even if you don't have a clear North Star and OKRs for your team or organization, the Pareto principle can give you quick help to move forward and reap most benefits faster than if you stay stuck in analysis paralysis, scope creep, or temptation for a shiny object.

On the Strategic level, here are two questions to ask yourself:

1. What are the top 20% of product features that will deliver 80% of the value to our users?
2. Who are the top 20% of customers who generate 80% of our revenue? How can we ensure to serve them better and attract more of them?

On the Operational level, here are two questions to ask yourself and review your priorities:

1. What are the top 20% of technical debt causing 80% of our issues?
2. What are the top 20% of bugs causing 80% of user issues?

On the Tactical level, here are two questions to as yourself:

1. What top 20% of tasks will deliver 80% of the value in the current iteration?
2. What are the top 20% of areas in our codebase causing 80% of the issues in code reviews?

Who are we, by the way?

This content is written and published by Imfiny/Pier22, a consulting company based in France. We help CTOs, and Tech Leads grow their engineering team and stack.