Skip to main content
This page is the bar we work to as a team. Read it before anything else when you join, and come back to it whenever you’re weighing a tradeoff or unsure how to approach a problem. For how this bar shows up week to week — Monday planning, standups, reviews, retros, and the Friday update — see Operating Rhythm.

​
What Makes Fleet Manager Different

Fleet Manager is the backbone of how we stand up and manage fleets worth tens of billions of pounds of hardware. That’s not a tagline — it’s the operating reality, and it shapes the bar we work to. A few things make this team unlike a typical product team:
  • No realistic test environment. The hardware is expensive and hard to come by, so we often don’t have anything to test against, and we rarely see the full shape of a deployment until a datacentre actually goes live. No plan survives first contact.
  • Factors well outside our control. Norway’s power board capping the available power so we can only burn-in around 50 nodes at a time is a real example. Things shift mid-flight constantly, and the team has to absorb it without slowing down.
  • Extremely tight SLAs. Operators are on the hook to stand up customer capacity rapidly and remediate bad nodes well inside SLA — and our job is to give them the platform capabilities to hit those targets. Shipping slowly on what they need isn’t an option; it directly costs the business.
  • Fast and robust — both. Most teams get to pick one. We don’t. The platform has to move quickly and be extremely reliable, because the cost of failure is hundreds of millions of pounds of hardware sat idle or customers blocked.
We’re a small, elite team that punches far above its weight, and the standard reflects that. The rest of this doc is what lets that work.

​
What We Expect From You

Joining this team isn’t about being assigned tickets and executing them. That part has been commoditised — AI can carve up and ship well-scoped tickets faster than a human can. What’s valuable now is people who can own entire scopes and verticals of work. Concretely:
  • Own the problem, not the ticket. There’s a problem area. You figure out the shape of it, what the long-term target state should look like, and the path to get there. The tickets fall out of that thinking, not the other way around.
  • Drive change through people. Most real work crosses team boundaries. Other teams are busy and have their own competing priorities — it’s on you to build the relationships, navigate the priority calls, and find a pragmatic way to make the problem go away. That might be a short-term patch now plus a documented, planned, and enforced long-term fix, or negotiating the room you need to land the change properly.
  • Don’t stall when blocked. If important work hits a wall — including a wall sitting on another team — doing nothing is not OK. Find a path forward, or very clearly flag the risk and pull in whoever can help drive it. A blocker quietly killing momentum is the worst failure mode on this team.
  • Carry several things at once. You’ll juggle multiple workstreams in your head simultaneously. Be proactive about reporting what you’re covering and where you’re at, so nobody has to chase you for status.
  • Be pragmatic — perfect is the enemy of good. We almost never get to do a slow, clean migration. Find the shape of the target state, communicate it to the team, then attack the 80/20s that reduce business risk fastest. By the time you’ve hit those, something more critical will have popped up — that’s the steady state. Stay nimble and shrink problems over time.
  • Lift the whole team. Every engineer here operates as a tech lead — that’s the bar, not a stretch goal. Don’t wait to be handed work: observe whole areas, look for ways to lift quality and velocity, and if you see a teammate underwater, step in and take weight off them. Be wary of other people’s time when you need their input — go to the right person with the right opinion, don’t spray it across whole channels. And often it’s faster to delegate a carved-up piece of work to an AI agent than to another human — use that.
High quality, high pace, eyes up across the whole problem space.

​
The Four Execution Mechanisms

Given the constraints above, the four mechanisms below are how we actually succeed. They follow Tom’s Execution Guidebook, and they’re the levers a small team uses to ship under pressure without things breaking. Treat them seriously — they’re not nice-to-haves. For every piece of work, ask yourself: what’s the most efficient route to making this problem go away?

​
1. Decide fast

Don’t let decisions sit and stall a workstream. When you hit a decision point, work out who you actually need in the room, pull them in, and push the call through.
  • For reversible (two-way door) decisions, the bar for alignment is lower — make the call with the input you’ve got and revisit if it turns out wrong. The cost of being slightly off is tiny.
  • For irreversible ones, do invest in proper alignment — get the right expertise in the room before committing. The aim is days, not weeks.
  • When you feel stuck, ask “what decision is actually blocking me, and who do I need?” and pull them in. Don’t sit on it silently.
Bias towards momentum, but not at the cost of skipping the people you genuinely need.

​
2. Compress feedback loops

Every cycle of iteration — code, review, alignment, testing — should run in minutes, not hours. If iteration is slow, everything else gets slow with it.
  • If you find yourself running the same manual sequence three or four times, automate it.
  • PR reviews should never sit for days. The expectation is same-day for small-to-medium PRs, and within hours for the smaller ones. Larger PRs that touch core architecture decisions deserve proper thought and shouldn’t be rushed — but they shouldn’t sit either.
  • If alignment is dragging across week-long Slack chains, pull a 30-minute call.
  • Local dev, tests, and deploys should run in minutes.
When you start any task, ask: “what feedback loops will slow me down here, and which can I shorten before I start?” Sometimes that’s a small investment — a faster local environment, a better test fixture. Sometimes it’s bigger — simplifying a piece of architecture so the loop is shorter forever. Both are worth it. The diagnostic: when a production bug shows up, how long does it take to find the fix? If the answer is days instead of hours, the friction is somewhere — find it and kill it.

​
3. Build solid foundations

Good architecture is what makes everything else fast. Favour composition, strong separation of concerns, and cheap rollback (feature flags help a lot here). Mistakes should be cheap to fix — you swap a component, you don’t fight a system. AI tooling works well when patterns are clear and consistent. It doesn’t when the codebase is a mess. Investing in clean structure up front is what lets both us and the agents we use keep moving fast. For larger design decisions, write an ADR under docs/adr/: it’s a good way to collaborate with the team and leaves an audit trail of the reasoning. The nuance: “just do the simple thing” doesn’t always apply. Good software design patterns are worth the investment — they’re the foundation that makes everything else fast.

​
4. Cut scope ruthlessly

Build only what matters. Complexity is a cost, not a capability. Two questions to ask constantly:
  • “Do we actually need this?”
  • “What’s the minimum path to get this working end-to-end?”
Ship the critical path first. Prove what matters through delivery, then layer on the rest only when it’s genuinely needed. The exception: investing in architectural foundations that compound across the platform. When someone proposes a new abstraction or a better pattern, the question isn’t “can we ignore it?” — it’s “does this give us compounding leverage everywhere, or is it overhead we’ll carry forever?” Be generous about the first, ruthless about the second. Smaller ships are faster to build and easier to turn around when we took the wrong direction. Scope creep is normal — the courage piece is pushing back on it, admitting uncertainty, and abandoning work you’ve already done if that’s the right call. That’s correct behaviour, not waste. Most of it comes down to noticing friction as it happens and fixing it rather than working around it. That’s the habit that separates teams that ship from teams that stall.