An eight-week audit window is 56 days.
SHRM's 2026 recruiting benchmark puts median time-to-fill for a nonexecutive position at 39 calendar days. SHRM defines time-to-fill as the period from job requisition to offer acceptance. It does not include a notice period, onboarding, or the time required to understand a protocol well enough to own its riskiest code.
So if an audit starts in eight weeks and a lead engineer leaves today, “open a role” may be necessary.
It is not a recovery plan.
An eight-week audit window is not an eight-week hiring window
The audit date and the hiring process are two different clocks.
The first counts down to the moment a codebase is supposed to be mature enough for focused security review. The second counts only to an accepted offer. Those clocks do not end at the same definition of “ready.”
Suppose the audit begins on day 56. The team chooses day 42 as its scope-freeze target, leaving two weeks to stabilize the audit commit. That two-week lead is an adjustable planning assumption, not a universal rule imposed by every auditor.
Now use the 39-day recruiting median and add a 14-day onboarding assumption. The new hire reaches useful ownership on day 53.
That is 11 days after the team's scope-freeze target.
The arithmetic is not a forecast. A particular search could close much faster or much slower. A senior protocol engineer may not resemble the general nonexecutive market in SHRM's sample at all. But the comparison exposes the risk: a normal hiring process can fit inside the calendar while still arriving too late for the work that matters.
The benchmark matters—and where it stops
SHRM's 39-day figure comes from broad recruiting data across more than 4,600 organizations. It is not a crypto-engineering benchmark, and it does not tell us how long it takes to find a Solidity, Rust or protocol-security specialist.
That limitation is precisely why we should not turn it into a stronger claim.
The benchmark gives a reasonable baseline for one part of the timeline. The team still has to model everything it leaves out:
- candidate notice periods
- onboarding and access
- architecture and dependency context
- the protocol's threat model
- tests and invariants
- deployment and upgrade procedures
- ownership of auditor questions and remediation
If those steps remain implicit, the team is not planning capacity. It is hoping the calendar behaves.
Audit readiness is an ownership problem
OpenZeppelin's audit-readiness guide describes productive audit candidates as systems that are tested, documented and ready for deployment. Its team checklist asks who will interact with auditors and whether another team member could step in after a departure without a steep learning curve.
That changes the recovery question.
It is not simply:
How many engineers do we have?
It is:
Who can make and defend the next audit-critical decision?
A team of six can still have a single point of failure if one person owns the contract changes, another owns deployment, and nobody else can explain their assumptions. A smaller team can be more resilient if every critical workstream has a named owner, a backup and a usable handoff.
The unit to map is not headcount. It is accountable ownership.
For a typical audit-readiness window, we would start with five workstreams:
| Workstream | What ownership means |
|---|---|
| Contract changes | Final implementation and remediation decisions |
| Tests and invariants | Unit, integration, fuzz and property coverage |
| Docs and threat model | Architecture, assumptions and intended behavior |
| Deployment path | Scripts, permissions, upgrades and rehearsal |
| Auditor response | Fast answers, triage and verified fixes |
The exact map will vary by protocol. The important part is that “the team” cannot be the owner of a critical path. A person must be accountable, and someone else must be able to step in.
Four decisions that protect the date
1 — Freeze optional scope now
When capacity disappears, continuing to add features converts a staffing problem into a moving-target problem.
Identify the smallest coherent scope worth auditing. Name the exact commit or branch the team intends to stabilize. Separate required contract changes from everything that can move after the review.
De-scoping is not surrender. It is a way to spend the remaining engineering attention on a surface the team can actually explain and test.
2 — Give every critical workstream an owner and a backup
Write down who owns each row in the map. Then ask the uncomfortable follow-up: if that person vanished tomorrow, who could continue without reconstructing the project from chat history?
If the answer is nobody, the immediate deliverable is a handoff created while the remaining context is still available. Tests, architecture decisions, deployment steps, open assumptions and known risks should live together.
3 — Cover the critical path before the permanent hire arrives
The permanent search can continue in parallel. The urgent question is how to cover the work that cannot wait for it.
There are several legitimate answers:
- reassign an internal engineer who already knows the system
- embed a specialist for a narrow, time-boxed workstream
- reduce the audit scope
- move the audit date deliberately
An embedded engineer is not automatically the right answer, and adding a person can make a late project slower when the scope is unclear. External capacity only helps when the team can define the missing ownership, grant the right access and support a fast technical handoff.
4 — Move the date before the buffer reaches zero
An audit slot is not more valuable than an audit-ready codebase.
If the team cannot freeze a coherent scope, pass its tests, explain its assumptions and staff remediation, moving the date may be the safest decision. Make that decision while options still exist, not after the team has burned the final week pretending the original plan remains intact.
We built Audit Clock
We wanted to make the collision visible before turning it into a service pitch.
Audit Clock is a simulated planning model. It compares:
- days until the audit
- the team's chosen scope-freeze lead
- time to an accepted offer
- an explicit onboarding assumption
- an explicit embedded-specialist ramp assumption
- audit-critical workstreams that still have no owner
Every assumption is adjustable. Change the audit from eight weeks to twelve. Move the freeze target. Use your own recruiting history. Set onboarding to zero if the person is already inside the team. Mark each workstream covered as ownership becomes real.
The model then says one of three things: the normal hiring path misses the freeze, the ownership runway is nearly gone, or the full-time search still has planning room.
It also generates a 72-hour coverage plan the team can copy.
Run the default scenario
The default is deliberately simple:
| Input | Assumption |
|---|---|
| Audit starts | Day 56 |
| Scope freeze | Day 42 |
| Accepted offer | Day 39 |
| Onboarding to useful ownership | 14 days |
| New hire useful | Day 53 |
| Embedded specialist ramp | 5 days |
Under those assumptions, the normal hiring path misses the freeze by 11 days.
That does not mean an embedded specialist will be productive in five days. Five days is a scenario input, not a dOrg service-level promise. Its job is to let the reader compare paths and replace our assumption with one they can defend.
The more important interaction sits below the timeline. Toggle the workstreams that lack an owner. Three uncovered rows make the risk concrete in a way that a generic “we need another engineer” statement cannot.
What the model cannot tell you
Audit Clock does not inspect a repository. It cannot assess code quality, candidate quality, specialist availability or the fit between an engineer and a protocol.
It does not estimate audit findings, launch safety or the probability that a date will hold. It does not model compensation, recruiting channels, notice periods or jurisdiction. The 39-day benchmark is general recruiting data, not evidence about crypto hiring specifically.
It is also not an audit. Embedded delivery and independent security review are different jobs and should remain separate.
Those exclusions are intentional. A compact model is useful only if it is honest about what it knows.
The real output is a decision
A departure close to an audit creates four possible actions: reassign, embed, de-scope or delay.
The right choice depends on the codebase and the people already around it. But waiting for the recruiting process to answer an audit-readiness question is itself a choice—and often the least visible one.
The next useful artifact is not a longer job description. It is a one-page recovery plan containing:
- the audit and scope-freeze dates
- the exact audit scope
- an owner and backup for every critical workstream
- the gaps that must be covered now
- the date on which the team will de-scope or move the audit if coverage is still missing
The hiring process can keep running. The audit clock will not wait for it.