The engagement is sold. Three workstreams are running, the client's steering committee meets every second Thursday, and one of those workstreams is now a software build that the consultants running the program are not going to write themselves. An engineering team is coming in. The question that decides whether this goes well has nothing to do with the code: it is whether the client experiences one program or two vendors. Get the operating model right and the consultants keep the relationship while the engineers keep the system, and the client sees a single coherent effort. Get it wrong and by week six the client is fielding two versions of status, two definitions of done, and a growing suspicion that nobody is holding the whole thing.
This is written for the engagement manager who has to make that work while also running everything else. Precision Federal builds the software in arrangements like this. What follows is the operating model we use, stated plainly enough that a firm can adopt it with any engineering partner, including one that is not us.
The one decision that sets everything else
Before reporting lines, before tooling, before the first standup, one question has to be answered in writing: who does the client hold accountable for the system working. There are only two honest answers, and picking either one is fine. Refusing to pick is what breaks programs.
In the first model, the consultancy is accountable to the client for the whole program including the build, and the engineering partner is accountable to the consultancy. The client has one throat to choke. Status flows through the engagement manager. The engineers are, from the client's point of view, part of the program team. This is the ordinary arrangement on commercial work and it is the one most firms want, because the relationship stays whole.
In the second model, the engineering partner holds a direct scope with the client, usually because a separate contract, a separate funding line or an independence constraint requires it. The consultancy still runs the program, but the client signs the build separately and the engineers report technical status directly. This is common on public sector work and on programs where the build is funded from a capital budget while the advisory work is funded from an operating budget.
What determines whether an embedded arrangement holds together
Editorial weighting, illustrative rather than measured. The last row is low on purpose: tool alignment is the thing programs spend the most time on and the thing that matters least.
What does not work is the arrangement where the consultancy tells the client it owns delivery while the engineering agreement makes the partner responsible only for hours. That gap is invisible until the first missed date.
Reporting lines that survive a bad week
An embedded engineering team has two reporting lines and they carry different traffic. The delivery line runs from the engineering lead to the engagement manager and carries scope, schedule, risk and anything that changes a commitment to the client. The technical line runs inside the engineering team and carries architecture, code review, incidents and the hundred decisions a day that nobody outside should be asked to arbitrate.
Draw the boundary by asking whether a decision changes what the client was promised. Choosing a message queue does not. Deciding that the ingest cannot handle the client's file format without a two-week change to the upstream export does. The first belongs entirely to the engineering lead. The second reaches the engagement manager the day it is known, not at the next steering committee.
The inverse failure is an engineer who treats a schedule risk as a technical matter and fixes it quietly. The rule that prevents it belongs in the operating agreement: anything that could move a client-visible date is reported the day it is suspected, not the day it is confirmed.
The failure mode here is an engagement manager who asks to review technical decisions. It feels like diligence; it produces a team that stops deciding. The correct instrument is not review but a standing constraint list written once: the target environment, the supported technologies, the data boundaries, the accessibility requirement, the date. Inside it the engineers decide.
Cadence: four meetings and no more
Programs accumulate ceremonies. The version that works is short and each meeting has one job.
A daily fifteen minutes inside the engineering team. The engineering lead runs it. The engagement manager is welcome and almost never needed. Its only product is a list of blockers, and any blocker that requires the client to do something is copied to the engagement manager within the hour.
A weekly delivery review, forty-five minutes, engineering lead and engagement manager. This is where the two teams reconcile. The agenda is fixed: what shipped, what is at risk, what the client owes us, what we owe the client, and any change to scope. It produces one written update, and that update is the input to whatever the client sees. Written, so that a week where nobody can meet still produces the artifact.
A client-facing demonstration every two weeks. Running software, on the real stack, with real or realistic data. Not slides about software. This is the single most useful discipline in an embedded arrangement, because it converts an abstract argument about progress into an observable fact, and because a client who has seen the system every two weeks does not get a surprise at the end. The consultants run the meeting and frame the business meaning. An engineer drives the screen. That split is deliberate and it holds the model together in front of the client.
A phase gate at the end of each increment. Decision-oriented, attended by whoever can approve money and scope. It signs off the increment's acceptance criteria, or does not, and confirms the next scope.
Branding, attribution and how the client is addressed
Decide the visibility posture before the engineering team meets the client, and write it down in one sentence.
Three postures are common. Fully under the consultancy's brand, where engineers appear as program team members and the partner firm is not named to business stakeholders. Named partner, introduced openly, keeping its own identity. And a mixed posture, where the partner is named to the client's technology organization, which finds out anyway from source control, while the business-side framing stays with the consultancy.
On public sector work the calculus usually inverts. Where personnel and delivery capability are evaluated, naming the engineering firm with a real, described scope reads better than an anonymous pool of resources, and concealing who wrote the software sits badly next to a personnel evaluation. Decide before anything goes to the client, not after someone asks.
Any of the three is workable. What matters is that the posture is consistent everywhere the client can see: commit authorship, ticket assignees, cloud account names, meeting invitations and email signatures. A program that has decided on a name-free posture and then ships a repository full of commits from an unfamiliar domain has not decided anything; it has just delayed the conversation.
Communication rules that keep the relationship intact
The fear behind every embedded arrangement is that the engineers will go around the consultants. The way to prevent it is not to forbid contact, which is unworkable and slows delivery to a crawl. It is to separate contact by type.
Engineer-to-engineer contact on technical matters should be direct, frequent and unmediated. If our engineer needs to ask the client's platform team about a firewall rule, routing that through two account managers costs a day and creates nothing. Direct contact here is the difference between a two-week integration and a six-week one.
Anything touching scope, schedule, cost, satisfaction or the next phase of work goes through the engagement manager without exception. Not "usually." Without exception, including when a client executive asks an engineer directly in a hallway, and the answer to that question is a friendly redirect: good question, that is one for the program lead, let me connect you today.
Two more rules earn their place. First, no engineer commits to a date in front of the client. Dates are commitments and commitments belong to whoever holds the contract. An engineer can say what is technically required; the engagement manager says when it will be delivered. Second, bad news reaches the consultancy before it reaches the client, always, and with enough lead time that the two teams can agree how to present it and what the recovery plan is. A client should never learn about a slip from a channel the consultants have not seen first.
Access and security, which is where the calendar actually goes
The most common cause of a slow start is not technical difficulty. It is that on day one the engineers cannot reach anything. Access is a serial dependency and it is almost always underestimated, because the person estimating it has had access for two years and no longer remembers acquiring it.
Work backwards from the first commit. The team needs directory identity, source control, a development environment, credentials to each integrated system, a data set to build against, and network paths. Each has a separate owner and queue, and several require a signed agreement before the request can be filed.
Plan for the case where full data access arrives late. The mitigation is a synthetic data set built to the real schema in the first week from the data dictionary, which converts a blocking dependency into a parallel one.
| Access item | Typical owner | What it gates | Start it |
|---|---|---|---|
| Identity and directory account | Client IT, sometimes HR for screening | Everything downstream | Before the engagement is signed, if possible |
| Source control and CI | Client platform or engineering | First commit, code review, builds | Week one |
| Development environment | Cloud or infrastructure team | Anything that has to run | Week one, in parallel |
| Integration credentials | Each owning system's team, separately | Each integration, one at a time | Week one, one request per system |
| Representative data | Data governance, privacy, legal | Model work, validation, acceptance | Week one; build synthetic in parallel |
| Production deployment path | Operations and security review | Go-live only | Midpoint, so review findings are cheap |
Security posture is agreed at the same time and in writing: where client data may live, which people are named as authorized, whether anything may be copied to the engineering firm's own environment, whether any client data may be used to train or fine-tune a model, and what is destroyed at the end. On work destined for a federal environment, add the accreditation destination and the control set the system must satisfy, and build inside that boundary from the first sprint rather than porting a prototype into it later. Building in the wrong environment and planning to move is the single most expensive mistake available in this category of work, because the prototype that dies in security review is usually rewritten, not fixed.
Escalation: three levels, timed
Most escalation paths are a list of names with no clocks on them, which means the path is really "whenever someone gets frustrated enough." Put times on it.
Level one, inside the working teams, resolved within one business day. A blocker, a missing credential, a disagreement about an interface. The engineering lead and the consultancy's workstream lead own it. Most things end here.
Level two, engagement manager and engineering firm's delivery lead, resolved within three business days. Anything that changes scope, cost or a date, and anything at level one that did not clear in a day. The output is a written decision or an agreed change request, not a longer conversation.
Level three, the partner or executive sponsor on each side, within a week. Contract questions, a fundamental disagreement about acceptance, or a relationship problem. It should be rare, and it should never be the first time either executive hears about the issue.
Where the calendar goes in the first six weeks of an embedded build
Editorial weighting, illustrative rather than measured. The last row is low because status work belongs with the consultants, not the engineers.
The artifacts that keep two teams aligned
Meetings synchronize people who attend them. Artifacts synchronize everyone else, including the people who join in month four. An embedded arrangement needs a small number, each with a single owner and a stated update rhythm.
- The operating agreement, one page. Who is accountable to the client, the two reporting lines, the four meetings, the visibility posture, the communication rules, and the escalation path with its clocks. Written in the first week, signed by both leads, reread at every phase gate. Nearly every problem in this article is prevented by this page existing.
- The constraint list. The environment, the supported technologies, the data boundaries, the security destination, the accessibility requirement, the integration targets by product and version, and the fixed dates. This is the boundary inside which engineers decide without asking. Changing it is a decision, made at a gate.
- Acceptance criteria per increment, written as tests. Not adjectives. A measured threshold on a named data set, a response time at a stated load, a specific workflow completed by a named role, a deployment that runs from a clean checkout. Written before the increment starts and signed at its gate. This is the document that decides whether an argument at the end is a five-minute check or a three-week negotiation.
- The weekly written update. One page, same five headings every week: shipped, at risk, what we need from the client, what the client needs from us, changes. Produced by the delivery review, and the raw material for anything the client sees.
- A decision log. Every architectural or scope decision that would be expensive to reverse, with the date, the alternatives considered and the reason. Ten lines each. It costs a few minutes a week and it is the only defense against relitigating the same decision in month five with a different cast.
- The risk and dependency register, jointly owned. Specifically including client-side dependencies with named owners and dates, because those are the ones that slip silently and are hardest to raise politely without a shared document to point at.
- A live demonstration environment. Not an artifact in the document sense, but it functions as one: a running system anyone can look at, which ends more disputes about progress than any status report.
How we work inside your engagement
Precision Federal builds AI systems, data platforms, cloud infrastructure and full-stack web and mobile software, and we deliver them into production, including inside U.S. federal agencies where the system has to pass security authorization, handle controlled information and meet accessibility requirements. That federal delivery experience matters to a consultancy for two reasons: it is a route to government revenue for your clients, and an engineering team used to working under authorization requirements is disciplined about environments, evidence and handover in a way that pays off on commercial work too.
In an embedded arrangement, here is what happens. In the first week we sign the operating agreement, agree the visibility posture, file every access request in the order it gates work, and write the constraint list with your team and the client's technology lead. By the end of the second week there is a running skeleton in the target environment: it does almost nothing, but it builds, deploys and passes a test, which retires most of the risk that the environment is not what everyone assumed. Inside four weeks there is a working slice of the real workflow against real or synthetic data, shown in a client demonstration you run.
You keep everything that matters. You keep the client relationship, and we do not approach your client independently during the engagement or after it without your agreement. You keep the code and the intellectual property, transferred by a written present assignment rather than a work-for-hire recital, with our pre-existing tooling named, carved out and licensed to you perpetually so nothing in the delivered system is encumbered. You keep the data, which never leaves the boundary we agreed and is never used to train anything. You keep the framing and the analysis, which are yours and were never ours.
On pricing, the shape follows the certainty. Where scope is clear enough to define acceptance criteria, we price fixed increments against those criteria, billed at milestones, with a written change process for anything outside them, so the build has a number your finance lead can put inside the engagement price. Where the work is genuinely exploratory, a committed team for a fixed number of weeks with a hard stop and a written finding is more honest than a fixed price built on a guess, and we will say which one applies rather than quoting whichever is easier to sell.
The first step is one email with a one-page brief: what the client has decided and funded, the system the result must live inside named by product and version, what data exists and who can grant access, the security destination, the date that matters, and who can approve a scope change. We return a scoped, priced statement of work with acceptance criteria written as tests. No call required, and nothing about the brief commits you to anything.
Where these arrangements break
Two status stories. The consultants report green because the workstream plan is on track; the engineers report amber because an integration is at risk. Both are honest and the client hears chaos. The single written update, produced jointly, is the fix.
The engineers were bought as hours and asked for an outcome. If the agreement prices time and the expectation is accountability for a result, the gap surfaces at the first miss. Decide which is being bought and price it that way.
Access was assumed rather than requested. Four weeks of a twelve-week build spent waiting for credentials. Requests filed in week one, in dependency order, with a synthetic data path in parallel.
Acceptance is written in adjectives. "Production-ready," "accurate," "scalable." Acceptance never arrives because there is nothing to test against, and the engagement ends arguing about quality rather than criteria.
The client's own dependencies are never tracked. The build slips because a client team never delivered a specification, but the risk register only listed the engineering team's risks, so nobody raised it until it was late. Track both sides in one register with names and dates.
Handover is a document instead of a rehearsal. Whoever inherits the system should deploy it while the engineering team watches, before the final invoice. Anything else is a claim about knowledge transfer rather than evidence of it.
Bottom line
An embedded engineering team works when three things are written down in the first week: who the client holds accountable, what the engineers may decide without asking, and how bad news travels. Everything else in this article follows from those three. The consultants keep the relationship, the framing and the analysis. The engineers keep the system, the technical decisions inside an agreed boundary, and the obligation to raise a risk the day it is suspected. One status artifact, one demonstration every two weeks, and an escalation path with clocks on it will carry a program through the weeks when things go wrong, which is the only test that matters. Firms that draw this once and reuse it stop rediscovering the same problems on every engagement.
Frequently asked questions
Write a one-page operating agreement in the first week. It names who the client holds accountable for the system working, the two reporting lines, the meeting cadence, the visibility posture, the communication rules and an escalation path with time limits. Then file every access request in the order it gates work. The agreement takes an hour to write and prevents most of what goes wrong later, because almost every failure in these arrangements traces back to a question that was never answered in writing.
Yes for technical matters, no for anything else. Engineer-to-engineer contact about interfaces, credentials and integration should be direct and unmediated, because routing it through account managers costs days and produces nothing. Anything touching scope, schedule, cost, satisfaction or future work goes through the engagement manager without exception, and no engineer commits to a date in front of the client. Bad news reaches the consulting team before it reaches the client, with enough time to agree how to present it.
Decide before the first client meeting and be consistent everywhere. Working under the consultancy's brand is ordinary on commercial engagements, and a reasonable partner will expect it. If that is the choice, it has to hold in commit authorship, ticket assignees, cloud account names and email signatures, not just in meetings. On public sector work the calculus usually inverts, because delivery capability and personnel are evaluated and an anonymous resource pool reads worse than a named partner with a described scope.
Access, not technical difficulty. Directory accounts, source control, a development environment, integration credentials, representative data and network paths each have a different owner and a different queue, and several require a signed agreement before the request can be filed. Start the slowest first, usually screening and directory accounts. Build a synthetic data set from the schema in week one so that a privacy review returning in week five delays validation rather than all construction.
Whoever the assignment clause names, so write it down. Ask for a written present assignment of copyright rather than relying on a work-made-for-hire recital, because under 17 U.S.C. § 101 a commissioned work qualifies as a work made for hire only where there is a written agreement and the work falls within one of nine listed categories, and software is not among them. Pair the assignment with a named carve-out for the partner's pre-existing tooling and a perpetual license back so the delivered system is unencumbered.