Skip to content
Matthew Blode

How I get shit done

You don’t win by being right. You win by finding out faster.

Nine things I’ve learned about shipping, as an engineer and technical founder, across two startup exits (VenueSafe, Fingertip) and 90M+ users at Linktree. The tools come last.

01Ship fast or die

Going faster means removing what’s slowing you down.

Instead of asking how to ship faster, ask what’s slowing you down and get rid of it: blocked tasks, too many meetings, fuzzy ownership, PR reviews. Find the 10% that gives you 90% of the value, and get it in front of real people. Nobody knows what works up front, so the quickest way to find out is to put it in someone’s hands.

02Bias towards action

Even a failed first attempt teaches you what to build next.

Now that building is cheap, throwing code away costs nothing. Your first version is just a guess, so try not to get attached and keep iterating.

03Own it, then hand over the keys

If something’s broken and you can fix it, just fix it and push.

Try to kill off “that’s not my job” wherever it shows up. One person should own a feature the whole way through, across design, engineering, and product, and if you can’t yet say what “done” looks like, sort that out first. Ownership doesn’t scale by doing more yourself, it scales by giving someone real authority and the accountability to go with it. Give them both at once, because authority with no accountability gets messy and accountability with no real say isn’t fair on anyone.

04Build lots, keep it simple

Get it simple enough that it clicks in your head.

Solve your own problem, give the tool away, and show people how you did it. For each project, find the little crux of the problem and get it as simple as you can, until it clicks. Once it clicks, it’s like a ball rolling downhill.

05Risk scales with blast radius

How much you can break decides how carefully you ship.

An early MVP can ship fast and loose: push to main, get it in front of users. A platform with 90M+ people on it earns feature flags, staged rollouts, and proper review. The scariest code, anything touching money, tax, or permissions, earns stronger tests even when AI wrote it. CI going green doesn’t mean the product works.

06Stay at the frontier

Pick the role that scares you slightly more than it excites you.

Put yourself where you’ll learn the fastest, and keep learning the newest thing. Speed is a skill, and you only build it under pressure, when real people need a real answer and the deadline isn’t moving.

07You can sense carelessness

People never see your code, but they can feel when it was made carelessly.

It’s the sum of all the small details that people pick up on, even the ones they’d never consciously notice. So generate fast, then go and sand down the rough edges, and keep sanding. The thing that still sets you apart is knowing what’s good, choosing it, and standing behind it.

08Get in the room

A model can write any code, but it can’t be in the room, and that part doesn’t go away.

Play the long game and optimise for opportunities. Do the talks, build in public, help people when there’s nothing in it for you. You can’t plan luck, but you can give it more ways to find you.

09Getting things done

A slightly obnoxious belief that any problem can be solved does more for a team than any plan.

Don’t carry everything in your head: put it in a system you trust so you can be fully present on the one thing in front of you.

When AI can write anything, your edge is the stuff it can’t do: taste, ownership, being in the room.