Skip to main content
BuildLogicStudio
Begin
Index / Journal / The one-engineer-per-engagement rule

The one-engineer-per-engagement rule

On why every BuildLogicStudio engagement is owned end-to-end by a single engineer, and what we have learned about the trade-offs.

T The one-engineer-per-engagement rule

The studio runs on a rule that sounds like a constraint and is actually the most freeing decision we have made: every engagement is owned by a single named engineer, end to end. The engineer who answered your first email writes the engagement letter, runs the kickoff, makes the two visual routes, builds the production code, and pushes the deploy. On Atelier Builds the engineer is paired with one other engineer for the application half, but the public-facing surface is still one person.

The case for the rule is in the kinds of conversations it makes possible. When the engineer owning the build is also the engineer who wrote the engagement letter, every conversation about scope is grounded in the same person's memory. There is no telephone game between an account manager and an implementer. There is no junior engineer in the middle re-interpreting a senior engineer's notes. The conversation between the client and the engineer is direct, technical, and short.

The case against the rule is the case of capacity. An agency that runs one-engineer-per-engagement cannot scale by hiring junior engineers and putting them on overflow. We can scale only by hiring more senior engineers, and senior engineers do not appear quickly. The result is that the studio grows slowly — four engineers in year five — and that the studio takes fewer engagements than its name might suggest. Both of those are real costs. Both are costs we have decided are worth paying.

The trade-off that matters less than people think is the bus-factor argument: what happens if the engineer owning the build is unavailable? In practice, in five years and roughly seventy engagements, this has happened twice and both times the project lead and a second engineer were briefed within a day. The runbook, which is a deliverable on every build, is what makes that hand-off cheap. The hand-off is rare enough that it does not justify a different operating model, but the runbook is what makes the rule survivable when the hand-off does happen.

Have a project that needs this kind of attention?

Write to us. The engineer who replies is the engineer who would run the engagement.