Imagine you are a developer whose job is to work on a large software project. In this case ‘large’ means that there are so many bugs that it’s impossible to fix them all.

Different bugs impact different amounts of users. Some bugs affect one person, while others affect 100 or even 1000. Of course bugs also have different severity – some bugs are minor annoyances while others cause serious problems – but let’s consider a group of bugs that all have similar severity (and similar cost-to-fix) and the only major difference is how many users are affected by them.

Here are two ways to work in this environment:

Option 1: You spend every day fixing a bug that affects one user. At the end of the year, you have fixed about 200 bugs and made life a little better for about 200 users.

Option 2: You spend one day fixing a bug that affects 1000 users, and then spend the rest of the year goofing off, watching TV at work, and rearranging your desktop icons.

The second choice is better. In fact, a developer who chooses the second choice is five times more productive than a developer who chooses the first. They have five times the impact because five times as many users are affected by their work.

Of course there are more choices than the two options above, but I’m comparing these two specific options to make a point:

‘Option 1’ is not a good choice. It is not useful or noble or heroic to come to work every day and do work that doesn’t matter. It doesn’t make you a good developer or even above average. It is a waste of company time.

In my experience, in large companies, a lot of developers choose something like option 1.

These companies end up moving very slowly. Users feel like bugs never get fixed, because the same frustrating bugs remain year after year – despite hundreds of users asking for improvements. These companies grow, hiring more developers to increase speed, but the speed never comes. The additional developers are working hard, fixing issues every day, but the users don’t seem to notice any difference.

To create real impact, we must focus on work that matters.

How do we do that?

1. Spend more time understanding the users and the product. Get to know what people are asking for and why. This leaves less time for actually fixing bugs and that’s OK. Remember that it’s better to fix one high-impact bug than 200 low-impact bugs.
2. Be wary of metrics. It’s easy to attach importance to a number – “I fixed 200 bugs this year! Cool!” Making that number go up might not represent actual benefit for the product or its users. If you must track a number, find a number that your customers think is important.
3. Be transparent. If it’s possible to tell your users what you are working on each week, do so. They will tell you when you’re wasting your time on low-impact work. If it’s not possible to be that open, you can use your imagination instead. Ask yourself: if our users knew what I was working on today, would they be happy? Or would they suggest something else?

Learning about the product and the users’ needs lets a developer be more effective. Working hard on unimportant tasks is no better than goofing off. By focussing on what matters, we can delight our users and move much faster than we could before.