Blog
Time on Feet
Two months ago I wrote about capping my concurrent projects after a team retro put a name to the exhaustion we were all feeling. Last week I counted the agents I was juggling.
Ten.
I’d like to say there was a dramatic moment — a broken build, a deadline missed, an output so mangled I had to sit down. There wasn’t. Just another week of believing I could multitask and orchestrate well enough to handle them all, and the quiet, accumulating evidence that I couldn’t. I struggled to juggle the context switching. Work got done, but I couldn’t have told you with confidence which of it was good.
What caught me wasn’t a moment. It was a dawning realisation about the state the whole digital product industry is in — and an old lesson I’d apparently forgotten I’d already learned.
Before Fireball Apps, I was a co-founder at Byrd. We were building an app to help runners put together sustainable training plans. Edd, the founder, was a serious runner and one of the most intelligent people I’ve ever met, and he geeked out on his training regime accordingly — dozens of techniques, endless reading on how often to run, how far, how fast, how varied. Working on that product turned me from someone who couldn’t run into someone who could.
And here’s the thing. Underneath all that reading, the science of a good training plan came down to a handful of principles that most people get wrong.
Most people run too fast or too far in their regular training runs. Slowing down a little and stopping earlier leaves more in the tank for the rest of your day, and lets you recover quicker. Which leads to the more crucial point: most people train too hard, and the extra recovery time that costs them means they run less overall.
The biggest predictor of whether a runner would improve wasn’t intensity at all. It was a phrase Edd used constantly: time on feet. Shorter, slower runs meant more runs, and more runs meant more time on feet. The runners who improved weren’t the ones who hammered themselves — they were the ones who kept showing up because they hadn’t wrecked themselves the day before.
I won’t pretend this maps one-to-one onto AI adoption and the vibe-coding era. But sitting behind ten agents, stretched and unsure of my own output, the parallels were hard to ignore.
Engineering teams are feeling burnout more than they used to — I’ve written about this before, and I hear it from teams I work with. That sounds a lot like running too fast and too far in our day-to-day training runs.
And the pace of change makes it worse. No matter what we do, a newer, better way of doing it is almost always just around the corner. That model, that new MCP server, that new tool is out tomorrow — because it always is. The industry’s answer to every question right now is run harder: more agents, more parallelism, more throughput. It’s the training plan of someone who hammers themselves every session, improves for three weeks, and then stops running entirely.
What I’d like to see from engineering teams isn’t simply more coding done with agents run in parallel. That isn’t sustainable, and I don’t think it’s even fast — not over any distance that matters.
What I’d like to see is more progress in refining what we have.
So here’s what I’m actually changing, starting this week: a review step after each session.
After each run, look at what’s been completed and ask whether it’s of a higher quality than what came before. If it is, carry on. If it isn’t, reassess — the plan, the prompts, the number of agents, the pace. It’s the running principle transplanted almost directly: the point of a session isn’t the distance covered, it’s whether you’re in better shape for the next one.
I don’t know yet what the right cadence or format is — that’s a future post, once I’ve got some honest miles in. But the shift in mindset is the part I’m confident about. Time on feet, not speed per session. Sustainable throughput, not maximum throughput. The teams that improve over the next few years won’t be the ones running the most agents this quarter. They’ll be the ones still showing up, still learning, still shipping — because they didn’t wreck themselves sprinting after every new tool.
I helped build a product on that principle. It took ten parallel agents to remind me it applies to me too.
If your team’s training plan currently reads “run harder” — more agents, more parallel work, more pace — and you’re quietly wondering how long that holds, that’s a conversation I’m having a lot at the moment. Come and find me before the wheels come off.