Ways of Working

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.

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.

Yes this was written with the help of AI.

But it was based on my own prompting, I’ve read it all and on the basis of decades of experience, it reflects my views. My views aren’t always right, of course, but see above; I think clarity and consistency are more important. If you disagree with something or think it can be improved then I’d very much welcome a discussion about it, 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).

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.