Leverage Is the Whole Game

Early in my career I measured a good day by how much I personally got done. Tickets closed, code written, problems handled. It felt productive, and it was — for one person, for one day. It took me a long time to notice that the people who actually moved things weren't doing more work. They were doing work that did work for them.

That's leverage, and it's most of the difference between people who scale and people who just get busy.

Two kinds of hours

An hour has two settings. You can spend it doing a unit of work — answer the ticket, clean the data, run the report. Or you can spend it on the thing that does that work from now on: the script that closes the tickets, the pipeline that cleans the data, the system that runs the report every morning while you sleep. The first hour pays you once. The second pays you every day after.

Almost everyone spends their sharpest hours on the first kind, because it feels good and it's obviously useful right now. The multiplier work feels slower and less certain, so the urgent unit-work wins every single day — and you stay exactly as productive as one person can be.

What counts as a multiplier

Code is leverage — write it once, it runs forever. Automation is leverage; that's the whole reason I build it for a living now. But the highest-leverage thing isn't always software. A person you trust with a whole problem is leverage. A clear decision that kills a hundred future arguments is leverage. A document that answers the same question for everyone who'll ever ask it is leverage.

The test I use: if I do this once, does it keep paying, or does it disappear the moment it's done?

Spend down, not across

This changes how I plan a week. I don't ask what's most urgent. I ask what, if I build it now, means I never have to do this category of thing again — and then I guard the hours for it, because nothing else will. The unit-work always has a louder claim.

You only get so many good hours. Spend them on the things that keep working after you've stopped.