Ways of Working

Built from 30+ years of building software and specifically seven years scaling product and engineering at a PE-backed company: what worked, and what I’d do differently with a clean slate.

These documents describe how a product and engineering organisation operates. They are opinionated by design. Not every decision in them will be the one you would have made, but that’s not the point.

Shared alignment matters more than individual perfection.

A team where everyone follows the same agreed process outperforms a team where each person follows their own preferred process, even if some of those individual preferences are objectively better. Whether the team sizes items as S/M/L or uses Fibonacci numbers matters far less than everyone using the same approach. These documents exist to give everyone a common framework. If something needs to change, change it, but change it for everyone, deliberately.

Pragmatism over process.

Every process described here exists because the cost of not having it exceeds the overhead of following it. Where we’ve chosen not to mandate something (daily standups, story points, pre-merge PRs), it’s because we believe the overhead outweighs the benefit. If that balance shifts, the process should evolve. The goal is the minimum process that makes things work, not the absence of process, and not process for its own sake.

These are the defaults, not the ceiling.

The documents describe the aim and the standard operating mode. That doesn’t mean nothing ever changes. But change should be deliberate, considered, approved, and documented. Some rules can be broken under exceptional circumstances. The Head of Eng can override the backward-compatible migration requirement, the PM can escalate a Tier 1 to a Tier 2 mid-sprint, a Lead Dev can authorise fix-forward during an incident. The override mechanisms are defined because exceptions are expected. What isn’t acceptable is drifting from the defaults without noticing, or making exceptions that never get reviewed.

Scale the model to your headcount, don’t abandon it.

The structure described here (multiple product squads, a platform squad, a Staff Engineer, specialist PMs) is the full model at roughly 25–40 people. Most organisations are smaller, and plenty should stay that way. A smaller organisation runs the same operating model with the roles collapsed into fewer, more senior people: the Staff Engineer’s scope folds into the Lead Dev, discovery and analytics fold into the PM, platform work becomes an allocation rather than a squad, quality becomes a named owner inside the team rather than a separate function. Modern tooling makes that credible in a way it wasn’t a few years ago; one capable senior IC with good AI leverage genuinely covers ground that used to need two or three people.

What collapses is the bundle of responsibilities into a person. What must never collapse is the responsibility itself, or the clarity about who holds it. If nobody can name the single person accountable for quality, or for what gets built next, or for production at 2am, that responsibility has been dropped rather than merged. Team Structure sets out which role combinations work, which one to resist (PM and Lead Dev in the same head), what never collapses however small you are, and what should trigger splitting a role back out as you grow.

There are two strands, and the smaller one is not a lesser version.

Most of these documents describe a sprint-based model: a two-week cadence, refinement a sprint ahead, planning on the Monday. That is the right shape from about one squad upwards. Below five people it stops being right, because a team of three does not have a planning problem, it has a finishing problem. The Founding Team Operating Model is the same operating model run as continuous flow instead of sprints: work pulled one item at a time from an ordered queue, limited by work in progress rather than by a sprint boundary, with Slipdock as the orchestration layer that both people and AI agents take work from. The responsibilities, the tiering, the written artefacts and the second pair of eyes are all identical. Only the ceremony changes, and it changes a lot. Pick the strand that matches your size, and switch strands on a trigger rather than on ambition.

Above all else, be deliberate.

Do things for a reason. Choose an approach because you’ve considered the alternatives, not because it was the first thing that came to mind or the way it was done at your last company. If you can’t articulate why you’re doing something, stop and think about whether you should be doing it at all.

Drafted with AI, from my notes and my decisions.

Every rule in here is one I have run or chosen deliberately, and I can tell you why. That is also how I think AI should be used across a product and engineering team: it drafts, people decide. My views are not always right, and if you disagree with something or think it can be improved, I would welcome the conversation so we can improve it together.

How to Use These Documents

Joining the team? Start with the Engineering Process and the Team Structure document. Read the Operating Principles cheatsheet. Then read the documents relevant to your role.

PM? Engineering Process → Product Process → Product-Engineering Interface cheatsheet → Artefact Requirements cheatsheet.

Developer? Engineering Process → Engineering Process cheatsheet → DevOps Principles (container standards and deployment sections).

Lead Dev? All of the above, plus Team Structure (career progression and growth responsibilities) and Project Sizing.

Platform squad / DevOps? Engineering Process → DevOps Principles → AI Use Case Catalogue (platform-relevant use cases).

Founding team of 1–4? Start with the Founding Team Operating Model and its cheatsheet. That is your strand, and it is self-contained enough to set up a board and start working from. Then read Product Process for the tiering, Project Sizing for the size bands, and Team Structure on what must never collapse however small you are.

Small team, around one squad (5–12)? Read everything as the destination, then read Team Structure on flexing down before you decide what to adopt now. The Operating Principles cheatsheet and Engineering Process cheatsheet are the compressed version of the model and are usually the right place to start at small scale. If you are at the bottom of that range and ceremony is costing more than it returns, the Founding Team Operating Model describes the lighter strand and when to graduate out of it.

Head of Eng / Head of Product / CTO? Everything, but start with the Operating Principles cheatsheet for the philosophical foundation, then the Team Structure and Product-Engineering Interface for the organisational dynamics.