A lot of our delivery happens through consulting partners. Our engineers ramp into their client engagements, ship the work, and roll off cleanly. The mechanics of that look different from a typical client-direct engagement.
Single point of accountability
The partner owns the client relationship; we own the technical delivery. That separation only works if there's no ambiguity about who calls what. We default to the partner setting scope and timeline; our team owns architecture decisions and delivery cadence within that envelope.
Match the partner's tooling
If the partner runs on Jira, we run on Jira. If they review code in GitHub, that's where we review. The fewer tool boundaries between our team and theirs, the less context-switching everyone does — and the faster the work moves.
Ramp matters more than skills
The technical skill is the table stakes. The differentiator is how fast someone gets useful in a new codebase. We optimize for that hard: every engineer has a personal "first 48 hours" runbook for new engagements, focused on shipping a tiny change end-to-end before they touch anything substantial.
Documentation is the deliverable
The point of an embedded engagement isn't to be irreplaceable. It's the opposite. We treat documentation as a first-class deliverable so the partner's team can run what we built without us. ADRs, runbooks, and "why did we do it this way" notes all ship with the code.
Roll-off is part of the plan
Every engagement has a defined end. We talk about it in week one. The transition is smoother when both sides expect it.