Engineering handbook
The engineering handbook, published as written
Most companies will tell you they have engineering standards. This is ours — the same document our teams are held to, published as written, with nothing rewritten for the website. Read it before you hire us. It is a fair basis for holding us to account afterwards.
Teams here own their own methodology — there is no central process office issuing decisions. That only works if the standards are written down and non-negotiable, because much of what we build carries financial transfers, health records or corporate data, and is expected to run for a decade.
How to read it
How to read it
It reads like what it is: a working document, written to be argued with by the people it binds. The voice shifts between chapters because more than one person wrote it. Some chapters run to a thousand words; Monitoring is four lines, because the standard says four lines. We would rather show you that than pad it out into something we do not hold anyone to.
What is here is the floor, not the ceiling. It sets what a team may not fall below — environments, backups, alerting, a maintained backlog, a named owner. What a team does above that floor is the team’s own call. That is the point of teams owning their methodology in the first place.
Publishing it changed the formatting and nothing else. Moving off WordPress meant repairing headings, links and image markup, and each chapter carries a one-line summary written for the index. The standards themselves are as our teams read them.
- 01
Product Management
Every team needs a Product Owner, and four rules that make one effective: know the users, keep the backlog real, split stories small, and write acceptance criteria. Read - 02
Long-term Maintainability & Code Quality
Most of what we build has to run for 5 to 15 years. The five non-negotiables that follow from that: no dead code, no untested code, and refactoring always allowed. Read - 03
Starting a New Team
What a new team settles first: its own methodology, who owns adherence to it, real Product Ownership, and which technologies to reach for before building anything. Read - 04
Automation
Why we treat the build itself as an engineering product: install and upgrade in one or two commands, sane defaults, tooling that makes new people productive. Read - 05
Running Team Maturity Initiative
How team maturity gets implemented when every team owns its own methodology. Product Owners, training, and the environments a team needs to run it. Read - 06
Monitoring
Our production baseline: monitor every part of the ecosystem, alert on it, give the responsible people access, and be ready to fix problems around the clock. Read - 07
Developer Productivity
What we expect every developer to know and why one unproductive person changes a whole team — plus the two months we give anyone new to get there. Read - 08
ROI
Spending a client's money well is an engineering job: change a costly approach unprompted, prefer existing libraries, drop stories not worth building. Read - 09
Etiquette Guidelines
The small things clients notice: punctuality, being visibly present, cameras on, and what your background says before you speak. Read
More of how we work: How we work Engineering archive Research
Hold us to it
The handbook is the concrete version of the pitch.
If you are weighing us up, judge the answer we give you against these standards, because that is one of the things they are for.