Why engineers need to be bored.

An analysis on boredom in engineering productivity and how it can lead to deeper innovation.

There’s a mantra that people in software engineering love:

80% of the work is done by 20% of the people.

Ironically, often, people will group themselves within the minority of workers (“of course I’m one of the high output people doing most of the work!”)

But whether we’re talking about individual engineering teams, bigger organizations, or broadly across entire companies, people will find that there are small, tactical, high performer groups doing giant chunks of the meaningful work.

Another one you might hear in DevOps or IT circles is:

80% of our problems are caused by 20% of the changes.

Again, often, people would lump their own changes with the ones that don’t result in problems (“of course my features don’t cause issues, they’re rock solid!”)

And again, whether we’re talking about individual contributions or massive companies, you will find that there are usually a small subsets of changes that notoriously cause massive problems.

The origin of this catchy idea comes from the Pareto principle:

80% of consequences come from 20% of causes

or, in other-words, the majority of results come from a minority of effects. There are big consequences (both good and bad) to small things. And this has been observed across socio-economics, micro-economics, and macro-economics (in all of the different economic sectors).

Let’s take a look at a few examples.

In 2009, within the droves of the American healthcare reform, Myrl Weinberg found that some 80 percent of healthcare costs are incurred by 20% of the population. I.e. the majority of the massive amounts of money being spent on healthcare in the United States is actually only coming from a small minority of people with chronic conditions.

The Agency for Healthcare Research and Quality says that 20 percent of the population incurs 80 percent of total health-care expenses. We also know that this segment is made up of people with chronic conditions.

Another good example is Amazon Web Services.

In the early 2000s, as the story goes, Amazon found itself in a technology and IT rats nest. With massive dependencies on third party vendors, very short windows for pushing changes into production, dependency deadlocks across teams, and little planning for how to scale their online business, Amazon needed a way to decouple everything from within: Amazon Web Services was born. Using an API driven methodology, teams began to move faster by consuming services from within. CEO of Amazon and previous leader of AWS, Andy Jassy said:

We expected all the teams internally from that point on to build in a decoupled, API-access fashion, and then all of the internal teams inside of Amazon expected to be able to consume their peer internal development team services in that way. So very quietly around 2000, we became a services company with really no fanfare

Over time, the innovation and creation of AWS within Amazon by a small group of engineers and product leaders would become the central product of the entire company. In 2021, AWS make up some 74% (nearly 80%) of Amazon’s total operating profit. And that number is expected to continue to climb.

One question you may be asking yourself is “What’s the point of the small minority then? For example, if 80% of the work is done by 20% of the people, shouldn’t we just trim the fat and get rid of the people only doing 20% of work?”

And while an interesting thought, you need to keep in mind that this is a constant balanced principle.

If you did attempt to get the minority of workers doing the majority of work to actually just do 100% of it, those workers would inevitably slid back into the balanced mold of the principle. You would find yourself with a skeleton crew where even fewer people are doing the majority of the work and a few of your previous high performers have slid into the lower 20%. Instead, it’s important that the system surrounding this balance change and adapt to lift the tide of both the majority and the minority.

For example, looking deeper at the discussion on healthcare reform in the United States, addressing the needs of the minority will inevitably also addresses the needs of the majority:

If we can create a system that provides for and appropriately addresses the unique needs of the 20 percent of the population who are driving the health-care dollars spent in America, we’re 80 percent of the way toward a health-care solution for all.

And in the example of Amazon web services, it would be a massive mistake to cut out all the other businesses that don’t bring in large portions of the operating profit: those smaller departments and businesses all run on AWS and enable the platform as a whole to get better through surfacing early issues, trying beta features internally, and so on. Or as some like to say, the other Amazon business units “Drink their own champagne” and everyone’s life gets better.

---

Today, I’d like to propose a new principle: The Pareto principle of Boredom

80% of innovation comes from being bored 20% of the time

Engineering teams and innovators are peculiar anomalies. They can produce amazing output, but when pushed too far, you can extinguish the bright flame of innovation that many entrepreneurs and enthusiasts spend their whole life chasing.

It’s extremely important that boredom is built into the logistics of daily work. Which can be nearly impossible today with our constant inundation from notifications, “productivity” instant messaging solutions, on call alerts, customer questions, so on and so forth.

We live in a hyper connected world, but often times, all you need to cultivate some invention and creativity is a little boredom in your day:

boredom motivates pursuit of new goals when the previous goal is no longer beneficial. Exploring alternate goals and experiences allows the attainment of goals that might be missed if people fail to reengage. Similar to other discrete emotions, we propose that boredom has specific and unique impacts on behavior, cognition, experience and physiology.

And what are those impacts?

it has been suggested that boredom can increase creativity … despite the fact that folk ideas often consider boredom and creativity to be opposites ... In support of this claim, one study found that, when asked about the subjective positive outcomes of boredom, some participants listed increased creativity

To some in the tech industry, this may be obvious: if you are constantly pushing your engineers for increased productivity, the really important innovations around automation, experiments, and research won’t ever happen. Or said more plainly, your team will never automate the boring stuff.

You often see this on teams that have failed to adequately automated the most boring tasks (like releases and testing). Instead of doing the really fun, sexy innovative work that everyone wants to be doing, those teams are stuck spending huge swaths of time doing manual testing and hand crafting releases (that all should have been done through a pipeline).

There are a few questions you can ask yourself as an engineering leader:

• “Am I pushing productivity beyond the sweet spot of The Pareto principle of Boredom?”

• “How can I encourage my team to spend 20% of their time innovating and doing what excites them in free-form-boredom time?”

• “Is my team spending 100% of it’s output on tasks that have to get done?”

Boredom is the easiest and cheapest way you can start to breed innovation on an engineering team. By simply reducing the “true” workload from 100% down to 80%, you’ll start to find that in the newly created 20% of free-form-boredom time, engineers will get curious and creative. They’ll start spinning the flywheel of innovation and create unique solutions to existing problems on the team. And, as that flywheel spins, the speed of innovation and creativity will pick up. You may even find an entirely new and interesting product on your hands.