Sharpen your Axe

The Wrong Kind of Busy

If you have never watched competitive timbersports, you should. It is the sort of thing you flick to by accident on a Sunday afternoon and cannot look away from. A man stands on a horizontal log the width of a frying pan,¹ swings an axe between his own feet, and cuts clean through it in under twelve seconds.² The audience goes mad.

But the real event happened hours earlier, off camera. The same man sat with a pair of compasses, scratching arcs from each corner of the blade to find its exact centre point. He checked with calipers, locked the head into a jig, ground the edge in careful bursts, filed the bevel to exactly 20 degrees.³ Thinner cuts better; thinner also chips. Every competitor has their own answer to that trade-off, and the good ones keep it secret.

Most knowledge workers have the opposite instinct. They spend their days inside other people’s tools. Someone else’s note-taking app, someone else’s text editor, someone else’s workflow. They type faster, learn shortcuts, maybe install a plugin or two. They swing the axe harder.

There is a saying, often attributed to Lincoln: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” Lincoln never said it.⁴ An Oklahoma pastor coined it in 1944, quoting an anonymous lumberjack — and the original was measured in minutes, not hours. Each retelling inflated the numbers. The insight survived the inflation. The person who sharpens first will outperform the person who swings dully all day. Not by a little. By a lot.

But most people never sharpen the axe. They feel too busy chopping.

What Sharpening Looks Like

For a programmer, sharpening the axe means building the thing that makes the next thing easier to build.

My dotfiles are a public record of years of this, and most of the tools are small to the point of embarrassment. explaincron turns 0 */4 * * * into English. rjq gives jq a live REPL, because nobody writes a jq filter correctly on the first try. 2md takes whatever HTML you pipe at it and hands back markdown; ocr does the same for screenshots. execblock runs code blocks straight out of a markdown file, which means my notes can do things.

The same instinct, scaled up, becomes a knowledge base. I wrote tools to pull down research papers, parse them, and produce summaries in a structure I find useful. The base holds detailed prompts that describe how I like my notes organised, how I think through problems, how I want information presented back to me. It even holds a style guide for my own writing — six pages of rules about sentence length, banned vocabulary, and what good prose sounds like.⁵

None of these tools was urgent. Nobody was asking for them. But each piece compounds. A good summarisation prompt saves me twenty minutes per paper. Over a hundred papers, that is a working week. A well-structured knowledge base means I can find my own thinking from six months ago, instead of reconstructing it from scratch. The tool pays for itself, then keeps paying. Good tools remove friction. Great tools remove decisions.

The Arithmetic Has Changed

An xkcd chart maps how long you can spend automating a task before you waste more time than you save.

It is a sensible chart. For years it was right. If a task takes five minutes and you do it weekly, you get roughly four hours a year to build the automation before you are underwater. Most custom tools took longer than four hours to build, so people rightly left them unbuilt.

That arithmetic no longer holds. The cost of building a small tool has collapsed. A script that once took an afternoon now takes fifteen minutes of describing what you want. The xkcd break-even line has moved so far down the chart that tasks you would never have bothered automating are now obvious candidates. The five-minute weekly chore? You can automate it in less time than doing it once by hand.

And the line keeps dropping, because the multiplier grows with every model generation. Two years ago, handing a bug to a model meant an afternoon of supervision: feeding it files, correcting its guesses, coaxing it back on course. With Fable 5 I can say “look at this bug and fix it”, go and make tea, and come back to a fix with a passing test. The same hour of sharpening buys more each release; whatever break-even you calculated last year is already out of date.

Cheap tools change the compounding story. When each tool costs fifteen minutes, you build more of them; and the ones worth paying attention to are not the tools that save you five minutes but the tools that make other tools. A knowledge base helps you write good prompts. Good prompts help you process new information. Better information helps you build the next tool. The xkcd chart assumes each automation is independent. They stack. The hard part is no longer justifying the first push; it is noticing the friction in the first place.

Between the Swings

A sharp blade is wasted if you spend half the day walking between trees. For a knowledge worker the walking is context switching: alt-tab to Slack to find out why a decision was made, over to a dashboard to work out what broke, into last week’s meeting notes to remember what was agreed. None of it is the work, and all of it eats the day. Worse, it starves your agent: every piece of context you fetch by hand is context the model never sees.

So the second half of sharpening is connection. Spend the time to make your tools reach each other:

• Team chat. Decisions and their reasons live in Slack threads, not in code. An agent that can read the whole conversation is far more likely to build what you meant rather than what the ticket says.
• CI and deploys. You should not be fixing CI failures yourself any more, and a routine rollback should not need you at all. If reverting a bad deploy still involves a human, that is a tool you have not built yet.
• Production logs. An incident is a race to assemble context, and an agent assembles it faster than you can; but only if it can reach the logs, and only if the logs are good enough to reconstruct what happened. Teams that wire this up will simply move faster than teams that page a human to do the aggregating.
• Docs and meetings. Design docs, runbooks, transcripts. Feed the meeting notes to the agent the moment the meeting ends; I routinely get two or three pull requests out of a single meeting. Diarise the recording, so the model knows who said what and who wanted it.⁶

What if you are locked into Google Slides, or Slack, or some enterprise tool whose API permission you will never be granted? That used to be the end of the conversation. Now it is an afternoon’s work: point a modern LLM at a network capture of you using the thing and ask for a command-line tool that does the same. agent-browser is great for this. The integration nobody would approve becomes a script nobody can take away.

To find your own gaps, try a full working day without leaving Claude Code. Every time you alt-tab to copy something in or out, write it down; each entry is a missing connection. The list will be longer than you expect. The gap is much bigger than you notice, right up until you make the connections.

Letting Go of the Handle

The usual objection to all this is control. If the agent can read your Slack, your logs, and your meetings, and act on what it finds, what stops it doing something you would regret?

Auto-mode — letting the agent act without approving every step — is at its best for exactly the people who worry about this, because the worry has a productive outlet. Vigilance you pay continuously; a guardrail you write once. Mine live in the same dotfiles: a hook that blocks rm -rf and offers the recoverable trash instead, and another that stops the agent reaching for the wrong package manager in a given project. Anything outward-facing follows a stricter rule: rehearse before sending. A Slack update gets posted to a private preview channel first, reviewed and edited in-thread, and only then promoted to the real one. The agent swings freely; the edge only lands where I have already agreed it can.

Sharpen Your Axe

If you do knowledge work and you have not built a tool in the last month, you are probably swinging too hard and sharpening too little.

Start small. Write a script that automates something tedious. Build a template for a document you create often. Describe your preferences in enough detail that a machine could follow them. You are not wasting time. You are building leverage.

The tree will still be there when you are done sharpening.