How I get shit done

01Subtract what’s making you slow

Speed is a subtraction problem, not an addition problem. Don’t ask how to ship faster, ask what’s making you slow and delete it: blocked tasks, too many meetings, vague ownership, ceremonial review. If it had to move in half the time, what would you stop doing first? Nobody knows anything, so build to 80%, put it in front of a real user today, and fix what they trip on. AI won’t save you here; an unclear system just produces confusion faster.

02Keep it simple, then just do it

You don’t need the whole path mapped up front. But at some point the core concept has to click in your head, and once it does the work rolls like a ball downhill, each step making the next one obvious. Keep it as simple as possible, no simpler. Find the 10% that delivers 90% of the value, do that, and just ship it.

03Deletion is editing, not waste

When building is cheap, throwing code away costs almost nothing. The first version runs on speculation, the second on experience, so the rebuild is better every time. A failed first attempt isn’t wasted work, it’s research. Don’t get attached to code you can rebuild in an afternoon.

04Own the whole thing

If something’s broken and you can fix it, fix it and push. Don’t wait for whoever broke it, and refuse to let “that’s not my job” exist. One person owns a feature end to end, across the seams between design, engineering, and product. If you haven’t defined what “done” means, you’ve already failed. VenueSafe went from idea to acquisition in six months because nobody was waiting on anybody.

05Give people the keys

Ownership doesn’t scale by doing more yourself. It scales by handing someone real authority and letting the accountability ride with it. Authority without accountability is chaos; accountability without authority is unfair, so hand over both together. The same generosity compounds in the open: solve your own problem, give the tool away, teach the workflow. The person you teach today teaches their own team tomorrow.

06Build constantly, kill ruthlessly

When AI compresses a weekend project into a few hours, the build-versus-buy maths flips: a few hours buys a tool you control forever instead of one you rent. So build constantly, most things small, every one testing an assumption (I’m 308 repos in and counting). But it only works if you kill just as fast: set kill criteria up front, because when anything is buildable the scarce skill is deciding what deserves to exist. The time excuse is gone; all that’s left is whether the idea was any good.

07Stay at the frontier

Pick the environment where you’ll learn fastest, and the role that scares you slightly more than it excites you. Never stop learning the newest thing. Speed itself is a skill you only build under real pressure, when real people need a real solution and the clock isn’t negotiable.

08Risk scales with blast radius

Risk tolerance should track blast radius. A startup MVP ships aggressively: push to main, get it in front of users. A platform at 90M+ users earns feature flags, staged rollout, and review. The riskiest code (currency, tax, permissions) earns stronger tests even when AI wrote it. AI passing CI doesn’t mean the product works.

09You can sense carelessness

Users can’t see your code, but they feel when it was made carelessly. The sum of the small details is what they feel, even the ones they’ll never consciously notice. Generate fast, then sand the rough edges, and keep sanding. Code and design are cheap now, so knowing what’s good, choosing it, and being accountable for it is the last moat.

10Get in the room

A model can write any code. It can’t be in the room, and it can’t be trusted, and that edge doesn’t commoditise. Play the long game: optimise for opportunity, not this quarter. Do the talks, build in public, help people with no invoice attached, and the surface area for luck grows every year. You can’t schedule luck, only widen the funnel it arrives through.

11The tools are a side note

The mindset above runs on its own; tools just remove friction. Most of my code is AI-written now, so the job shifted from typing to context, planning, review, and taste. Context beats code: the bottleneck isn’t writing it, it’s gathering context, decomposing the work, and reviewing. Prefer constrained AI over open-ended, and let your taste live in the tooling so care is the default.

12Stay calm, bring the energy

Under pressure, don’t rattle. When something breaks or a deal wobbles, the job is to be the calm one who still believes it’ll work, then prove it. Keep nothing important in your head; put it in a system you trust so you can be fully present on the one thing in front of you. The flip side of calm is energy: a slightly obnoxious belief that any problem can be solved rallies people more than any plan.

When the machine writes anything, the edge is what it can’t: taste, ownership, being in the room.