Software that earns the trust the business has to place in it — by being delivered on a cadence you can plan around, on a foundation your team can actually maintain.
§ 01 ·
Most of the work is not the visible features; it is the foundation: the code review, the test pyramid, the observability, the delivery cadence, the engineering operating model.
When that foundation is right, the features ship on time and the team can stay small. When it is not, the team grows and the features still slip. The four phases the firm uses to do this work are on the How we work page.
§ 02 ·
Numbers from the firm's own engagements over the last several years. Every number has a basis: `engagement data` (measured from real engagements), `design heuristic` (a working target the firm uses to plan), or `target` (a posture the practice is designed to maintain).
§ 03 ·
The questions we hear most often, in the order they tend to come up.
Delivery is shipping features. It is what the business can see. Engineering is the system the delivery runs on: the test gates, the deployment pipeline, the observability surface, the on-call model, the review culture.
Most engineering problems are delivery problems that have not been fixed yet, and most delivery problems are engineering problems that have not been diagnosed yet. A feature that ships on time is the visible result of a foundation that is working.
Most engineering engagements run between three and nine months. The framing phase (the delivery assessment) is four to eight weeks; the delivery model and reliability work is the bulk of the early engagement; the operating-model work is ongoing. The total horizon is set in the framing session and revised only by mutual agreement.
Engagements are priced against the delivery assessment produced in the framing phase. The cost depends on the size of the system, the depth of the observability work, the on-call model the work needs, and whether the engagement includes a reliability-model component. A typical range for a multi-phase engagement sits in the low-to-mid six figures; the final figure is set in the scoping call after the framing phase.
The first 30 days are the framing phase: a delivery assessment that measures lead time, change-failure rate, time-to-restore, deployment frequency, the on-call load, the test pyramid, and the code review load. The output is a small document that scopes the rest of the engagement and names the order in which the foundation work should happen.
By changing the foundation, not the headcount. A smaller team with a working test pyramid, a working observability surface, a working deployment pipeline, and a working on-call model will out-deliver a larger team with a broken one. Adding people to a system with a broken foundation is the most expensive way to slip a deadline.
The work is unglamorous and most of it. A working foundation is what lets a small team carry the features the business needs. A broken foundation does the opposite.
§ 04 ·
What each phase produces in an engineering context is on the How we work page.
A flat list of the artefacts a software engineering engagement produces. The full shape of the engagement is on the [How we work](/services/methodology/) page.
A measured picture of where the engineering work is today: lead time, change-failure rate, time-to-restore, deployment frequency, the on-call load, the test pyramid, the code review load. The assessment is the basis for the rest of the engagement.
Names the branches, the test gates, the deployment pattern, the rollback story, the observability surface, and the small set of paved roads the team has agreed to use. Deliberately does not specify the implementation in detail.
The SLOs, the error budgets, the on-call rotation, the runbooks, the escalation paths, and the post-incident review discipline. The reliability model is what lets the business plan around the system.
The review cadence, the code-review standard, the on-call compensation model, the paved-road pattern library, the escalation paths for the things the team has not seen before. Names what the operating model explicitly does not do.
A short, durable document recording what happened, what was assumed that turned out to be wrong, and the engineering change made so the same failure mode cannot happen the same way again.
§ 06 ·
Six failure modes we have seen repeatedly, across software engineering engagements of every size. Each one motivates a specific choice in how we work.
Cadence is a property of the team, the architecture, and the test gates, not of the CI system. A faster CI on a broken foundation produces faster broken changes.
When end-to-end tests are the only fast feedback, every change either takes too long to verify or ships untested. The cost of catching a bug late is orders of magnitude higher than catching it at the unit-test layer.
A dashboard that displays the wrong metric is a confidence-builder. An instrumented system that the team can query is what debugging requires. Most on-call pain is solved by changing the instrumentation, not by adding dashboards.
The review is supposed to change the system, not the on-call rota. Skipping the change is how the same Sev-1 happens twice — usually on a different on-call rotation.
Adding people to a system with a broken foundation is the most expensive way to slip a deadline. The new people cannot deploy reliably either, and the foundation work is now competing with the new feature work for attention.
A pattern library that is not also a default, tested, and supported implementation is a poster. Teams will route around it, and the paved road will become documentation the team carries.
The thing we were not expecting was how much of the work was observability. Once the team could see what the system was doing, half the on-call pain disappeared, the rest became tractable. We did not add a single new feature. We made the existing ones reliable.
§ 08 ·
Public frameworks and writing that inform the firm's practice.
The empirical case for the practices that actually move delivery performance. The four DORA metrics are the measurement model the practice uses.
The industry baseline. The performance distribution the report produces is the reference for the firm's own measurements.
The pattern language for stability patterns, integration points, capacity, and the failure modes that show up in production — the operational reference we lean on most often.
The end-to-end treatment of the deployment pipeline as the spine of the engineering practice. The patterns are still durable; the tooling in the book is not.
The four team types and three interaction modes map cleanly onto the engineering operating model. We treat it as the organisational sibling of the engineering work.
If you are weighing a delivery transformation, responding to a reliability incident, or strengthening the engineering operating model of an existing team, the firm is useful at that boundary. A short conversation is the right next step.
Start a conversation