The week the schedule stops being a schedule
Every engineering organization has that week. Two people are still cleaning up the integration that slipped in April. One is out on leave. The customer demo is in five weeks, and the piece the demo is actually about is the piece nobody has started. The team is not underperforming. The team is fully committed, and fully committed is functionally the same as unavailable.
The question in that week is not whether to add capacity. It is what kind of capacity can arrive fast enough to matter, and what has to be true about the work before adding anyone helps instead of hurts. Fred Brooks answered half of that in 1975 when he wrote that adding people to a late software project makes it later. The half he did not answer is the useful half — the conditions under which it does not.
Those conditions are knowable, and they are mostly about scoping rather than about people. Work that has a boundary somebody can draw on a whiteboard in ninety seconds transfers well. Work whose boundary requires a forty-minute conversation ending in "well, it depends" does not, and no amount of talent on the receiving end changes that. The rest of this piece is about telling the two apart, and about what the transfer actually costs when the answer is yes.
Why the hiring instinct fails on this timeline
Open a requisition for a senior ML or platform engineer and count forward honestly. Writing the description and getting it approved is a week in a fast organization. Sourcing and screening runs three to six weeks for a strong candidate pool, longer if the role needs a clearance, a public trust investigation, or a specific domain background. Offer, negotiation, and a notice period add two to four more weeks. Then ramp: a strong senior engineer merges a first meaningful change in the second week and is genuinely productive somewhere between week six and week twelve, depending on how much undocumented context the codebase carries.
Add it up. The person you start recruiting today is useful in the fourth month. If the date is five weeks out, hiring is not a solution to this problem. It may still be exactly the right decision for the next twelve months, and those are two separate decisions that deserve two separate conversations. Collapsing them is how organizations end up with a rushed hire, a mediocre fit, and a missed date anyway.
A hire also carries a cost floor a bounded engagement does not. Base salary is the smallest part of it. Payroll taxes, benefits, equipment, tool seats, recruiting fees, and the management hours spent onboarding push the fully burdened figure to roughly 1.25 to 1.4 times base in most organizations. That cost continues after the deadline passes. Correct if the work continues. Expensive if the work was a spike.
Hand-off readiness by work-package type
Editorial weighting from delivery experience; illustrative, not a measured statistic.
The separability test
Work hands off cleanly when three things are true of it. It has an edge somebody can draw. It has a definition of done a reviewer can check without a conversation. And it fails in a way that stops at its own boundary.
The edge. Name the outside of the package: which repository, which module, which API surface, which tables, which environment. If naming those requires a whiteboard session, the package is not ready, and the fix is scoping rather than a longer briefing. Two hours spent tightening the boundary buys more schedule than two days spent explaining a loose one.
The definition of done. "Improve retrieval quality" is not a hand-off. "Recall@10 above 0.85 on this held-out set of 1,200 labeled queries, latency under 400 ms at p95, running in the staging cluster" is. The acceptance criteria have to be checkable by someone who was not in the room when they were written, because that is precisely who will be checking them.
The blast radius. Ask what breaks if the package is late, wrong, or abandoned. If the answer is "the new service does not ship," the package is separable. If the answer is "the core scheduler behaves differently for everyone," it is not, and that work stays with the people who carry the system's history.
Four shapes that hand off in days
Across defense, health, energy, transportation, and public-sector data work, the same shapes keep proving transferable. They share a property: their contract with the rest of the system is written down before anyone starts.
- Service behind a contract. A new endpoint, worker, or model server whose request and response schema is agreed on day one and does not move.
- Pipeline with fixed schemas. Ingest, normalize, validate, land. Input format known, output table known, quality rules written as tests.
- Evaluation and benchmark tooling. The labeled sets, scoring code, regression gates, and reports that let the team prove the system works. Almost always deferred, almost always the thing a customer asks about first.
- Migration work. A framework version bump, a library replacement, a lift into GovCloud, an infrastructure-as-code conversion. Tedious, well-bounded, and a natural fit for outside hands.
- The specified backlog. The queue of forty small, well-described items nobody has had a clear week for. Low risk individually, meaningful in aggregate.
- Hardening and CI. Test coverage on the paths that matter, container hardening, STIG remediation, pipeline reliability. Work with an objective finish line.
What actually has to be written down
Leaders bracing for a documentation project are usually relieved by this list. Six items, most of which already exist in some form.
- A README whose setup steps produce a running system on a clean machine.
- One architecture note, one page, naming the modules and who owns each.
- The acceptance criteria for this package, written as checkable statements.
- Build and test commands that pass today, plus the known-flaky list.
- An access list: repository, tickets, staging, secrets, data, and who grants each.
- One named reviewer with merge authority and a stated response time.
The list is shorter than most people expect, and the reason is worth stating plainly. Documentation for onboarding a permanent employee has to convey the whole system. Documentation for a bounded work package only has to convey the boundary. Those are different jobs, and confusing them is why teams postpone hand-offs they could have made in a week.
The README is the item everyone skips and the one that costs the most when it is stale. If environment setup takes three days of message-archaeology, that is three days of ramp charged straight to a five-week deadline. One hour with a current engineer running the README on a clean machine, fixing whatever breaks, returns more schedule than any other hour available that week.
The named reviewer matters more than the volume of documents. Handed-off work stalls at review, not at writing. If a pull request sits for four days because the only person who understands that module is the person the overflow was supposed to relieve, the whole arrangement fails on its own terms. Naming a reviewer with a stated turnaround, even 48 hours, is the single control that keeps throughput real.
The ramp cost, counted honestly
Ramp is real, and pretending otherwise is how these arrangements sour. On a bounded package of four to eight engineer-weeks, expect the first two to four working days to produce little visible output: environment, access, reading the code that touches the boundary, and confirming the acceptance criteria mean what everyone thinks they mean. Call it five to ten percent of the package. Budget it out loud rather than discovering it in week two.
The comparison that matters is not ramp against zero. It is ramp measured in days against a hiring cycle measured in months, or against a slipped date measured in customer trust. Framed that way, four days is cheap.
A clean overflow ramp
Step three is the one teams try to skip and should not. Before any package work begins, the incoming engineer ships one small, low-risk change through the entire loop: branch, build, test, review, merge, deploy to staging. It surfaces the broken CI runner, the expired staging credential, and the review bottleneck while the stakes are nothing. Finding those in week four costs the date.
When overflow is cheaper than hiring
The arithmetic is not a rate comparison. An outside rate above a loaded internal rate still wins when the internal rate cannot be purchased at all before the date. What actually decides it is duration, boundedness, and where the value sits.
| Option | Time to first useful output | What it costs | Where it fits |
|---|---|---|---|
| New full-time hire | 3–4 months | Fully burdened salary, ongoing | Work that clearly continues past this quarter |
| Contract-to-hire | 6–10 weeks | Premium rate plus conversion fee | You want the person, not only the output |
| Staffing body shop | 2–4 weeks | Hourly, plus your managers' supervision time | You have spare management capacity to direct them |
| Overflow engineering partner | 3–10 days | Fixed price against a defined package | A dated deliverable with a drawable edge |
| Absorb the slip | Immediate | The date, and the customer conversation | The date was softer than it looked |
Overflow wins when the work is a spike, the boundary is clean, and the date is real. It loses when the work is permanent, when the value comes from accumulated context rather than delivered output, or when the package genuinely cannot be bounded. In that last case the honest answer is to cut scope or move the date, and to say so in week one rather than week four. A partner who takes an unboundable package at a fixed price is telling you something about how the engagement will end.
One practical note on the staffing row. Bodies billed by the hour transfer the management burden back to the person who had no time in the first place. If the constraint is engineering hours, staffing helps. If the constraint is engineering leadership hours, it makes things worse. Worth being precise about which one is actually short.
The federal wrinkle: consent, flow-down, and work percentage
If the deadline sits on a federal contract, three rules govern the hand-off, and all three are checkable in an afternoon before anyone writes code.
Consent to subcontract. Under FAR 52.244-2, a contractor without an approved purchasing system needs the contracting officer's written consent for the subcontracts the clause identifies, and FAR 44.201-1 sets out when consent applies. On cost-reimbursement work the reach is broad; on firm-fixed-price commercial acquisitions it usually is not triggered. Pull the clause list from the prime contract on the day the need appears. Consent takes days, and nobody wants to learn that in week four. If the prime contract exceeds $750,000 and the prime is a large business, FAR 52.219-9 subcontracting-plan reporting also attaches, which is a reason primes often welcome a small-business teammate rather than resist one.
Security flow-down. DFARS 252.204-7012 requires NIST SP 800-171 implementation wherever covered defense information lives, flows down to subcontractors handling it, and carries the 72-hour cyber incident reporting obligation to DIBNet. CMMC assessment requirements appear in new DoD solicitations through DFARS 252.204-7021 under the phased rollout that began in late 2025. Where export-controlled technical data is in scope, the ITAR at 22 CFR 120 through 130 applies, and the Joint Certification Program's DD Form 2345 is the standing certification for access to militarily critical technical data. A teammate who already carries these obligations turns the security conversation into a document exchange instead of a project.
Work percentage on SBIR and STTR. The SBA SBIR Policy Directive sets a minimum of two-thirds of the work performed by the awardee in Phase I and a minimum of one-half in Phase II, measured in dollars rather than hours. STTR splits differently: at least 40 percent to the small business and at least 30 percent to the research institution. Eligibility sits at 13 CFR 121.702. Overflow on an SBIR award has to be sized to stay inside those floors, and the calculation runs on total award dollars, so it is a scoping input rather than an afterthought.
Data rights and the code that comes back
Two clause families decide who owns the output. FAR 52.227-14 governs rights in data on civilian agency contracts. On defense work, DFARS 252.227-7014 governs noncommercial computer software, with the government receiving unlimited or government purpose rights depending on how development was funded, and DFARS 252.227-7018 carries the SBIR data rights protections for SBIR-developed software. The subcontract has to mirror the prime's data-rights position, including markings.
The failure mode here is quiet and lands months later. Software arrives at delivery with markings that do not match what the prime promised the government, and the fix is a renegotiation nobody budgeted. Ten minutes at scoping time confirming which clause applies, what gets marked, and who holds background intellectual property removes the entire problem.
Access is the real long pole
The most common cause of a slow start is neither scoping nor documentation. It is access. Repository permissions, VPN, a ticket-system seat, an identity in the cloud account, an entry in the secrets manager, a data-use approval, and on federal work whatever screening the contract requires. Each item has an owner, and each owner has a queue.
The fix is ordering, not urgency. Submit access requests on the day of the scope call, in parallel with the paperwork, rather than after signature. Paper and access can run at the same time; when they run in sequence, a five-day start becomes a three-week start with nobody at fault.
Ask early whether the role requires a public trust investigation or a facility clearance. Those timelines run in months and change which work can be handed off at all — an unclassified evaluation suite against synthetic or already-released data can begin immediately while the cleared portion waits its turn. Splitting the package along the access line is often the difference between help this month and help next quarter.
How we take a hand-off
Our engineers take overflow the same way we take any bounded delivery. A scope call that runs under an hour. A written one-page scope with acceptance criteria, a named engineer, a start date, a review cadence, and a fixed price. Status in writing every day it is running. No discovery phase billed against a deadline that has five weeks left in it.
Who arrives depends on the package rather than on who happens to be free. Our standing bench includes named engineers, licensed professional engineers, and domain specialists across defense, health, energy, transportation, and public-sector data, and we match against the shape of the work: a retrieval evaluation suite draws a different person than a Terraform conversion into GovCloud or a records-extraction pipeline that has to survive an audit.
The practice was built by a former professor in technology who ranks in the Kaggle top 200 of more than 200,000 competitors and holds seven cloud certifications, with twenty years of production delivery for federal agencies across five consulting firms, three of them federal. That history is why the intake questions are the ones that decide outcomes: where is the edge, who reviews, what counts as done, which clauses flow down. We are SAM.gov active, CAGE 1AYQ0, and JCP / DD-2345 certified, so the compliance portion of a federal hand-off is a document exchange rather than a discovery exercise.
What comes back at the end
A hand-back is an artifact set, not a status update. Code merged into your branch structure and passing your CI. Tests that a reviewer can run. A runbook for anything operational. A recorded walkthrough so the knowledge stays in your organization after the engagement closes. Anything unfinished is written up with its current state and its next three steps, at a level of detail your own engineer can pick up on a Monday morning.
The honest test of an overflow engagement is what your team has to do in the week after it ends. If they spend that week reverse-engineering decisions, the work transferred without the understanding, and the cost simply moved to a worse moment. If they spend it building on top of what arrived, the hand-off did its job.
Bottom line
"Fully committed" is a statement about a date, not a permanent condition. The right question is whether some piece of the work in front of that date has a drawable edge, a checkable definition of done, and a failure mode that stops at its own boundary. When the answer is yes, that piece can leave the building this month and come back finished, and the hiring decision can be made calmly on its own timeline instead of under duress. When the answer is no, the useful move is to cut scope or renegotiate the date early enough that the customer hears it from you rather than from the calendar.
If a date is coming at you and there is no bench behind it, the next step is small. Send two things to [email protected]: a paragraph describing the work package and the date it has to be done by. You get a yes or a no within one business day. If it is a yes, you get a one-page scope with a named engineer, a start date, acceptance criteria, and a fixed price, at no cost and with no obligation. If it is a no, you get the reason and, where we can offer one, a suggestion about how to reshape the package so somebody can take it.
Frequently asked questions
Three to ten days from the scope call, with access as the deciding variable. Repository permissions, cloud identity, and any contract-required screening set the floor. Submitting access requests on the day of the scope call rather than after signature is usually worth a week by itself.
Six items: a README that produces a running system on a clean machine, a one-page architecture note, written acceptance criteria, build and test commands that pass today, an access list, and one named reviewer with merge authority and a stated turnaround. Onboarding-grade documentation is not required for a bounded package.
For a spike, yes, because a hire carries a fully burdened cost of roughly 1.25 to 1.4 times base salary that continues after the deadline. For work that clearly persists past the quarter, hiring wins. The two decisions should be made separately rather than as one.
Consent to subcontract under FAR 52.244-2 and FAR 44.201-1, security flow-down under DFARS 252.204-7012 with NIST SP 800-171 and any CMMC requirement under DFARS 252.204-7021, data rights under FAR 52.227-14 or DFARS 252.227-7014, and on SBIR or STTR awards the work-percentage floors in the SBA policy directive.
Anything whose failure changes behavior across the whole system, anything where the value lives in a person's accumulated history with the codebase, and anything whose definition of done cannot be written as a checkable statement. Those stay in house, and the overflow goes to the separable work beside them.