Anytime you’re making a list at work, rank it.

This idea came from my recent post:

Anytime you’re making a list at work, of anything, rank it. Tech debt? Security concerns? Feature requests? Rank them. Rank them so that you do the important ones first. Those are the only ones you probably will do.

— Jake Worth ⚛️🌲 (@jakeworth.com) Oct 16, 2025 at 12:11 PM

This is a nuanced argument; let me try and make it!

Why Ranking Beats Lists

Lists are good. But when execution matters, most lists are improved by ranking.

Consider a list of technical debt problems. Maybe you have three you can think of:

  • Lack of an autoformatter allows trivial style debates
  • Flaky test suite reduces trust in tests
  • Outdated libraries make code hard to extend

You make this list, call it “Tech Debt”, and try to fix each problem.

You might be able to guess what happens next: your team only fixes one of these problems, or two, but not three.

Why? Constraints. We ran out of time. We have a small team. Management discovered the effort and shut it down. Whatever the reasons, you don’t fix all three.

So which problem gets solved? It will probably be the first one, or the one engineers want to solve. That’s bad business.

How to Rank with Intention

Instead, we should rank the items on the list. This forces us to predict which will have the greatest impact.

Perhaps we review our three problems and come to the conclusion that our flaky test suite is the worst. We tackle it first. Given our constraints, that ends up being the only problem that we tackle.

Why Ranking Matters

Ranking gives you a chance to do something that matters.

Consider the Pareto Principle, which states that 80% of effects come from 20% of causes. In a team with tech debt, one problem is always more important than the others.

In some cases, it may be causing the others! To take our flaky test suite example, it could result in developers writing fewer tests. It could mean the developers don’t take on new tasks when tests are running. It could mean they don’t trust the result. These are all symptoms of the flaky test suite.

A Real Example: Web Performance

An area where this technique can be applied is web performance.

Consider a slow webpage. Should we try sharding our database? It will absolutely make the application more performant.

But, there are many things we could do to improve performance. We could shard the database. We could create database views. We could create a read-only database. We could cache data in an in-memory data store.

These are just a few techniques, and we haven’t even left the data layer! There are swaths of real estate that we aren’t talking about. Which is going to have the biggest impact? We have to try to answer that question.

Make Your First Idea Count

Ranking is vital when talking to management. Executives are busy. You can’t come into most meetings planning to read through a list of ideas.

Even if you could, it isn’t the most effective approach. Nobody benefits from dropping a brainstorm on a busy person. It’s better to say: “Our flaky test suite is the most important tech debt issue. Here’s how we’ll fix it. Will you support us?”

In Ride of Lifetime, Bob Iger writes:

“Don’t start negatively, and don’t start small. People will often focus on little details as a way of masking a lack of any clear, coherent, big thoughts. If you start petty, you seem petty.” pg. 227

Start petty, seem petty. If you’re going into a meeting with a decision maker and a list of ideas, your first idea needs to be a standout. You might only get to pitch that one idea. Ranking helps you find it.

Rank What You Can Control

One final note: this concept of ranking is designed for single-use lists that you set down when you’re finished. It doesn’t age well or accommodate endless piles of work.

Anytime you’re making a list at work, of anything, rank it. Always be ranking!