There's a game you play as a kid - music plays, a potato gets passed around the circle (ours was a beanbag, I think, or somebody's shoe - the potato was always theoretical), and the only rule anyone actually remembers is that you do not want to be the one holding it when the music stops. That's it. Fifteen years of shipping software - startups, banks, tax systems, and now a large government data platform - and the most useful delivery framework I've found is a children's party game.
Never be the reason the project is stalling.
That's the rule. Get things off your plate as fast as you possibly can. Everything else I believe about delivery - and I seemingly believe quite a lot, judging by the length of this post - is downstream of that one sentence.
Some context for why I'm writing this now: I'm currently a consulting Tech Lead on a data engineering project inside a large UK government programme (HMRC), via the good people at Equal Experts - technical design of pipelines and integrations across enterprise systems, mentoring engineers, partnering with delivery leads. Which is about as far from a six-person startup as it's possible to get whilst still technically doing the same job. And the thing that's surprised me is that the rule holds in both places. Hits harder in the big one, actually.
Projects don't fail because people can't do the work
It's almost never a talent problem.
Every late project I've ever been near - and I've been near some properly late ones - was full of capable people working hard. Flat out, in most cases. Calendars rammed, Slack going like a slot machine. And yet nothing, or very very slow, shipping. Because the work wasn't moving - it was sitting. Sitting in a "blocked" column nobody had looked at (or simply didn't want to, myself included) in a week. Sitting in a PR waiting for review. Sitting in an email to a third party that we'd sent, and, well, the ball's in their court now isn't it. (It is not. There is no court. The ball has simply disappeared.)
Staleness. That's the killer. Not difficulty, not incompetence - staleness.
I wrote about a version of this in The First CTO - the engineer whose tasks would go into a black hole. Genuinely talented, lovely person, doing careful and thorough work, and none of that mattered because the task would vanish for two, sometimes three weeks with no visibility, and I'd be awkwardly fishing for updates in standups and getting nothing back. Try roadmapping around that. Try giving a founder a timeline when you don't know if a feature surfaces this week or next month. The work was good. The silence killed us anyway. I said it in the book and I'll say it again here because it's maybe the most expensive lesson I've learned: the cost of silence is so much higher than the cost of rough edges. Rough edges you fix in a follow-up PR. Silence just kills momentum, and momentum is the only thing a project actually runs on.
So: aggressively squash bottlenecks. Keep everything moving and flowing, at all costs. And when a potato lands in your hands - a decision, a review, a question, a dependency - either deal with it or pass it on today. Not after you've finished your "real work". This is the real work. Took me embarrassingly long to accept that.
The Midas touch
Right, so what does this actually look like day to day. The frame I use - and I'm aware this sounds a bit grandiose, bear with me - is trying to skew every single interaction towards unblocking, progressing, or fixing something that was broken, stuck or slow. Every meeting, every Slack reply, every review, every corridor conversation (or the remote equivalent, which is I suppose just...more Slack). You touch it, it turns to gold. Or at least turns to slightly further along than it was, which is less catchy but more honest.
When I was CTO at a startup with engineers split between India, the UK and the US, my entire day was architected around this without me really noticing I'd done it. Mornings were for the overnight questions from India - unblock them first, they'd been waiting while I slept. Then clear the wreckage from the US day - requests, fixes, code reviews, all of it sat there ready for when I logged on. Then, and only then, my own building work, squeezed into a window in the middle of the day. Afternoons stayed clear for the US coming online. My own output lived in the gaps. That's the job - the day arranged around other people's flow rather than my own.
The anti-pattern, by the way, is the interaction that observes but doesn't move. The status update that's purely a status update. The meeting where everyone reports what they did and nothing changes hands. If an interaction ends and no potato has moved... what was it for? (I know what it was for. It was for the calendar. The calendar is insatiable.)
Leverage, or: stop doing the bug list
I'm writing this as someone who gets it wrong constantly: the most productive-feeling work is often the lowest-leverage work available to you.
Working through a bug list feels brilliant. Tight feedback loop, visible progress, little dopamine hit per Linear ticket. And it's often exactly the wrong thing for you - specifically you, the lead - to be doing, because a mid-level engineer could clear that list nearly as fast, and meanwhile the external dependency that's about to stall the entire team for a fortnight is sitting there, ignored, because chasing it involves emails and Zoom calls and other people's bureaucracy and no dopamine whatsoever.
I dedicated a whole chapter of the book to this ("The Bottleneck Is You" - subtle, I know). I spent months writing features someone else could've written while the observability and alerting work that only I was going to do sat unfinished - and we paid for it, repeatedly, including one stretch where customer transactions weren't syncing and my fix was to just...manually fetch the missing ones. Each time. For weeks. Treating the symptom on a loop because properly diagnosing the cause felt like a chore. The question I eventually learned to ask myself - and still have to ask, most days - is: is this the best use of my time, or just the most comfortable use of my time? They are almost never the same thing.
Leverage means spending yourself where it compounds across people. One unblocked dependency beats ten closed bugs. It just doesn't feel like it at 4pm on a Tuesday.
Quarterbacking
Somebody on the team has to be watching the whole field. Not micromanaging - watching. Deadlines, bottlenecks, who's blocked on whom, which dependency is going to bite in three weeks. Everyone else is heads-down executing (as they should be, that's the job), which means if nobody's zoomed out, the project is effectively driving with no mirrors.
I called this quarterbacking in the book - my job was "to play quarterback more than score the winning touchdown" (I still can't think of the UK sports equivalent, don't write in) - and it's become even more true as a Tech Lead than it was as a CTO. Think two or three moves ahead, like chess, except all the pieces have opinions and some of them are on holiday. If I know we'll need something from another team in three sprints, that conversation starts now, because on a big programme the lead time on a cross-team ask is measured in weeks, and the only way to make that invisible is to start before you need it.
The other half of quarterbacking is knowing which decisions to make instantly and which to slow down on. My whole framework is reversibility - if it's cheap to undo, decide now, on the spot, write it down, move on. Save the ceremony for the genuinely irreversible stuff. A pending decision blocks work just as effectively as an outage; it just does it politely.
The version of this I actually use with my HMRC team - and I should say upfront I nicked it from Josh Radnor, of all people, who frames every decision as one of three things - is: hats, haircuts, tattoos. A hat is easy to take off if it looks rubbish - try it on, decide in the meeting, move on. A haircut you'll have to live with for a few weeks, but it'll grow out - worth a conversation, not worth a committee. A tattoo is significant time, effort and money to undo - that's where the ceremony goes, the review boards, the sleeping on it. I introduced it to the team a few weeks back and promptly butchered it in the retelling (someone asked me later what "the hats thing" was because they couldn't think of a hat that would be hard to take off - fair, honestly), but it stuck, and now it's shorthand in our design conversations. "Is this a haircut or a tattoo?" turns out to be a genuinely useful question to ask out loud in a room, because most decisions that were about to eat a fortnight of deliberation reveal themselves to be hats.
Look at the scary parts first
Related, and worth its own section because I've watched it sink more timelines than anything else: every project has bits everyone is awkwardly avoiding. The integration with the system nobody fully understands. The tedious data migration. The auth. You can feel them on the plan - they're the boxes people estimate suspiciously quickly and then don't make eye contact. And the natural instinct is to start somewhere comfortable instead, bank some easy wins, build a bit of momentum - which feels sensible and is actually just deferral, because the scary part doesn't get less scary by being scheduled later. It just detonates closer to the deadline, when you've got no room left to absorb it.
So: scary parts first, always. And the frame I use for finding them - and I did not expect to be earnestly recommending a Donald Rumsfeld quote in a blog post, yet here we are - is the known/unknown matrix. He got roundly laughed at for it at the time, and it's genuinely one of the most useful planning tools I know. Strange world.
Four quadrants:
- Known knowns - the work. You know it, you know how to do it, estimate it and crack on. This is the stuff project plans are made of, which is exactly why project plans are so misleading - it's the only quadrant that behaves.
- Known unknowns - the scary parts you can already name. "We don't actually know how that system handles partial failures." "Nobody's confirmed the data format on their side." These are where the delays live, and the move is to attack them first - spike them in week one, not week ten. A known unknown investigated early is a line on a plan; investigated late, it's a crisis.
- Unknown knowns - the sneaky quadrant, and on a big programme, the one I spend most of my time in. This is knowledge that exists - somebody, somewhere, already knows the answer - it just doesn't exist in your team. It's three desks away, or in another supplier, or it left the programme eight months ago, or it's sitting in a Confluence page last edited in 2019. My single most repeatable trick as a Tech Lead is aggressively hunting these down: the question your team is about to burn a fortnight investigating is, alarmingly often, a twenty-minute call with the right person. Finding the right person is the skill. Ask around loudly. Someone always knows.
- Unknown unknowns - the ones you can't hunt because you can't name them. You don't plan for these; you surface them early by building a thin end-to-end slice of the system as soon as humanly possible (poke the pipecleaner through the pipe), so they detonate in week three (cheap, interesting, "huh") rather than week thirty (expensive, career-shortening). And you keep some slack in the plan, because there will be one. There is always one.
In hot potato terms: a scary part everyone's avoiding is just a potato someone's hidden. It's still there, still cooling, it's just cooling somewhere nobody can see it - which is worse. Get it on the table in week one.
Be a generalist with one sharp edge
There's an economics concept I kept reaching for when I was sketching this post out - comparative advantage. Figure out your strongest move and apply it aggressively, because that's where the upside is. Not "be well-rounded". Well-rounded is table stakes; you need enough breadth to opine usefully on the whole architecture, to keep up in any technical conversation on the project. But breadth alone makes you a floating generalist, and floating generalists are lovely and charmingly a bit useless.
You need one thing you bring that the project measurably benefits from. On the HMRC programme, mine is overall system architecture and API design and production - that's my sharp edge, that's where I can walk into a room and actually shift the outcome. The 40% rule from the book applies here too - your technical skills end up being less than half the job, the rest is communication, unblocking, translating, quarterbacking. "Five jobs in a trench coat pretending to be one job", as I put it then, and government delivery has, if anything, added a sixth.
One caveat, learned the hard way (there's a double-write bug with my name on it in a previous life): your own understanding should not be the ceiling of the system you're building. Generalist with a specialism also means knowing exactly where your specialism ends and pulling in the person whose edge it actually is. Passing the potato, again. It's all the same move.
Build the team so the potato barely touches the ground
Two things I now believe about team shape, both learned by getting them wrong first.
One: vertical slices beat horizontal slices. A team where each person can influence and execute across the whole stack will outrun a team of siloed specialists every time, because every silo boundary is a place where the potato has to cross a desk - and desks are where potatoes go cold. Fewer handoffs to outsiders, fewer "waiting on the platform team" tickets, fewer potatoes in the air at all (a lovely image nonetheless).
Two: work out people's actual strengths and skew the work towards them. Not the org-chart version of their strengths - the real ones, the ones you only learn by watching people work. Then form little cross-functional pockets around features and let them run. The proudest moment of my second CTO stint - and I mean this, although it didn't feel like pride at the time, it felt weirdly like being made redundant - was a feature that shipped start-to-finish without me. Small cross-functional group, engineer leading it, product, iOS, founder. I was consulted twice, I think. Advisory. Nobody says "congratulations, the team doesn't need you anymore" - there's no card for it - but that is the success state. That's the machine whirring away.
Be someone people want to pass to
Softer one now, but I'd argue it's load-bearing: be personable. Be actually pleasant to work with. Nobody wants to hand a problem to the person who greets every request with a sigh and a lecture - so they don't, and the potato quietly stops being passed to you, or worse, stops being passed at all, and now there are cold potatoes accumulating around one difficult person and everyone's pretending not to notice.
I've watched a technically brilliant person do this to a team - collaboration slowly becoming "a negotiation you can't win", engineers going quiet in meetings, not because they had nothing to say but because they'd learned it wasn't worth the friction. And (deep breath, said this in the book, saying it again) I've been that person, early in my career - "a very effective one-man army", which I took as a compliment for an embarrassingly long time before realising it meant "doesn't play well with others".
Momentum, motivation and morale all marry together - lose one and the other two start wobbling. Shipping regularly keeps the hum going; it's genuinely infectious, it makes the product feel alive. And when someone drops a potato - because they will, everyone does, I have dropped absolute clangers - it's "we", never "them". People pass freely when dropping one isn't fatal. That culture is built or broken in about a dozen small moments, and you don't get to choose which dozen. Relentlessly celebrate wins publicly, dissect losses voraciously but blame-free.
The payoff is non-linear
Why bother with all this? Because delivery isn't supposed to be linear, and if yours is, something's being left on the table.
Linear is: everyone busy, output roughly proportional to headcount, fine, whatever. Exponential is what happens when unblocked people start unblocking each other - when the thing you cleared on Monday means three people don't stall on Thursday, and one of them clears something that saves the team a sprint next month. Leverage stacks. Flow compounds. The best project I've ever been part of - a six-week, one-shot, real-money ledger migration, coordinated across timezones, deployed simultaneously at 6am my time and 10pm his - went flawlessly not because we worked harder but because the scoping, ownership and handoffs were so clean the thing basically flowed downhill. It's still my gold standard for what delivery can feel like.
The catch - and I've made my peace with this, mostly - is that the enabling work is invisible. Nobody screenshots your observability setup. Nobody tweets about your CI pipeline. The metric that matters is: is everyone else shipping faster and more confidently than they were three months ago? If yes, you're doing it. Even if you can't point at a single feature with your name on it. Especially then, actually.
The government bit
So does any of this survive contact with government? With large enterprise organisations?
A large public-sector programme is, structurally, a machine for cooling potatoes. I say that with genuine affection - the governance exists for good reasons, this is tax infrastructure, you want assurance gates on tax infrastructure - but the shape of the thing is: multiple teams, enterprise systems on every side, delivery leads, architecture boards, stakeholders whose calendars book out weeks ahead. Every one of those boundaries is a desk. Every desk is somewhere the work can quietly stop.
Which is exactly why the hot potato rule matters more here, not less. At a startup, urgency is ambient - the runway does the motivating. On a programme, urgency has to be manufactured, daily, by someone - and as Tech Lead, that someone is largely you. The technical work is genuinely complex, but the team handles complex; complex is what they're for. What the team can't do from inside their editors is keep work moving across organisational boundaries. So that's the gig: chase the decision like it's an incident, pre-heat the dependency two sprints early, make the "waiting on" column the most scrutinised thing in standup. Startup risk is chaos; programme risk is stasis.
"Am I working hard enough?"
One last thing, and it's the part I still wrestle with, because everything above has a jarring duality to it: when you do this job well, it looks like you're not doing much.
A tweet did the rounds recently that I haven't stopped thinking about - "a good middle manager looks like a guy who just drinks coffee and forwards emails, but his actual job is secretly absorbing insane executive requests so the team can just do their work." I chuckled, and then I felt extremely perceived. Because that's the shape of it, isn't it. No artefact at the end of the day. No PR with your name on it. A day spent chasing a decision, pre-heating a dependency, absorbing something from upstream so the team never even knew it existed - and at 5pm your brain, trained by fifteen years of tight feedback loops and green CI ticks, pipes up with: did you actually do anything today?
I get this a lot. More than I'd like to admit. "Am I working hard enough?" - as though the only admissible evidence is output I can point at.
The answer I've landed on - and I have to re-land on it roughly weekly - is: look at the project, not at your plate. Is it humming? Are people unblocked, shipping, in flow? Are the potatoes moving? Then yes - you are, by definition, working. The hum is the output. An empty plate and a moving project isn't slacking; it's the entire job description. It just doesn't feel like it, because the work you absorbed is invisible precisely when it's done well - the crisis that didn't happen doesn't send a thank-you note.
There's an old saying - "absence of evidence is not evidence of absence" - usually credited to Carl Sagan, though apparently it goes back to a Victorian missionary in 1888, because no good aphorism has a tidy origin story. (I did check whether it was Rumsfeld, hoping for symmetry with earlier. It wasn't. Gutted.) But here's the thing: in this job, you have to invert it. Absence of evidence is the evidence. The dependency that never became a blocker, the decision that never sat in a queue, the escalation that never needed escalating - it worked because nothing came of it. Nothing happening is what success looks like from the inside. Quiet weeks aren't a sign you've coasted; more often they're the receipts. You just have to learn to read them, because nobody else is going to read them out loud for you.
TL;DR
Fifteen years, one children's game:
- Never be the reason the project is stalling. Get things off your plate fast.
- Staleness kills projects. Not lack of ability - staleness.
- Skew every interaction towards unblocking something. Skip the bug list; chase the dependency.
- Somebody has to watch the whole field. Think two or three moves ahead.
- Play your comparative advantage aggressively, and know where it ends.
- Vertical teams, real strengths, high morale. Be someone people want to pass to.
- Do all that and delivery stops being linear.
Keep the potato hot. Keep it moving. And whatever you do - don't be holding it when the music stops.
(More of the stories behind these ideas - the failures, mostly - are in The First CTO.)