Protégé engineering inside the mentor's programs

The mentor-protégé agreement is signed, the developmental assistance schedule is written, and a year later the file shows quarterly meetings, a few training sessions, and one joint proposal that did not win. Nothing improper happened. The arrangement simply never touched a program with revenue in it. The mentors who get real value from the relationship do something different from the start: they place the protégé's engineers on live work, inside a program that is already running, with a scope the protégé owns and a customer who sees the result.

This is written for the program executive or small business office lead who has to decide where a protégé team actually sits. The decision is not administrative. Putting a specialist engineering team on a live workstream changes delivery risk, changes what the annual report has in it, and changes whether the relationship produces a second contract or a filed document.

Why the joint-pursuit-only model underperforms

The default pattern is to treat the protégé as a bid asset. The firm goes on the team, the proposal names it, and the work begins if and when the award lands. That model has three problems that show up in the same order every time.

The first is timing. A pursuit cycle runs six to eighteen months from capture to award, and the protégé does nothing chargeable in that window. Developmental assistance that consists of proposal support is training the protégé to write, not to deliver, and the mentor learns nothing about whether the firm can build.

The second is evidence. When the recompete arrives, the mentor wants to say the protégé performed. If the only shared history is a pursuit, there is no performance to describe. A citation that reads "teamed on a proposal" is not past performance for either party.

The third is the one that costs money. The mentor's live programs have real engineering pressure in them: a data pipeline that breaks under load, a model that nobody can explain to an authorizing official, an application that fails accessibility review three weeks before a milestone. Those problems are on the critical path right now. A protégé with the right engineering depth can take one of them and finish it, and the mentor sees within a quarter whether the relationship is worth expanding.

Where a protégé team fits inside a running program

Program managers reasonably resist inserting an outside team into a delivery structure that works. The way to do it without disturbance is to pick a workstream with a boundary that already exists in the architecture, rather than splitting a team.

Four placements tend to work. Each has a natural interface, so the protégé can be held to a result rather than supervised hour by hour.

The analytics or model layer behind an existing application. The program owns the application and the data store. The protégé owns feature engineering, model training, evaluation, and the service that returns a prediction with its inputs recorded. The interface is an API contract and a schema. Handing over that layer moves specialist work off the program's critical path without touching the user-facing system.

Ingest and data quality. Most federal programs carrying analytic scope have an ingest problem: files arriving in shapes nobody documented, partial loads, silent schema drift, and a nightly job that fails without telling anyone. This is bounded, measurable, and unglamorous, which is exactly why it stays broken. A protégé that fixes it earns credibility fast because the improvement is visible in the operations report.

A modernization increment carved out of the legacy system. Pick one function, put a service in front of it, move the traffic, retire the old path. The protégé owns the increment end to end, including its tests and its deployment pipeline. The program keeps the rest of the system untouched during the work.

The accreditation and evidence workstream for a new capability. Somebody has to produce the control implementation statements, the diagrams, the scan results, and the artifacts an authorizing official reads. When a specialist owns that alongside the build, the security review stops being the thing that slips the schedule.

What developmental assistance looks like when it is real

The assistance a protégé actually needs from a large mentor is rarely technical. A specialist engineering firm brought onto a program knows how to build. What it does not have by default is the mentor's machinery: the estimating discipline, the earned value data, the CDRL production line, the security paperwork, the way a program office writes a monthly status report that an ACO reads without asking questions.

Assistance that changes a protégé's capability tends to fall into these categories.

• Estimating and pricing structure. How the mentor builds a basis of estimate, how indirect rates are structured and disclosed, what a cost narrative has to show. This is the single highest-value transfer, because it decides whether the protégé can bid larger scope credibly.
• Program control mechanics. Work breakdown structure discipline, schedule integration, variance reporting, and the cadence of a program management review. A protégé that can plug into the mentor's reporting rhythm is far easier to place on the next program.
• Contracts and compliance depth. Flow-downs and what they actually require, property and travel rules, timekeeping practice, and the record-keeping an audit expects. Learning this on a live subcontract, with the mentor's contracts staff available, is cheaper than learning it in an incurred cost submission.
• Quality and configuration management. The mentor's process assets, tailored rather than imposed. A protégé should end the period with its own documented process, not a copy of the mentor's binder.
• Introductions inside the customer, made properly. The protégé's engineers meeting the government technical leads they will work with, in the program's normal forums, with the mentor present. This is what makes the workstream deliverable at all.
• Facilities, tooling and environment access. Getting the protégé's engineers onto the program's development environment, with accounts, repositories, and the build system, in weeks rather than months. Access latency is the most common reason a placement underperforms in the first quarter.

The assistance that does not work is a training catalog. Sending a protégé's staff to a generic course and logging the hours satisfies a reporting field and changes nothing about what the firm can deliver next year.

How credit and past performance flow

This is where most mentors leave value on the table, because the paperwork that makes the performance citable has to exist before the work starts, not after it.

Three separate things are often confused. Subcontracting credit is what the mentor reports against its plan goals. Performance evaluation is what the government records about the prime's contract, in the contractor performance assessment reporting system. Past performance for the protégé is what the protégé can cite in its own future proposals, and it comes from a different place.

The performance assessment on the prime contract is written about the prime. A subcontractor does not receive its own record from that system. What the protégé can use instead is a reference: a letter or a completed questionnaire from a named individual, describing scope, period, dollar value, and how the work was performed. Whether that reference is available at all depends on decisions the parties make at the start.

The reference commitment deserves a sentence of its own in the subcontract. It should name the role that signs, state that the mentor will complete a standard past performance questionnaire on request within a stated number of business days, and confirm that the protégé may describe the scope of its own work in proposals, subject to customer sensitivity and any nondisclosure terms. None of that costs the mentor anything. Its absence is why protégés arrive at the end of a period of performance with nothing they can cite.

On relevance, evaluators weigh similarity of scope, size, and complexity. A protégé's subcontract on a large program is often more relevant to a future pursuit than a small prime contract, because the technical environment matches. The reference should therefore describe the program's scale and the technical environment, not only the subcontract value. A reference that says the work ran inside a multi-site production environment serving a large user population, with named technologies and a stated availability requirement, does more for both parties than one that says the sub performed satisfactorily.

What specialist engineering adds to an AI or data workstream

The reason to place a specialist protégé on live work rather than adjacent work is that the failure modes on these workstreams are specific, and a generalist team staffed from a broad bench tends to hit them in sequence.

The evaluation problem. A model that performs well in a notebook and badly in production usually failed at the split, not the algorithm. Records that share a subject, a site, or a time window leak across training and test partitions, and the reported accuracy is measuring memorization. The fix is a partition rule stated in the design, held constant across every experiment, and a held-out set nobody touches until the end. Programs that skip this discover it when the customer runs the system against their own sample.

The explanation problem. A federal user who acts on a model output has to be able to say why. That means storing, for every prediction, the input record, the model version, the feature values, and the decision threshold in force. It is a data model decision, and it is very expensive to add later because the history is gone. Building it in from the first sprint costs almost nothing.

The drift problem. Data changes: a form is revised, an upstream system starts sending nulls, a population shifts. Without monitoring on input distributions and on outcome rates, the first signal is a user complaint. The monitoring should be part of the delivered system, with thresholds and an owner, not a promise to look at it quarterly.

The accreditation problem. A capability that cannot be authorized is not a capability. That means the environment, the identity model, the logging, and the control evidence are design inputs. Working to the NIST SP 800-53 control set and the FedRAMP baseline appropriate to the destination, from the beginning, is the difference between a system that goes live on schedule and one that sits in review.

The handoff problem. The program keeps the system after the increment ends. That requires infrastructure as code, a build pipeline anyone can run, a runbook, and a rehearsal in which the receiving team deploys while the builders watch. Treating handover as a deliverable rather than a courtesy is what keeps the capability alive.

How we work inside a mentor's program

Precision Federal builds AI systems, data platforms, cloud infrastructure, and full-stack web and mobile applications, and delivers them into production inside federal agencies. We are a small business, and we work as a specialist subcontractor, teaming partner and protégé to large primes. On a mentor's live program, our engineers take a bounded workstream with written acceptance criteria and answer for the result.

The first weeks are concrete. In week one we read the program's architecture, the data model, the current pipeline, and the security package, and we sit in the program's normal technical forums. By the end of week two we return a written finding: what the workstream requires, where the risk is, what we would change in the first increment, and a measured baseline for whatever the acceptance criteria will be scored against. Weeks three through eight produce a working increment in the program's environment, against real data, with tests, a deployment pipeline, and the control evidence a security review will ask for. Nothing is built on a side account and migrated later.

The mentor keeps everything that matters. The customer relationship stays with the mentor and we work through the program's reporting line. The code, the models, the data, the pipelines and the documentation are delivered under the terms of the subcontract, with our pre-existing tooling named and licensed so nothing in the delivered system is blocked for a future maintainer. We follow the mentor's configuration management and reporting practice rather than importing our own.

Pricing takes one of two shapes. A defined increment prices as a firm fixed-price milestone against written acceptance criteria, which puts schedule and technical risk on us. A continuing workstream prices as a committed team at a stated allocation, with named engineers and a substitution path in the subcontract. Which one fits depends on how well bounded the scope is, and we will say plainly when a scope is not bounded enough for a fixed price yet.

The first step is one email with a one-page brief: the program, the workstream, the environment named by product, the data and who grants access, the security destination, and the date that matters. We return a scoped, priced statement of work.

Structuring the placement so it holds

A placement that lasts has a small number of decisions made correctly at the start.

1. Give the protégé a scope with a boundary in the architecture. If the scope cannot be described as an interface, a deliverable, and an acceptance test, it will become supervised hours and neither party will get what they wanted.
2. Name the engineers and commit the allocation. Key personnel discipline is not only for the prime contract. A named team at a stated percentage, with a substitution path, is planable; a promise of qualified staff is not.
3. Solve environment access before the kickoff. Accounts, repositories, the build system, and whatever badging or onboarding the site requires. Every week of access latency is a week of the period of performance spent waiting.
4. Write the reference commitment into the subcontract. Who signs, within how many days, and what the protégé may say about its own scope.
5. Set the developmental assistance against a capability the mentor wants to buy later. If the mentor wants the protégé bidding larger scope in two years, the assistance is estimating, program control and compliance. Choose it deliberately.
6. Name an executive sponsor on each side and hold a quarterly review. Relationships that live in one person's contact list end when that person changes jobs.
7. Measure the placement. Baseline the workstream metric before the protégé starts, report it monthly, and record the delta. That number is what makes the case for the next placement, and it is what the recompete narrative is built from.

Bottom line

A protégé relationship that lives only in pursuits produces a filed document. A protégé placed on a live program produces delivered capability, a measured improvement in the monthly report, a reference both parties can use, and a firm that can carry more scope next cycle. The placement decision is engineering, not administration: pick a workstream with a boundary in the architecture, commit named engineers, clear environment access before kickoff, and write the reference commitment into the subcontract before anyone starts work. Mentors that do those four things get a specialist capability they can deploy again. Mentors that do not get quarterly meetings and a training log.

Frequently asked questions