~/team

How I run a team

Until May 2026 I led the team behind the APIs that power AI auto-marking of written and spoken English at Cambridge University Press & Assessment - two production APIs, five environments. This page is about how I run a team. Most of it comes down to one habit: writing things down.

99.98%

twelve-month API uptime

~1%

change failure rate (DORA)

~350

pages of team documentation

80+

diagrams kept as code

one front door

Everything the team needs lives in one space, and the first thing on the front page is what to do when something is on fire - the incident process, with the on-call number right there. Then everything else.

team-space

$ tree team-space/ -L 1 team-space/ ├── incident-response ← first thing on the page ├── architecture/ ├── practices/ ├── processes/ ├── rfcs/ ├── guides/ ├── reports/ ├── incidents/ ├── glossary/ └── onboarding/

Exported to PDF it runs to about 350 pages, and nobody reads it cover to cover - that is not the point. The point is that any question - how do we deploy, why is the queue shaped like that, what did we decide about X and why - has one obvious place to look. New joiners get productive in days rather than months, and the answers do not leave when people do.

decisions in writing

rfcs

A problem, the options, a proposal - short documents, so decisions are made in the open and the context survives the meeting.

adrs

Architecture decision records in the repos do the same job at code level - numbered, dated, and next to the code they explain.

epic champions

Every epic gets one person responsible for its organisation, documentation and progress - so ownership never evaporates into "the team".

diagrams as code

I think in diagrams. Rough ones start hand-drawn in Miro - boxes and arrows in a workshop beat prose every time. The ones worth keeping get formalised as Graphviz or Mermaid source and committed next to the code they describe.

the pipeline, drawn the same way it is enforced

ci — check:diagrams

$ ls docs/diagrams/ architecture.dot frame-pipeline.dot gpu-buffers.dot netcode-loop.dot $ npm run check:diagrams ✓ 4 diagrams render cleanly, rendered PNGs up to date

CI renders every diagram and fails the build if one is missing or stale - so the diagrams are never allowed to lie. Live examples across the public repos, each with a galacto-style docs/ folder: line-of-sight, evo.

boring on purpose

Operations should be dull. The exciting version is called an incident.

Service levels are the mission - uptime is measured rather than assumed, and the twelve-month number was 99.98%.
Alerts page a human who has a runbook - nobody debugs from memory at 3am.
Delivery tracked with DORA metrics via github-org-metrics, a tool I wrote and open-sourced - change failure rate held around 1% while shipping several times a week per service.
Acceptance tests run against every environment and double as executable documentation of the API.

ai in the loop

The team's tooling used AI where it genuinely saved time: Claude triaging Sentry errors into well-formed Jira tickets, and keeping the backlog deduplicated and readable. My own projects are built the same way - AI-assisted end to end, with the tests, docs and diagrams above keeping it honest.

Sounds like your kind of team?

The full history, skills and live projects are on the CV - or just say hello.

View CV

last updated: 2026-07