Federal deals do not usually die at the demo. They die about four weeks later, in a stage that has no name in most sales methodologies and no owner on most sales teams. A security architect sends nineteen questions. A program office asks for a deployment diagram showing where government data sits at every hop. A contracting officer asks for an accessibility conformance report. Someone asks whether the pilot can run inside the agency's own environment by a date. Each of those is an engineering answer, and a sales team that has to route each one back to a product organization that has its own roadmap loses weeks per question. Enough weeks and the fiscal year closes without the deal.
This is written for the person who owns federal revenue at a commercial software or data company: the head of public sector, the vice president of federal sales, or the general manager who inherited the number. The argument is that the constraint on your close rate is not headcount, pipeline or price. It is technical answer latency, and that constraint is fixable with an arrangement rather than a hire.
Where the deal actually stalls
Map your last ten federal pursuits against the stages and the pattern usually appears immediately. Discovery is fine. Demonstration is fine. Then something happens that is not on the sales board at all, and the deal sits.
The stall is almost always one of five things. A security review that asks questions the sales engineer cannot answer without reading source code. A deployment requirement that the product does not currently satisfy, discovered late. A technical evaluation section in a written response, due in eleven days, that nobody on the team is qualified to write. A pilot the agency wants to run inside its own boundary, which requires a build that does not exist. Or an accessibility requirement attached to the purchase, which requires remediation the product team has not scheduled.
Notice that none of these are sales problems and all of them arrive during sales. That is the whole of the issue. The sales team owns the clock and does not own the resource that stops it.
What a federal sales team is actually missing when deals stall
Editorial weighting, illustrative rather than measured. The last row is low because adding sellers to a technically constrained pipeline adds stalled deals.
Why the product organization cannot be the answer
The instinct is to escalate to engineering, and it fails predictably for structural reasons rather than cultural ones.
A product engineering organization is planned against a roadmap that was committed to the commercial business. Federal requests arrive without notice, are individually small, and are urgent in a way that does not match a sprint boundary. The engineer who answers them is pulled off committed work, which makes the product leader correctly resistant, which makes the escalation slow, which makes the sales team stop escalating and start guessing. Guessing on a security questionnaire is how a company ends up with an assessment finding that it misrepresented its posture.
There is a second problem. Federal technical questions require knowledge the product team genuinely does not have, and there is no reason it should. What an authorizing official needs in a control implementation summary, how a deployment inside a government cloud region differs from a commercial one, what an accessibility conformance report has to contain to be usable in a procurement, how a technical evaluation is scored and therefore how it should be structured: these are learned by delivering into agencies. Asking a talented commercial platform engineer to produce them on a deadline is asking for a first attempt at an unfamiliar genre, under time pressure, on a document a government reviewer will grade.
What the engineering partner does during the pursuit
The work divides into five things, and a sales team that names them separately can staff them separately.
The technical answer desk
Every federal pursuit generates a stream of questions from security, network, identity, records, accessibility and privacy reviewers. Answering them well requires reading the product's actual architecture, not its marketing pages, and answering them in the vocabulary the reviewer uses. The right arrangement is a named engineer with the product's source access and a commitment on turnaround, so a question that arrives Tuesday is answered accurately by Thursday.
Answer quality matters more than most sales leaders assume. Reviewers compare answers across vendors, and a precise answer that admits a gap with a dated remediation plan reads as competence. A vague answer that avoids the gap reads as evasion and gets followed up with three more questions, which costs another two weeks.
The demo environment that matches the deployment model
A demonstration running on the vendor's multi-tenant commercial instance answers the question of what the product does and leaves the harder question untouched: can this run where we need it. Building a demonstration environment in a government cloud region, with the agency's identity model, with the network shape the agency will actually use, changes the conversation, because the security architect in the room can see the answer instead of being promised one.
This is a real build, and it is reusable across pursuits, which is what makes it worth doing once properly rather than improvising per deal. The reusable version is an infrastructure-as-code definition that stands the product up in a government region with federated sign-on, the logging destination configured, and the egress list documented, from a clean checkout.
The technical volume
When an agency buys through a written competition, a section of the response is technical and it is scored by evaluators against stated criteria. This document is not a brochure and it is not a white paper. It is written to a scoring rubric, and the difference between a version written by a proposal writer and one written by an engineer who has been through an agency deployment is visible on the page and in the score.
What good looks like: the architecture described accurately with a diagram a reviewer can follow, the deployment model stated plainly with the boundary drawn, every requirement in the solicitation answered in the order the solicitation asked, risks named with mitigations that are specific, and no claim that the shipped product cannot support. Evaluators reward specificity because specificity is checkable.
The pilot delivered inside the agency
Increasingly the last stage before a purchase is a working pilot inside the agency's environment on the agency's data. That is a delivery project with a deadline, and treating it as a sales activity is how it fails. It needs a scope, acceptance criteria written as measurements rather than adjectives, an engineer accountable for it, and a plan for what the pilot leaves behind. A pilot that leaves behind a documented deployment and a measured result converts. A pilot that leaves behind a good impression does not.
The pre-work that removes the stalls entirely
The highest-return item is the one that happens before any specific deal. Inventory the product's outbound network calls and external dependencies. Remediate accessibility in the component library. Build federated sign-on and hardware-token support. Add immutable decision and access logging. Generate a software bill of materials in the build. Write the control implementation summary once, against the standard control catalog, and keep it current. Every one of those turns a future four-week stall into a same-week answer, and none of them is deal-specific.
What a security review actually asks, and why it takes engineering
Sales leaders who have not read one underestimate what a federal security review is. It is not a questionnaire about whether the company encrypts data. It is an inventory exercise conducted against a control catalog, and the reviewer is trying to build a picture accurate enough that an authorizing official can accept risk on the agency's behalf.
The questions cluster in six places, and each requires someone who can read the system rather than the datasheet.
The boundary. Where does the system stop and something else begin. Which components run in the agency's environment, which run in yours, which run at a third party. What crosses each line, in which direction, over what protocol, carrying what. A reviewer wants a diagram in which every arrow is real. Producing one usually means reading configuration and network rules, because most products have connections nobody has written down: a telemetry endpoint, an error reporting service, a license check, a content delivery network, an outbound call inside a third-party library.
Identity and authorization. How users authenticate, whether that can be federated to the agency's own identity provider, whether hardware tokens are supported, how administrative access is separated from user access, how privileges are granted and revoked, and whether the vendor retains any standing access to the running system. The last of those is often a deal-level question rather than a technical one: a product that requires vendor administrative access to function is a much harder approval than one that does not.
Data at rest and in transit. What is encrypted, with which algorithms, using which cryptographic implementations, and who holds the keys. Federal reviewers care about validated cryptographic modules specifically, and an otherwise sound product using an unvalidated implementation is a finding. Whether the customer can hold its own keys is a recurring question.
Logging and monitoring. What events are recorded, whether the record can be altered, where the logs go, how long they are retained, and whether the agency's own security operations can ingest them. Products built for commercial buyers often log for debugging rather than for audit, and the difference shows up immediately: a debugging log cannot reconstruct who did what to which record months later, which is the question that matters after an incident.
Vulnerability and supply chain. How the product is scanned, how quickly findings are remediated by severity, what the patch cadence is, and what is inside the deployment artifact. A software bill of materials generated by the build rather than maintained by hand is what makes this answerable, and generating one is a day of work that saves a month of correspondence.
Incident response. Who is notified, how quickly, through which channel, and what the vendor commits to do. Agencies have their own reporting obligations and they need the vendor's commitments to be compatible with them.
Read that list and the staffing problem is obvious. Answering it takes someone with source access, architectural knowledge, and familiarity with what a federal reviewer is trying to establish. That is one person for a few days per pursuit, and then a reusable set of documents. It is not a job a sales engineer can do well and it is not a job worth interrupting a product roadmap for repeatedly. It is exactly the work that belongs with a partner who does it continuously.
Four ways to get the engineering, compared
| Dimension | Escalate to product engineering | Hire federal solution engineers | Engineering delivery partner |
|---|---|---|---|
| Turnaround on a security question | Depends on the sprint boundary and the escalation path | Fast once hired; hiring cycle is months | Committed, typically same week |
| Federal delivery knowledge | Rarely present, and no reason it would be | Present if you can hire it; the market for it is thin | The reason the arrangement exists |
| Effect on the product roadmap | Direct and resented; commitments slip | Neutral once the team is standing | None; the work runs beside the roadmap |
| Cost shape | Hidden, and paid in delayed releases | Fixed salary against variable demand | Fixed-price milestones or a committed team for a term |
| Can deliver a pilot inside an agency | Only by taking engineers off the roadmap | Yes, at the size you staffed for | Yes, scoped per pilot with acceptance criteria |
| Who owns the resulting code | You | You | You, by written assignment from the first commit |
The table is not an argument that hiring is wrong. A company with a durable federal business eventually builds this team, and should. The argument is about sequence. Hiring a federal engineering team before there is federal revenue means carrying a fixed cost against a pipeline that is still being proven, and the hiring cycle for engineers who have actually deployed inside agencies is long because the market for them is thin. A partner arrangement gets the capability in place this quarter and can be converted or wound down as the business tells you which.
Pre-work that converts a four-week stall into a same-week answer
Editorial weighting, illustrative rather than measured. The last row is low because none of the stalls described above are caused by sales material.
How the arrangement is structured commercially
Three shapes work, and most companies use two of them at once.
A committed team for a term. A stated number of engineers for a stated number of months, with a named lead, a defined response commitment on technical questions, and the sales leader deciding week to week what the capacity points at. This fits the answer desk, the demo environment and the pre-work, because the demand is real but its exact shape is not knowable in advance. It is priced as a monthly commitment and it is the arrangement that removes latency, which is the actual problem.
Fixed-price milestones per deliverable. A technical volume, a demo environment build, a pilot delivery, a security documentation package. Each has a scope, acceptance criteria and a price. This fits everything where the shape is knowable, and it is the arrangement finance prefers because the cost is attached to an artifact.
A pursuit-triggered increment. A pre-agreed rate and scope template that activates when a specific opportunity appears, so nobody is negotiating a contract while a proposal deadline runs. Companies with lumpy federal pipelines use this to avoid carrying capacity between pursuits without losing the ability to move fast when one lands.
What should not be used is an hourly staffing arrangement with no defined outcome. The reason is not price. It is that hours purchase attendance and the thing the sales team needs is accountability for an answer being right and on time.
What the company keeps
This is the question every sales leader asks second and it deserves a direct answer.
The customer relationship. Entirely yours. We work behind your team or in front of it, whichever you choose. On a commercial-style pursuit most companies prefer we are invisible and we deliver under your brand. Where an agency evaluates the technical team by name, being visible is usually the stronger posture, and that is a decision to make before a response goes out rather than after a reviewer asks who wrote it.
The code, the environment definitions and the documents. All assigned to you in writing, committed to your repositories from the first day. The demo environment definition, the deployment artifacts, the control implementation summary, the technical volume text: yours, and reusable across every future pursuit without us.
Your data and your customers' data. We do not hold either. Where our engineers touch agency data during a pilot, they do it inside the agency's environment under the agency's access controls.
A named carve-out for what we bring. Our pre-existing tooling is named in the agreement, excluded from the assignment, and licensed to you perpetually so nothing we bring can strand a future maintainer or an in-house team you hire later.
The first weeks
An engagement that starts well looks like this. In the first two weeks we read the architecture, the deployment pipeline, the dependency inventory and the interface, and we read your last three federal pursuits including every question you were asked and every answer you gave. The output is a written list: what in the product blocks a federal deployment today, what documentation exists and what is missing, which of your past answers would not survive an assessment, and what each item costs in engineering weeks.
By week four the answer desk is live with a named engineer and a turnaround commitment, and the accessibility work has started because it is independent of everything else and is the item most likely to block a purchase outright. By week eight there is a demo environment in a government region that a security architect can be walked through. From there the work follows the pipeline: technical volumes when responses are due, pilot delivery when an agency asks for one, and the pre-work continuing underneath so that each pursuit starts from a better position than the last.
Five failure modes to avoid
Sales answers the security questionnaire. Answers that overstate the posture are found later, and being found is far worse than having a gap. An engineer answers, with a dated plan attached to anything not yet true.
The pilot is built where the product can never be deployed. A pilot in a convenient commercial account proves the product and proves nothing about deployability, which was the question. Build it in the destination environment or against a written path to it.
The technical volume is written the week it is due. Evaluators can see it. The architecture description, the boundary diagram and the risk section should exist as reusable assets that get tailored, not composed under deadline.
Nobody owns the government configuration between deals. Two releases after a pursuit ends, the federal build stops working and nobody knows. It needs a continuous integration job like any other supported configuration.
The arrangement is bought as hours and asked for outcomes. Decide which you are purchasing and price it that way. A committed team with a response commitment and a fixed-price deliverable are both fine. An hourly pool asked to be accountable for a proposal score is not.
Bottom line
Federal deals stall in a stage most sales organizations do not staff: the technical evaluation, where security architects, deployment requirements, scored written volumes, in-agency pilots and accessibility requirements arrive all at once and all require engineering. Escalating into a product roadmap is slow and produces answers in an unfamiliar genre. Hiring the team is right eventually and is a long cycle against unproven revenue. An engineering partner with agency delivery experience closes the latency this quarter, is priced as milestones or a committed team rather than hours, and leaves the company owning every artifact it produces. The first step is one email with a one-page brief. We return a scoped, priced statement of work.
Frequently asked questions
Because the next stage is technical rather than commercial. Security architects send detailed questions, a program office asks for a deployment diagram and a boundary description, a purchase may require an accessibility conformance report, and the agency often wants a pilot running inside its own environment. Each answer requires engineering, and a sales team that has to route every question into a product roadmap loses weeks per question. The constraint is technical answer latency, not pipeline.
Eventually a durable federal business builds the team. The question is sequence. Hiring engineers who have actually deployed inside agencies is a long cycle because the market for them is thin, and it puts a fixed cost against a pipeline that is still being proven. A partner arrangement gets the capability live in weeks, is priced as milestones or a committed term, and can be converted to a hired team once the revenue justifies the fixed cost.
Five things. Answers the security, identity, network, privacy and accessibility questions accurately and quickly. Builds a demonstration environment that matches the deployment model the agency will actually use. Writes the technical volume to the scoring criteria. Delivers the in-agency pilot with measured acceptance criteria. And does the pre-work between deals that removes future stalls: dependency inventory, federated sign-on, logging, accessibility remediation, software bill of materials and the standing security documentation.
Two shapes, usually together. A committed team for a stated term with a named lead and a response commitment, which fits the answer desk and the pre-work because demand is real but its shape is not knowable in advance. And fixed-price milestones for deliverables with a definable scope: a technical volume, a demo environment, a pilot, a security documentation package. Hourly staffing with no defined outcome is the arrangement to avoid, because it buys attendance rather than accountability.
The company does, by written present assignment, with everything committed to the company's own repositories from the first day. That includes the environment definitions, deployment artifacts, security documentation and technical volume text, all reusable across future pursuits without the partner. The partner's pre-existing tooling should be named in the agreement, excluded from the assignment, and licensed back perpetually so nothing brought in can strand a future maintainer or an in-house team hired later.