Nearly every organization I've worked inside faced the same challenge, though none of them used a consistent term for it. Critical expertise was concentrated in a small group of long-tenured individuals, and whatever documentation existed was usually a personal framework, revised each month to address the previous month's problems.
That isn't negligence. It's what happens when capable people keep an operation running under pressure. But it means the real process is undocumented, the reasoning behind it is unrecorded, and both are one departure away from disappearing.
Before I built what was missing, I established what was actually there: compliance audits across vendor and contractor documentation, fit-gap analysis measuring stated requirements against operational reality, workflow assessments that changed how responsibilities were distributed. Then I built what closed the gaps — certification systems, work instructions, assessment standards, and planning templates that put expert judgment into a form people who hadn't acquired it could use.
In many organizations, that expertise has already gone. Some of it retired. A great deal of it was released in restructuring, because undocumented knowledge is invisible to workforce planning—it doesn't appear in a process map or a role justification, so it can't be weighed. The people who knew the most about how the work actually functioned were, on paper, the easiest to let go. Many organizations are now discovering what left with them.
AI has raised the stakes further. When an organization automates undocumented work, it isn't automating the work—it's automating the workaround, and losing the underlying rationale permanently. At the same time, the entry-level roles that once transmitted expertise through apprenticeship are being compressed, while the body of knowledge itself expands faster than new employees can absorb it.
Preparing a workforce to work alongside AI starts earlier than most people think. It starts with an honest assessment of what is documented, what is assumed, and what exists only in someone's head—and with building the standardized work instructions and processes that make everything downstream possible. Automation applied to an undefined process only accelerates the ambiguity.
Competence without comprehension
A major defense modification program integrated multiple technical sub-projects, each with its own vendors supplying materials and modifications. The schedules feeding the integrated program were inaccurate, and the inaccuracies compounded as they rolled up.
The people producing them were experienced and expensive. That was what made the pattern worth understanding. They weren't undertrained — they were trained in automated tools that performed the underlying calculations for them. They knew which buttons to press and what output to expect. What they had never learned was what the buttons actually did, which meant they could not recognize when the output was wrong. Errors that a manual check would have surfaced immediately passed through unexamined, because nothing in their training had given them a reason to doubt the tool.
I found them by working the schedules manually. Once the specific failures could be demonstrated rather than asserted, the conversation shifted from competence to method — and the corrective standard already existed, documented in PMI practice and Air Force guidance. It had simply never been operationalized in a form the program could apply monthly.
Working with direct-hire staff, who owned the build and rollout under clearance requirements, I specified a structured reconciliation system to standardize the monthly checks: what to verify, how, and what constituted a failure. I then trained the sub-project teams and audited compliance monthly, extending to the supplying vendors. Several of those vendors approached me afterward about the same problems inside their own organizations.
The finding. Automation transfers capability without transferring understanding, and the gap doesn't announce itself. It produces confident, credentialed, entirely wrong output — and it is invisible until someone who knows the underlying work examines the result by hand. This is now the central risk in AI adoption, and the mitigation hasn't changed: the underlying standard has to be documented, the checks have to be structured and routine, and someone in the organization has to retain the comprehension the tool replaced.
When the assessment itself has no standard
A major defense program consolidated schedules from subcontractors, vendors, and internal teams into a single integrated master schedule, audited monthly against DCMA guidance. The audits were being performed. The findings were being reported. And they weren't comparable to each other.
The issue wasn't effort or expertise. It was that the criteria lived in the judgment of whoever was conducting the review. Two capable analysts examining the same schedule produced different findings, because "acceptable" had never been written down. Month-over-month trends were unreadable, since a change in the result might reflect a change in the schedule or a change in the reviewer.
What the situation required was not better auditing but a documented standard: defined metrics, applied identically regardless of who applied them. I built that framework against DCMA criteria and it was adopted across the organization — into monthly audits, annual schedule reviews, and fiscal-year baseline reviews — with training developed so that new reviewers inherited the standard rather than reconstructing it.
The finding. An assessment is only as reliable as the documentation of its criteria. Organizations frequently invest in the rigor of the review while leaving the definition of the review undocumented, and then treat the resulting findings as data. The first artifact any assessment program needs is the written standard by which it judges — otherwise it is measuring its reviewers, not its work.
Requirements are a translation problem
At a university, faculty and staff submitted requests for modifications to the student information system. Technical staff built them. My role sat between the two, and the reason the role existed is that the two groups could not reliably describe the same thing to each other.
Requesters described outcomes in the language of their work — what a report needed to show, how a population needed to be defined, what a process was supposed to accomplish. Technical staff worked in the language of the database and its constraints, where an apparently simple request might be impossible, expensive, or achievable in a form the requester hadn't considered. Neither group was wrong. Each was describing the request accurately in terms the other couldn't fully evaluate.
The work was making the requirement legible in both directions: what was actually being asked for, what the software would and would not permit, and where the request needed to change to be buildable. Then, once it was built, confirming it — SQL queries and testing against the original intent, verifying the result produced what had been asked for before it went back to the requester.
The finding. A requirement is not a document that gets passed along. It's a shared understanding that has to be constructed, and it fails silently when each party believes the other means what they themselves mean. The verification step matters for the same reason: something can satisfy the written requirement and still not do what the requester needed, and the only way to know is to test against intent rather than against specification. Both failures are invisible without someone whose job is to hold both languages at once.
Assessment is the part that gets skipped
A training program for a hardware and software testing environment already existed when I arrived. It was outdated, it wasn't consolidated anywhere teams could reach it, and its modules didn't build on one another — each stood alone, so nothing accumulated.
Updating the content to current standards was the visible work. The harder question was how anyone knew it had worked.
The program's certifications had to satisfy multiple customers' external requirements, which meant a completion record wasn't sufficient. So the assessment became demonstration: a trainee built a working system from nothing — sequencing the hardware, wiring the fiber to the processors, configuring it correctly across the major platforms then in use. There was no partial credit and no way to pass by recognizing the right answer. The system worked or it didn't.
Sequencing mattered as much as the exercises. Modules were restructured so that each depended on capability proven in the one before it, which turned the program into an actual progression rather than a library. I then built a second tier above the existing entry-level program, for experienced staff and managers, and hosted the whole thing centrally so it functioned as one system rather than a collection of materials.
The finding. Most training programs assess recognition — did the trainee retain what was presented — because recognition is cheap to measure. Competence is a different claim, and it can only be evidenced by performance under conditions the trainee hasn't seen arranged in advance. The distinction is rarely enforced, and it is where certification programs quietly lose their meaning: an organization holds records showing qualification and has never actually observed the capability those records assert.
What visibility does to a conflict
An acquisition process had stretched to a length nobody could account for. Everyone involved had an explanation, and most of the explanations pointed at another department. The delays were understood as a relationship problem, and there had been no shortage of attempts to address it as one.
I built the schedule backward from the required delivery date — a reverse-planned integrated master schedule to DCMA standard, laying out every step, every approval, and every signature the process actually required, with realistic durations attached to each.
What that produced was not a plan so much as a picture. The timeline was consumed by hand-off structure: approvals routed in sequence that could have run in parallel, hard-copy signatures that idled on desks between steps, redundant reviews nobody had questioned because no one had ever seen the whole chain laid end to end. The bottlenecks were structural, and they were visible to everyone at once.
That changed the conversation. Once the delay could be pointed at rather than attributed, there was nothing to defend. Steps were consolidated, approvals parallelized, and signature handling revised. The template was adopted for long-range acquisition planning going forward, and the Army issued a Certificate of Appreciation for it.
The finding. Undocumented process doesn't stay neutral — it gets explained by whoever is affected by it, and those explanations tend to be about people. A process rendered completely and honestly gives an organization something to examine instead of someone to blame. Documentation is frequently framed as a compliance activity. It is at least as often a political one.
Contractually required, organizationally absent
More than once I arrived at an organization contractually bound to government standards it wasn't meaningfully following. Not through evasion — the contracts were real and taken seriously. But the standards existed at the level of the agreement, not at the level of the person doing the work. Understanding of what was required, and why, sat with a few individuals or a single group, and had never been written down in a form the people performing the work could reach.
So it became part of my annual objectives each time: document the process and produce work instructions for every person in the role.
I built them from nothing, in each case for software and technical procedures that had no existing documentation. Every step written for comprehension rather than for reference, with screenshots at each point. Branded to the department or organization, so it read as theirs. Version-tracked, in a consistent template, with training built alongside it — because a document nobody is walked through is a document nobody adopts.
Alongside that, I introduced structured scheduling tools in place of presentation-built timelines. The reason was accuracy of a specific kind: when a timeline is drawn by hand for a briefing, it can be adjusted to read more favorably than the underlying data supports. When it derives directly from the schedule, it cannot. The reporting stays tied to the record.
The finding. A standard an organization has agreed to is not a standard it is meeting, and the distance between the two is filled entirely by whether the people doing the work understand what is required and why. Formal documentation closes that distance — and it does something further that is rarely acknowledged as a benefit. Undocumented process is flexible in both useful and unhelpful directions: it permits adaptation, and it permits reporting that drifts from reality without anyone having to decide to distort it. Documentation removes that latitude. The resistance it sometimes meets is worth understanding on those terms rather than as an inconvenience.
