The Embedded Engineering Team Operating Contract: Tools, On-Call, Headcount Curves, and the Three Times We Fired Ourselves From a Meeting

What "embedded" actually means in practice (and how it differs from project work)

Embedded means we work inside the client's tools, calendar, and decision loop rather than behind a statement of work. Practically: their Slack, their issue tracker, their sprint cadence, their on-call expectations, their release calendar. There is no handoff meeting because there is no handoff. The unit of delivery is the roadmap, not the deliverable.

The difference shows up fastest in how work arrives. On a project engagement, work arrives as a signed scope and changes arrive as change requests. On an embedded engagement, work arrives the way it arrives for an in-house team: a support ticket that turns out to be a data model problem, a partner who needs an API by the end of the month, a regulatory question that reshuffles the quarter. We have run this model for multi-year engagements with clients in the US and UK, some spanning six years and a dozen interconnected systems, alongside shorter fixed-scope builds we deliberately scoped as projects precisely because they did not need this model.

The trade-off is real and worth naming. Embedded teams absorb ambiguity, which is exactly what a founder without an internal engineering org needs. They also absorb accountability that a fixed-scope contract would have made legible. Most of what follows is machinery we built to keep that accountability visible.

• • Project engagement: scope defined up front, change requests, defined end date, handover artifact at the close.
• • Embedded engagement: rolling roadmap, client-owned backlog, no handover event, continuity is the product.
• • Signal you need embedded: more than half your engineering questions in a month are "should we" rather than "can you build".
• • Signal you need project: the thing has a clear finish line and a named owner on your side after launch.

Which tools each team lives in, and why we never make clients use ours

We live in the client's tools, without exception. Some accounts run in Slack and Jira, others in Slack and Linear alongside a client's internal engineers, others in whatever lighter board a small operations team already uses. Our internal tooling exists for staffing and invoicing, never for client delivery work. Splitting the source of truth is how context gets lost.

The rule that makes this work is that there is exactly one backlog per product and the client owns it. If one of our engineers discovers a piece of technical debt, it gets written as a ticket in the client's tracker with a business-readable justification, not tracked on a private list we bring to a quarterly. That means the client's board, their investors, and any engineer they hire later can read the entire history of what was built and why in one place, including the parts that make us look bad.

The practical cost is onboarding friction. Every engineer joining an account needs accounts, permissions, and time in someone else's conventions. We treat that as a fixed two-week ramp with a named buddy on the account rather than pretending someone can be productive on day one. The compensating benefit is that when a client hires their own first engineer, that person inherits a complete, native record rather than an agency export.

Who owns sprint planning: the founder, the client's product lead, or us

Prioritisation is always the client's. Sequencing and estimation are always ours. The founder or product lead decides what matters this sprint; we decide the order within it, what has to be built first for technical reasons, and what a realistic commitment looks like. When those two overlap badly, we surface the conflict in planning rather than quietly resolving it in code.

The shape of that split changes with the client's stage. In the early years of a founder-led company, the founder usually runs prioritisation directly and one of our engineers facilitates planning. As a product function grows, planning ownership moves to their product lead and our role narrows to estimation, technical sequencing, and flagging dependencies across systems. In operations-heavy businesses, priorities are often driven by physical constraints rather than a roadmap document: delivery windows, perishable stock, partner onboarding dates. And when we sit inside a larger existing engineering org, sprint ownership stays entirely with their internal leads and our engineers take work from the same board as everyone else.

The written version of this split matters more than the meeting. We keep a short escalation contract per account that names which decisions the founder owns and which we take. It is the same principle we wrote up in our escalation ladder post: decisions get sorted by reversibility, spend, compliance exposure, and customer visibility, not by seniority.

On-call, escalation windows, and working across European, UK, and US time zones

Our working day in Europe overlaps the UK by roughly seven hours and the US East Coast by three to four. On-call is a rotation across the engineers already on an account, not a separate duty team, because whoever gets paged needs to know the system. Severity determines the window: production down gets an acknowledgement inside the overlap and out-of-hours coverage by prior agreement, everything else waits for the next working morning.

We define three severities per account and write them into the engagement, not into a generic SLA template. Severity 1 is anything that stops money, samples, or deliveries: a failing payment path in a consumer finance app, a blocked diagnostic result release, a delivery route that will not generate. Severity 2 is degraded but working, which means it gets picked up first thing the next morning. Severity 3 is everything else and goes into the sprint. The single most useful thing we did was write down what each severity means in that specific business's language, because "critical" means something different in regulated diagnostics than it does in a marketplace.

Out-of-hours coverage costs money and we say so up front rather than absorbing it silently. For clients with real overnight exposure, we agree paid standby. For clients without it, we agree honestly that a Saturday incident is a Monday fix, and we build the system so that is survivable: queued writes, idempotent retries, and alerting that distinguishes "a customer is stuck" from "a background job will catch up on its own".

• • Severity 1: revenue, patient safety, or fulfilment is blocked. Acknowledged same day, out-of-hours by agreement.
• • Severity 2: degraded function with a workaround. Picked up at the start of the next working day.
• • Severity 3: bugs, cosmetic issues, minor data corrections. Enters the sprint through the normal backlog.
• • Rotation rule: only engineers currently working on the account are in the rotation for that account.

Headcount curves and the week a client hires their first internal engineer

Embedded headcount is not flat. Accounts typically start with two to three engineers through the build phase, expand during a heavy integration or launch period, and settle into a smaller steady-state team once the system is live and the roadmap is incremental. The most important transition is the first internal hire, which should shrink our footprint deliberately, not accidentally.

When a client hires their first internal engineer, we run a fixed sequence in their first weeks rather than a vague "knowledge transfer". Week one, they get the deploy pipeline and the ability to ship a small change to production themselves, because nothing transfers ownership like a merge. Then support triage moves to them, so they see the system through its failures. Then a service or subsystem transfers outright, with our engineer moving to review-only on that area. On-call is last, because paging someone who has not yet been surprised by the system is unkind and unproductive.

The mistake we made early was treating the first internal hire as a threat to the engagement rather than the point of it. The correct posture is to make yourself progressively less necessary in areas where an in-house engineer is better placed, and to concentrate on the parts that genuinely need continuity across years: integration contracts, data models, compliance-sensitive paths, and the archaeology of why a decision was made five years ago.

• • Week 1: repo access, local environment, deploy pipeline, one small change shipped to production.
• • Week 2 to 3: support triage ownership, with our engineer as second responder.
• • Week 4 to 6: one subsystem transfers outright, our engineer moves to code review only.
• • After the first incident they handle end to end: they join the on-call rotation.

Ceremonies we join, ceremonies we decline, and the three times we fired ourselves from a meeting

We join standups, sprint planning, retros, and incident reviews. We decline recurring meetings where our presence is decorative: company all-hands, most sales pipeline reviews, and design critiques where no engineering constraint is in question. Three times across long-running engagements we removed ourselves from a standing meeting we had been sitting in for months, and each time it improved the account.

The first was a daily standup where our engineers were the only people speaking and the internal team had drifted to async updates. We were performing visibility rather than creating it. We proposed a written daily update in their Slack channel and kept one live sync per week, and blocker resolution actually got faster because blockers were written down instead of narrated. The second was a weekly marketing and growth sync we had been invited to "for context". After two months the only engineering-relevant output was a handful of tracking requests, so we left and asked for those as tickets. The third was a recurring architecture review that had outlived its trigger: it had been created during a migration, and once the migration finished, it became a meeting looking for an agenda. We replaced it with a rule that any change touching cross-system contracts requires a written design note and two named reviewers.

The general principle is that an embedded team should be ruthless about removing its own meetings and generous about writing things down. Every meeting we left was replaced by an artifact: a daily written update, a ticket type, a design note requirement. Leaving a meeting without leaving an artifact is just disappearing.

The three failure modes of embedded work, and what we changed after each

Embedded engagements fail in three recognisable ways: the team becomes invisible to the board, prioritisation creates dual loyalty, and knowledge concentrates in one or two people. All three are structural rather than personal, and all three are fixable with reporting and staffing changes rather than with better intentions.

The invisible-to-the-board problem happens when work is genuinely going well. Everything ships, nothing breaks, and the people approving the budget see an invoice with no narrative attached. We fixed this with a monthly written summary in the client's own tools: what shipped, what broke and why, what we chose not to do, and where the next quarter's risk sits. It is written for someone who was not in a single standup. Clients have forwarded these directly to investors, which is exactly the test they should pass.

Dual loyalty on prioritisation is subtler. When an agency estimates the work and also influences what gets picked, there is an incentive shape nobody enjoys naming. Our answer is the split described earlier, plus a habit of writing down the cheaper alternative we did not get paid to build. Knowledge concentration is the third and most dangerous: when one engineer holds the model of a system, the client's continuity risk is our staffing risk. We changed to a rule of at least two engineers with production context on any long-running account, rotating who leads a subsystem, and requiring that architectural decisions live in the client's repository as written notes rather than in a person's head. If an engagement ends, everything needed to run the system should already be in the client's hands, which is also how we structure code ownership contractually.

The decision-authority split described here is written up in full in our escalation ladder, which sorts technical decisions by reversibility, spend, compliance exposure, and customer visibility.