Accidentally in Code

We’re doing a big release this week for DRI Your Career. Mostly bug fixes and reliability work nobody will notice, but the two things worth mentioning:

• Audio episodes are now available as a private podcast feed.
• Made significant progress towards supporting multiple coaches (yes this implies some very exciting announcements – more soon).

We’ve come a long way since it was just Jean and “Claude the intern”, but mostly very iteratively. We’d come to a point where it seemed worth rethinking. We wanted to ship some bigger things – this release was nearly 100 PRs over about a week, passing back and forth between Ireland and California – and to do that we had to mature our approach.

1. Release branch and release process (vs pulling from main). I know this goes against conventional wisdom, but for a 2 person team with no on-call SRE, I think it’s better to be able to schedule your problems for a convenient time.
2. Orchestrator + merge queue. The merge queue tends to be stricter, so everything gets 2 code reviews, follow-ups filed, and so on. It also handles sequencing and rebasing – the things I used to burn CI minutes on when I was chaotically working in 5 tabs.
3. Board hygiene. P0/P1/P2/P3 issues, aligned with the orchestrator + merge queue setup. Everything related to features slated for the next release gets tagged so it gets prioritised.
4. Devex and optimisations. Ephemeral DB targets, authenticated E2E tests, env var requirements, a full design system, automated nightly DB backups.

What I find interesting is that these four pieces map onto four different phases of a team maturing.

1. Overkill. Slightly anal for two people. But the natural progression for a 2 person team no longer wanting to deploy main on every PR.
2. The AI-native piece. Only necessary because AI exists – also allows Claude to work overnight whilst we are sleeping (and don’t need the tokens for everything else we are doing).
3. The setup of a well-organised 6+ person team. What keeps the orchestrator (and us!) focused on impact rather than maxing out token and CI spend. Brought in when I realised we could easily ship >50 PRs but no finished headline feature.
4. A level I used to watch 20+ person teams struggle to reach. Necessary to support the velocity.

All of this to say that a sensible setup for a 2-person team has shifted dramatically from even a year ago. If the shift is that big for a small team running a small website on top of other activities, it’s going to be even more dramatic for larger teams. The list above is our specifics, but the categories are transferable: even if your process was right sized for your team before, it isn’t – or shouldn’t be – once each person on your team is running a team of agents.

1. What is your release process? How do you validate, find issues and monitor?
2. How do your agents run, what guard rails are in place?
3. How do you maximize value for token spend?
4. What’s your DevEx setup and how does it need to evolve?

Lately I’ve been thinking about the AI shift as upending the standard bottlenecks for team scaling. That’s moved me from “we need a new playbook” to “we need to update the existing one with different priorities”. All but one of these are things I’ve done as part of scaling a team in the before times. I just didn’t used to do them all in a week.

This is why I stay optimistic about developers even as writing code gets automated. You can’t just “AI it”: getting AI to solve problems faster than it creates them takes judgement. Claude helps enormously in moving things forward, but knowing what to prioritise and what it should be doing is a critical input.

This is the kind of work good managers do – evolving how the work gets done as the team evolves, to keep things moving. So we’ve decided, again, that we “don’t need managers”, at the exact moment there’s more of that work to do than ever… My hot take from years of experience scaling teams and being deeply immersed in AI-dev for the last 8 months or so? We’ll come back to the same conclusion – managers matter 🍿