A ten-person specialist team inside a two-hundred-person program is not a small version of the program. It is a different kind of object, and the operating model that runs the program will not run it. Apply the full ceremony and the team spends a third of its capacity in status meetings that exist to coordinate work it is not doing. Apply nothing and the team disappears into the org chart, produces something nobody integrated, and surfaces three weeks before a delivery with a problem the program manager could have solved in a day. Both failures are common, and both are failures of design rather than of people.
This is written for the program manager or chief engineer who has just brought a specialist subcontractor onto an active program and has to decide, in the first two weeks, how the arrangement actually works. The decisions are not exotic. There are about eight of them, they can be written on two pages, and getting them right early is worth more than any amount of management attention later.
What the specialist team is for, stated precisely
Start by naming the reason the team is there, because the operating model follows from it and the reasons are not interchangeable.
Sometimes the specialist team exists to build a component the program needs and the core team cannot staff quickly: a model, a data pipeline, a search layer, a mobile client, an integration into a system nobody on the program has touched. That is a bounded deliverable with a start and an end.
Sometimes it exists to carry a workstream that runs the length of the program, with its own backlog and its own customer stakeholders. That is a durable capability, and it needs a different reporting shape.
Sometimes it exists to recover something red, which is its own discipline and its own article.
And sometimes it exists because the proposal named it, the customer scored it, and the program is now obliged to give it real work. That last case is more common than anyone admits, and it is the one that fails most reliably, because nobody ever wrote down what the team was supposed to produce. If that is the situation, the fix is to write the scope now, honestly, and to make it something the program actually needs. A named subcontractor with a defined scope reads well to a customer. A named subcontractor with no scope reads worse than not having named one.
What actually determines whether a specialist sub is productive
Editorial weighting, illustrative rather than measured. The last row is deliberately low: full ceremony attendance is the most expensive and least useful integration mechanism available.
The first two weeks decide the next twelve months
The single largest waste on programs of this shape is access. A specialist team that cannot reach the repository, the build system, the development environment or the data spends its first month reading documentation and writing design notes nobody asked for, and the program pays full rate for it. Worse, the team's early impression of the program is that nothing works, and that impression is durable.
Access is a program management problem, not an IT ticket. It has three parts and each has a different lead time. Identity and account provisioning runs on the customer's cycle and cannot be compressed by wanting it faster, so it starts before the subcontract is signed rather than after. Repository and pipeline access runs on the prime's own cycle and can be done in a day if somebody owns it. Data access runs on whatever agreement governs the data and is the one most often discovered late, because everybody assumes somebody else checked.
The fix is a written onboarding sequence with a named owner for each item and a date. It is not a sophisticated artifact. It is a table with about fifteen rows, and it is the highest-return two hours a program manager will spend on this relationship.
Second, in the same two weeks: a written scope. Not the subcontract statement of work, which is a contracting document, but a technical scope the engineers on both sides agree describes the same thing. What the team builds. What interfaces it owns. What it does not touch. What "done" means for the first increment, expressed as something testable. Two pages. Signed by the chief engineer on the prime side and the technical lead on the sub side. Nearly every dispute that arrives in month six was preventable by this document in week two.
Reporting: one line up, full detail sideways
The reporting model that works has an asymmetry in it. The specialist team reports a small amount of information up the program's management chain, and a large amount of information sideways to the engineers it integrates with.
Upward, the team appears in the program's status reporting as one workstream. Its lead provides the same fields every other workstream lead provides: progress against the committed increment, risks with owners and dates, dependencies on other teams, and anything that needs a decision. One slide, or one section in whatever the program already uses. The team's lead attends the program-level status meeting the same way any other workstream lead does. This is the entire management overhead, and it should stay that small.
Sideways, the volume is much higher and the mechanism is different. The specialist team's engineers work in the same channels as the engineers whose systems they touch, review each other's code, attend each other's design discussions when the topic is shared, and keep their design documentation in the same place as everyone else's. This is where integration actually happens, and it costs almost nothing because it replaces communication that would otherwise happen through the management chain slowly and lossily.
The failure pattern here is a program that inverts the asymmetry: heavy management reporting, no engineer-to-engineer contact. Those programs produce a subcontractor that is perfectly visible in status reports and completely disconnected from the system, and the disconnection is discovered at integration.
Sprint alignment without ceremony collapse
Programs of two hundred people usually run some flavor of scaled agile, with a planning event on a fixed cadence and a set of ceremonies that exists to coordinate many teams. A ten-person specialist team does not need most of that, and forcing it to participate fully is a real cost.
The useful rule is that the specialist team synchronizes at the program's boundaries and runs its own rhythm in between. It participates in the program increment planning event, because that is where dependencies are made visible and commitments are set. It participates in the integration and demonstration event at the end of the increment, because that is where its work meets the rest of the system. It attends the cross-team dependency forum when it has a dependency, and skips it when it does not.
Between those points it runs its own sprints, on its own length, with its own review. If the program runs two-week sprints and the team's work has a natural one-week rhythm, that is fine so long as the team's increment boundaries land on the program's. What matters is that the artifact the program consumes arrives when the program expects it, in the state the program expects, not that the team's internal calendar matches.
One exception worth stating: the specialist team commits to the program's integration cadence absolutely. If the program integrates on Thursday, the team's code is in the shared branch and green on Thursday. Autonomy in method, no autonomy in the integration contract.
| Mechanism | Specialist team's participation | Why |
|---|---|---|
| Program increment planning | Full, with the technical lead and at least one engineer | Dependencies and commitments are set here and nowhere else |
| Program status reporting | One workstream line, same fields as every other lead | Visibility to management without consuming engineering capacity |
| Cross-team dependency forum | When the team has an open dependency; otherwise skip | Attendance without a dependency is pure overhead |
| Daily standups | Its own; not the program's | Ten people coordinating with each other, not with two hundred |
| Code review and design discussion | Fully mixed with the prime's engineers on shared interfaces | This is where integration risk is actually retired |
| Integration and demonstration event | Full, with working software in the shared environment | The program consumes the team's output here |
Deliverable ownership and the seam problem
Most trouble between a prime and a specialist sub happens at seams, and seams are created by ownership that is stated in nouns instead of interfaces.
"The sub owns the analytics component" sounds like a clear boundary and is not one. Does the sub own the ingestion of the data the component consumes, or does it receive that data from the prime's pipeline? Does it own the user interface that displays the results, or does it publish an API the prime's front end calls? Does it own the deployment of its component into the shared environment, or does it hand a container to the prime's release team? Each of those is a real decision with a real cost, and none of them is answered by naming the component.
Write ownership as interfaces instead. The sub owns everything behind a named interface: this service, these endpoints, this schema, this deployment artifact. The prime owns everything in front of it. The interface itself is a shared artifact with a version, changed by agreement, and each side tests against it independently. That framing converts a coordination problem into an engineering problem, which is the correct kind of problem to have.
Three corollaries follow and they are worth stating in the operating model document.
- The interface is defined before the implementation, and it is defined in a form both sides can test against. A schema, an API specification, a contract test suite. Not a slide.
- The sub delivers the deployment artifact, not the deployment. On most programs the prime's release process is the accredited path and the sub's component moves through it like everything else. The sub produces something that the prime's pipeline can take: a container, a package, infrastructure definitions, migration scripts, and the evidence its tests passed.
- Somebody on the prime side can build and run the sub's component from a clean checkout. This is the single best test of whether the handover will work, and it should be true from the first increment, not the last. Where it is not true, the program has a dependency it cannot control.
Where seams between prime and sub actually cause failures
Editorial weighting, illustrative rather than measured. The last row is deliberately low: sprint length is the thing programs argue about and almost never the thing that hurts them.
Environment, data and security handling
The security posture is usually the part that is decided by default rather than by design, which is a mistake because the default is expensive in one direction or the other.
The clean design is that the specialist team works entirely inside the program's environment, on the program's accredited infrastructure, using program-issued identities. Nothing leaves. Code lives in the program's repository. Data never moves. This is the model that produces the fewest arguments and the least residual risk, and where the program's environment is usable it is the right answer.
Where it breaks down is when the program's environment cannot support the work: the tooling is not there, the compute is not there, the iteration loop is too slow to develop against. Programs then quietly permit development outside and integration inside, which is workable if it is designed rather than tolerated. Designed means a written rule about what data may be used outside the boundary, which is usually synthetic or de-identified data generated inside and approved for release, and a hard requirement that anything built outside is proven inside before it counts as done.
Where controlled data is involved, the sub's handling obligations flow down from the prime's contract and the sub should be able to state its posture in writing without needing to be chased: where the data sits, who can reach it, how access is logged, what happens at the end of the task, and an explicit commitment that customer data is not used to train anything outside the delivery. A sub that has this written before it is asked is a sub that has done this before.
Customer contact rules, written down
This is the topic where an unwritten assumption does the most damage. The prime owns the customer relationship. That is not a formality; it is the thing the prime is accountable for, and a subcontractor engineer who answers a government question directly with a technical opinion can create a commitment nobody priced.
At the same time, a program that routes every technical question through a management chain is slow and produces worse answers, and customers notice when the person who built the thing is not in the room.
The rule that works has three tiers, and it takes ten minutes to write.
Technical working sessions. The sub's engineers attend and speak freely about how the thing works, alongside the prime's engineers. This is normal and good, and the customer benefits from it.
Anything about schedule, scope, cost or commitment. The prime speaks. The sub's engineers, if asked directly, say that the program will come back with an answer, and then tell the prime's counterpart within the hour. This is not evasive; it is the correct answer, because the sub genuinely does not know the program's constraints.
Bad news. Goes to the prime first, immediately, before it goes anywhere near the customer, and the prime decides how it is presented. A sub that surfaces a problem early to the prime is doing exactly the right thing. A sub that surfaces it to the customer, however innocently, has damaged the program manager's position.
Write these three rules into the operating model document, say them out loud in the kickoff meeting, and the topic never comes up again.
Escalation that resolves things in a day
Escalation paths on large programs tend to be drawn as hierarchies, which is why they are slow. The useful design names people rather than levels.
Technical disagreement about design or interface goes to a named chief engineer on the prime side, who decides. Not a committee. The sub's technical lead presents the tradeoff, the chief engineer picks, and the decision is recorded in the design documentation. A day, not a sprint.
Anything about scope, priority or schedule goes to the program manager on the prime side and the engagement lead on the sub side, who are two named people with each other's phone numbers. Anything about the subcontract instrument goes to the subcontracts manager and stays out of the engineering conversation entirely, which protects the working relationship from the contractual one.
And there is a standing rule worth adopting: any blocker that has cost the specialist team more than half a day of idle capacity gets raised the same day, by name, to the person who can clear it. Waiting politely is not professionalism on a program with a burn rate.
How we work inside a program like this
Precision Federal builds AI, data platforms, cloud infrastructure and full-stack software and delivers it into production inside federal agencies. On a large program we work as a specialist subcontractor under the prime's contract and inside the prime's boundary, and we come to the kickoff with the operating model already drafted rather than asking the program to invent one.
What the first weeks produce. In week one, the onboarding table with owners and dates, and whatever access is achievable immediately. In week two, a two-page technical scope naming the interfaces we own, the artifact we deliver into the prime's pipeline, and testable acceptance criteria for the first increment. By the end of the first increment, working code in the shared environment, integrated, with a build the prime's own engineers can run from a clean checkout.
What the prime keeps. The code, the models, the pipelines, the infrastructure definitions and the documentation, delivered under the prime's data rights posture as the government contract requires, assigned by a present written assignment rather than a work-for-hire recital. The customer relationship stays with the prime, entirely, under the contact rules above. We are equally comfortable being named as a subcontractor with a scored, defined scope and working behind the prime's brand with no external visibility at all.
How it is priced in shape. Two shapes, chosen to match the reason the team is there. For a bounded component, fixed-price milestones against written acceptance criteria, so the prime carries no schedule risk from our side. For a durable workstream, a committed team at agreed labor categories that maps into the prime's cost structure and the contract's rate schedule, with a named lead and named engineers at stated allocations and a written substitution path.
How to start. One email with a one-page brief: the program and the system, the component or workstream in question, the environment and who grants access, the security destination, the contract instrument, and the date that matters. We return a scoped, priced statement of work and a draft operating model for the arrangement.
Five ways this goes wrong
Access is treated as an IT ticket. The team is on the clock and off the network, and a month of capacity is spent producing documents. Name an owner and a date for each access item before the team starts.
Ownership is written as a noun. "The sub owns the analytics" leaves five seams undefined, and each of them surfaces as an argument during integration. Write ownership as interfaces with versions and contract tests.
The team is put in every ceremony. Full participation in a two-hundred-person program's coordination machinery costs a specialist team a third of its capacity and returns very little. Synchronize at the boundaries; run your own rhythm in between.
Customer contact rules are assumed. An engineer answers a scope question in a working session, in good faith, and the program manager spends two weeks unwinding an expectation. Three written rules prevent this permanently.
Nothing is integrated until the end. A team that demonstrates in its own environment for four increments and integrates in the fifth is carrying every integration risk on the program at once, at the point in the schedule where there is no room. Integrate from the first increment, even when the thing being integrated is trivial.
Bottom line
The operating model for a specialist team inside a large program is about two pages, and writing it in week two is worth more than any amount of management attention in month six. Name why the team is there and what it owns, expressed as interfaces rather than components. Get access done as a program management task with owners and dates. Report one line up and a great deal sideways. Synchronize at the program's boundaries and leave the team its own internal rhythm. Write the customer contact rules and say them out loud once. Name the two people who resolve technical and scope disputes, and resolve them in a day. Programs that do this get the specialist capability they paid for. Programs that do not get a subcontractor that is visible in status reports and absent from the system.
Frequently asked questions
Report one workstream line up the management chain and integrate heavily sideways with the engineers whose systems the team touches. The team participates fully in increment planning and in the integration event, attends the dependency forum only when it has a dependency, and runs its own daily rhythm. Ownership is written as interfaces with versions and contract tests rather than as component names, and access to the environment, repository and data is a program management task with a named owner and a date for each item.
In technical working sessions, yes, and the customer benefits from having the people who built the system in the room. Anything touching schedule, scope, cost or commitment is answered by the prime, and a subcontractor engineer asked such a question should say the program will respond and inform the prime the same hour. Bad news goes to the prime first, before it reaches the customer, so the program manager decides how it is presented. Three written rules, stated once at kickoff.
It has to meet the program's boundaries absolutely and is better left alone in between. Commit to the increment planning event, the integration cadence and the demonstration, and deliver into the shared branch on the day the program integrates. Inside those boundaries, a ten-person team running its own sprint length and its own standup is more productive than one attending a coordination machinery built for two hundred people. Autonomy in method, none in the integration contract.
The prime, delivered under the data rights posture the government contract requires, and the transfer should rest on a present written assignment of intellectual property rather than a work-for-hire recital. Alongside the code, the prime should receive the models, pipelines, infrastructure definitions, documentation and deployment artifacts, and someone on the prime's own team should be able to build and run the component from a clean checkout starting with the first increment rather than at handover.
Two shapes cover most cases. A bounded component is best priced as fixed-price milestones against written, testable acceptance criteria, which puts the schedule risk on the subcontractor. A durable workstream is better as a committed team at agreed labor categories that maps into the prime's cost structure and the contract's rate schedule, with named people at stated allocations and a written substitution path. Choosing the shape that matches the reason the team exists prevents most later disputes.