Pick your battles

Everyone theoretically knows the importance of prioritizing, yet many of us fail to make choices.

Let's take a trivial case: say I have 10 simple tasks to do. I know that each task theoretically takes 1 day.

If I start them all at the same time, there's a very good chance it won't take 10 days, but maybe 20, maybe 30.

This comes down to two things:

Mental load. I'll constantly think about the next task, I'll anticipate problems that don't exist yet. In a corner of my head, part of my brain will be processing subjects disconnected from my current task, making me less efficient.
Context switching. To start a task, I have to load a whole bunch of information into memory, sort it out in my head, connect it together, and then I can actually start. Every time I switch tasks, I have to clear everything and load new information. I'm not a computer — these mental operations take real time.

Beyond that, we all have a limited amount of time, and the energy we spend on one task is energy we can't spend elsewhere. To maximize your impact, you have to make choices.

Avoid Sarkozy Driven Development

I've been working with Vincent since we started Malt. He has many qualities and Malt wouldn't be where it is today without him. He perfectly represents the maxim "He didn't know it was impossible, so he did it."

However, I had a running joke with him, as we sometimes had these types of interactions:

Monday: Hey, I saw an old friend of mine who's an SEO specialist. Apparently if we do "insert action A here" we could increase our traffic by 100%.
Tuesday: Hey, I just read an article about "insert tool B here", it's just amazing what they do. We should use it too!
Wednesday: Hey, I have a friend who signed up on Malt. He was looking for a freelancer, and he noticed that on page 3, on line 5, one of the freelancers didn't quite match the search he typed in. We really need to look at that.

If I apply Brandolini's Law to software, it would go something like this:

The amount of energy needed to determine whether an idea works is an order of magnitude greater than the energy needed to come up with it.

It took a lot of energy to deal with each topic.

I ended up calling this type of exchange: Sarkozy Driven Development.

Sarkozy was a former French president, nicknamed the "hyperactive president." He was always reacting. For each new event, he announced a new law.

Of course, having someone who constantly opens new horizons is a source of innovation. But you have to focus your energy to produce maximum impact over a given period of time.

The rule of two

Writing is one way I address the problem of context switching. I have text files that I dump my brain into and pull up when I need them. For organizing my time, it's very powerful.

For years, I've been using a simple text file: TODO.txt. For a long time, this file was a simple list, ordered from most urgent/important to least important.

I start each day by rereading this file, to verify that my day will be satisfactory if I deal with the top items.

Over time, this file also accumulated ideas that were never realized, always pushed down, and it had the problem of not reconciling short-term and long-term priorities.

Now, I use it a little differently.

I invite you to do the exercise and ask yourself the following questions:

What are the two main tasks that I absolutely must have finished today?
Same question for the top two tasks of the week. And you can iterate on the month, quarter, etc.

From there, the rule is simple. Even if you finish the day's tasks every day, it will be a failure if you don't hit your goals for the week. If you hit the week's goals, it will still be a failure if you don't hit the month's. And so on.

This forces me to make choices. I've accepted the things I won't do. It also helps me organize as many of my daily tasks as possible to contribute to my weekly goals.

I got this approach from a video I highly recommend called "Scaling Yourself," which is linked at the bottom of this chapter.

Bring clarity

As software engineers, our job constantly mixes short and long term. We deal with hundreds of pieces of feedback, customer support, sales teams, social media when the company has some visibility, etc.

Prioritizing means knowing how to sort through all this noise to extract the signal. The goal is to determine the real problems to solve — the ones that will bring value to the company.

Once we've found them, a major responsibility for any "Senior," whatever the job, is to bring clarity.

Why do we do this task and not another?

To do this, you must use one of the most powerful tools at your disposal: the phrase "no, we won't do that, because..."

Don't confuse "knowing how to say no" with gatekeeping

By definition, "no" is the word you should say the most, because you have to filter out 99% of the noise to get to the 1% that's truly useful to the business.

I've been working on product definition and engineering strategy for over 10 years at Malt. There are incredible amounts of feedback to process. All of it is interesting. All of it is smart. But not all of it fits the strategy we're aiming for.

When you start to lose focus and accommodate every request — to be agreeable, or in search of consensus — you end up creating debt in the product. To handle a particular case, you handicap all the other users or developers. The product becomes more complex and special cases are introduced that must always be accounted for in further development, which slows down execution speed more and more.

Making a product means making choices. Trying to do everything at once doesn't work. Fail to choose and you create a Frankenstein's monster that will at best limp along, at worst collapse entirely.

However, don't confuse saying no with gatekeeping.

A good way to avoid gatekeeping is to bring the clarity I mentioned above. Providing clarity means explaining why you're making a particular decision.

Then, it's knowing how to say: "ok, this feedback is interesting, but":

we've taken it into account in another initiative that we plan to address later, around Q2
based on early user feedback, we think we should tackle this other issue first
it conflicts with the company strategy to achieve X by year end
given the constraints we've set ourselves, it wouldn't be coherent

Making choices is crucial. Knowing how to explain them is just as important.

Making choices also means knowing how to handle frustration. The frustration of others when your decision isn't what they wanted. But also your own, when you were the one who disagreed.

As a tech lead, you're expected to apply the following rule:

Agree and commit, disagree and commit, or get out of the way — Scott McNealy

In some cases, you have to fight. But again, your energy and your company's energy is not infinite. You have to pick the battles worth fighting.

Choose your battles

To make an impact, you have to constantly balance the quest for perfectionism, the desire to please everyone, and what's best for the company.

It's not just about product and business strategy. At the engineering level, we constantly have to make choices.

In addition to our day-to-day work, it's common to find ourselves with a TODO list a mile long of things we'd like to do:

investigate the performance of page X following last night's monitoring alerts
redesign feature Y to eliminate a coupling issue
write documentation on feature Z
convince the team to switch to W technology
discuss with the PM an opportunity to explore
migrate a set of pages to the recently updated design system etc.

It's a good sign that you're taking the time to think in terms of continuous improvement. But your company has limited time and so do you. You have to choose your battles and apply the rule of two. Not everything is fixable.

Questions to ask yourself

How many goals do you have for the next month?

If you have more than 2, what would you eliminate?

Would you say you prioritize mostly by metrics or by instinct?

Do you have a strategy that helps you make choices?

Do you feel that you always face a lot of resistance to your decisions? Can you explain the underlying reasons?