Let small fires burn

Your biggest danger is opportunity cost.

While you run around fixing bugs, product manager Bob wonders "Where are my shiny new features?". Who cares about the bug that affects 2% of our users when this new feature will close a million dollar deal, open a new market, and grow revenue 20%?

Working at a hypergrowth startup can feel like death by a thousand paper cuts:

• Tech debt from your first MVP catching up to you,
• bugs you shipped last week that just need a quick fix,
• old features interacting weirdly with new code,
• new users who always click the wrong thing,
• an alert that used to happen once a month that now happens every day,
• users with more and more data that slowly squeezes your code to death,
• that urgent feature your CEO promised at a conference two weeks ago,
• the latest big sale that's just waiting for a new payment method to start working
• ...

Every day you finish 2 items on your list and add 20 new ideas.

That's a good thing! You *want* to have more ideas than you have time to implement. The feeling that time is short means the company is growing and the market is pulling.

You're dealing with execution risk and execution risk is the easiest to fix: **Hire more people and prioritize**.

Without constraints, you can't do engineering. Constraints tell you the difference between a nice-to-have and a need-to-have. Does the feature work? That's a need-to-have. Is this the best code of your life? That's a nice-to-have.

Reid Hoffman, founder of Linkedin, has a great line in a Masters of Scale podcast episode

You gotta let fires burn. If you try to catch every fire, you'll miss the biggest opportunities

This sounds simple but it's hard to do.

People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are.

~ Steve Jobs

At Plasmidsaurus we have a constant tension between keeping the lights on and big bets that make us stand out in the market. You have to do both.

On any given day you'll have error logs, clunky user interfaces, that one customer who can't place an order to save their life, and a long list of big ideas. The big ideas are your priority, the fires are people throwing tennis balls at you.

Every fire is the biggest most important thing for the person who experiences it:

• The interface they use to do their whole job is bad, broken, and painful to use.
• The world blew up and they need your help to fix it.
• 1 customer is stressed and keeps emailing support about their order. The other 1000 successful customers stay quiet.

None of the asks are hard! 20 minutes tops.

But you have to look everyone in the eye and say "I understand your concern, but that's not a priority right now". Then focus on the big thing that fixes a whole class of issues.

For example: Adding new products and changing descriptions was a constant mess. One thing after another. Then we moved product info into the database, made a dynamic UI, and the noise stopped. Once we added a CMS, non-technical users could own product copy and everyone was happy.

Not all bugs matter.

The average codebase contains 10 to 20 defects per 1000 lines of code regardless of language. 3 per 1000, if you use cleanroom development practices from NASA. You're not using those because you don't have time.

That means in a React codebase like we had at Tia (~69,000 lines) you can expect around 690 bugs. That's not counting the bugs inside our megabytes of dependencies or the huge codebase (~10mio lines) running on the servers.

Scary, right? It's fine.

Many of those bugs never happen, don't cause a problem when they do, or they're impossible to reach for business reasons outside the code. My old manager always liked to say "Don't use code when you can use a lawyer".

Your biggest danger is opportunity cost. Are you working on the highest impact thing you could be doing right now?

You can't do everything, but you *can* focus on the next highest priority. This is true at the individual level, the team level, and all the way up the company.

How do you know what's the next biggest fire? Stack rank!

In his last book, Noise: A flaw in human judgement, Nobel prize winner Daniel Kahneman, writes that humans are bad at judging the absolute value of things. We can't estimate tasks, can't assess what's important, and we're poor predictors of impact.

Kahneman argues that you can't look at a problem in isolation and reliably say "Yep that's a 5 on the fire scale". But you're great at comparing two problems and saying "Yep that one's worse than the other one".

You can use this insight to create an ordered list of priorities.

1. Go pair-wise through your fires,
2. swap to put the bigger fire on top,
3. and after n^2 iterations you have a stack ranked list of fires from biggest to smallest.

Yay bubble sort.

Once you know the next big thing: Work on that. Avoid everything else.

Always aim to have one highest priority item in progress. Work in progress kills your progress.

This sounds obvious when you say it, but is hard to do. Small fires sneak up when you least expect it:

• that quick refactor while you're looking at a crap file,
• the quick reorg of the file structure when making a new module,
• building a quick caching system where it feels like things might get slow in the future,
• getting sucked into fixing a convoluted hard-to-reproduce bug that impacts a tiny fraction of your users.

It's okay to drop bugs as "not worth the effort" after you've invested a bunch of time. Better that than wasting even more time. Add a log so you can monitor the situation.

Yes, you'll need to fix everything eventually. If it's still there by the time you're sipping margaritas on the beach with nothing better to do.

Right now you gotta solve today's fire. You're not here to clean up code, discover the best file structure, or fix every small bug you encounter. You're here to fix the biggest baddest thing that's causing the worst trouble. Put your blinders on and fix *that*.

As they say in Moneyball: Do you get on base?. Cleanup and refactoring and finding the best way to express your thoughts can come later. First, make it work.

Kent Beck, creator of extreme programming, put it best when he said:

1. Make it Work
2. Make it Right
3. Make it Fast

~ Kent Beck

No sense polishing a turd that doesn't even work yet. It's going to change before it works and all your polishing effort will be for naught.

I encourage you to be super strict about what it means for code to "work": Your code's not working until users are using it. No sense writing the perfect code for a feature you'll throw away next month :)

Create followup tasks for any bugs, cleanup, refactoring, and improvement work you find. Keeping track of deferred tasks beats getting distracted from today's goal.

Your best tool in stack-ranking fires is to measure their impact with hard data. This is where observability shines.

When Tia's platform team built a ranked list of our slowest API endpoints, it immediately became obvious my team was strangling the system by fetching appointments on every request. Fixing that **one bug reduced CPU load on our database by 60%**. Huge.

You'd have to fix a lot of other bugs to have the same impact. I've sometimes spent hours fixing bugs only for the original user to go "Oh thanks, I had a workaround hours ago. Your fix looks nice"

How you measure impact depends on the fire. A few questions I've found useful:

• Does it cost money?
• How much?
• Does it break a workflow?
• For how many users?
• Does it resolve on its own?
• How fast?
• How often does the bug happen?
• Are we breaking SLAs?
• How badly?
• Are users complaining?
• Is there reputational cost?
• Can we get in trouble with legal?
• How long has the fire existed without anyone noticing?

Lots of fires feel huge because you noticed. That doesn't mean you have to drop everything and go firefighting.

If nobody's complaining, is it really a bug? For some users, it could be a feature and you'll break their workflow when you fix the issue. Hyrum's Law all over again.

At Plasmidsaurus we had a fun case where a cluttered page made it hard for people to do their work. After much complaining we fixed the page. 10 minutes later an angry mob of users showed up demanding their critical information back.

Secretly there were 2 kinds of users with different needs using the same page. Talk about poor domain modeling.