The AI enablement set, on one page

The situation at Halden Systems

1 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Bottom line. 78 percent of our people reached the end of the training for our engineering systems. 31 percent can predict what a step in those systems will do. That 47-point gap costs about $6.1M a year, and no better tool will close it. Another approach is needed.

They can follow the steps. They cannot say what the steps do.

That is not a complaint about depth of understanding. It is the difference between running a procedure and being able to predict its result, which is what somebody needs in order to tell when the screen has stopped matching the instructions, to judge whether an action can be undone, and to recover without asking. Lacking it, the only safe move is to stop and escalate, which is what 2.3 escalations per person per week are.

The organization

Halden Systems builds and sells engineering software.

The timezone spread is the figure that decides the delivery model, and the split between the last two rows is the one that decides who the program is for.

2 groups inside those 3,000 non-technical staff need naming, because the program treats them differently.

The 1,150 who work in engineering systems daily. Writers, designers, researchers, program managers and the senior half of support. Their work lives in repositories, issue trackers and build pipelines. They are the group whose capability gap costs money today.

The other 1,850, who were given an AI assistant anyway. Their work does not touch repositories, and the assistant went to every employee without regard to whether it suited the job. They are counted here because a tool nobody assessed them for is now in their hands.

The 4 earlier migrations at least moved people whose work had to move. This one reached 1,850 people with no case for reaching them, and it repeats the same error more widely: capability was never measured before the tool arrived.

5 of the 9 sites have nobody who can answer a question about repositories, pipelines or issue trackers during the local working day.

What is failing

Over 4 years Halden moved most of its non-engineering work into engineering systems. Documentation became docs-as-code. Design tokens went into a repository. Program management moved into the issue tracker. Support began authoring runbooks in markdown.

Every one of those moves was run as a tooling migration: a cutover, a demonstration, a recording, and a channel for questions. None was run as a capability problem, and two measurements show what that produced.

78 percent of the 1,150 reached the end of the training. 31 percent can predict what a step will do. Our completion dashboard reports the seventy-eight and calls the program finished.

A person who follows steps without understanding them is fine until the screen stops matching the instructions. Then they escalate. That happens a median 2.3 times a week each, which across the 1,150 comes to roughly 760 engineer hours absorbed every week.

64 percent say they are afraid of breaking something that cannot be undone. Given that they cannot predict what any step will do, that fear is accurate rather than timid, and it is the reason the escalation rate is a floor rather than a peak.

How we measured the 47-point gap

Bottom line. The 78 and the 31 come from two different instruments, and we say so before anybody asks. The 78 is a completion count we already had. The 31 is a scored check of whether somebody can predict what one of our systems will do.

Both known errors inflate the same side of the subtraction, so 47 points is a floor, not an estimate. The check becomes the level 2 measure (whether somebody can now do the thing), quarterly, with a stated condition under which we throw it out.

Three things a reader should take from this and nothing more.

1. Most of this population finishes training it cannot act on. That is the only claim the comparison supports, and it is enough.
2. 47 is a floor. Non-response flatters the 31 and mandatory completion flatters the 78. If the measurement is wrong, it is wrong in the direction of making the problem look smaller.
3. The check is repeatable and the program is accountable to it. Same item bank, same scoring, quarterly, reported by site before it is reported company-wide.

The condition under which we drop it. If the pass rate rises while escalations per person per week do not fall and median days to a first merged change does not move, we are measuring test-taking rather than capability, and the instrument is wrong rather than vindicated. Both of those behavioral measures are already counted and neither is self-reported.

The instrument, its scoring, the distribution and the cadence are in the capability survey.

The AI assistant is the fifth rollout, not a new problem

The assistants went to the same people, through the same workflows, on the same playbook.

The survey asked all 3,000 non-technical staff four questions about it.

The third row is the one that matters, because an assistant is only safe for somebody who can judge when it is wrong. On that measure fewer than a quarter of them are equipped to use it, and more than half have already met the failure it produces.

Somebody who cannot yet judge the output learns the wrong lesson from a confident wrong answer, which is that they cannot tell good answers from bad ones. The reasonable response is to stop using the assistant, and to say nothing about having stopped, because the rollout was announced as a success.

That is why usage will keep looking healthy while the benefit does not arrive. We are counting who opened the tool, not who can use it safely.

What was already tried, and what it produced

1 site ran a pilot at its own cost. Dublin, 24 people from the inner population, 6 weeks, a written runbook and one facilitated change each, with a named person to ask.

Median days to a first merged change fell from 41 to 9 for that group. The pilot cost nothing beyond existing staff time, which matters for one reason: it answers the objection that nothing can begin before the funding decision. Something already did.

What we already built, and what it teaches

Four years of rollouts produced a library of 140 training modules. It is the largest asset the program inherits and the clearest evidence about what went wrong.

Reading all 140 against one question, whether somebody who works through it comes out able to predict what the system will do, 96 fail it.

Three of those rows are the diagnosis restated as an asset register. The 41 are how 78 percent learned to follow steps they cannot explain. The 19 duplicates are the $410,000 of regional spend, showing up as content rather than as invoices. The 24 are 4 years of tool churn nobody was funded to clean up.

That is why the answer is not a bigger library. The content plan keeps 44 of the 140, adds 35 short pieces, and sizes the result at 79.

What the scale changes

At 1,200 people in one building, one determined person holds a program together by force of will. At 5,000 across 9 sites, 3 constraints bind that would not otherwise.

1. No hour of the working day is shared by every site. 17 hours separate the first site's morning from the last site's evening, and 18 percent say they would attend an optional live session. Any plan that rests on live attendance is refuted by our own survey before anyone costs it.

2. Proximity to help predicts capability better than job title does. The confidence gap between sites with a local expert and sites without one is 22 points, wider than the gap between job families. Median days to a first merged change is 41 company-wide and 58 at the 5 sites with nobody to ask.

3. 9 sites are each buying their own training, at about $410,000 a year of overlap. No site director was wrong to do that. Waiting for a central answer costs them more than buying locally, and the duplication is a symptom of having no shared owner rather than of poor judgment.

Where the money is

Three lines, and they do not come from the same population.

Revenue, which comes from customers rather than staff. Halden sells engineering software, and its customers need the same kind of teaching its own people do. Solution engineers currently spend about 6 days per new enterprise customer delivering that teaching by hand, across 240 new enterprise customers a year. 95 partner implementations a year depend on partner staff holding a certification we do not currently offer.

The connection to the internal problem is the machinery, not the audience. The content, the assessment and the certification that would close the internal gap are the same assets a customer program sells, which is why one function should own both rather than two functions building them twice.

Cost, which comes from the 1,150 and their colleagues. Roughly 760 engineer hours a week at $145 fully loaded, plus the $410,000 of duplicated regional spend, plus about 1,900 internal tickets a month whose answer already exists in writing.

Efficiency, which comes from time. 41 median days to a first merged change, 58 at the sites without an expert, and nine in the Dublin pilot.

Who decides

The Chief Operating Officer funds it. The problem crosses every function, and no single department can pay for it from its own budget.

The VP of Engineering is its loudest advocate, because these are their engineers absorbing 760 hours a week. They are also the wrong owner. A program owned by engineering gets built for people who think like engineers, and those people are not the ones failing.

The nine regional site directors decide whether it works. They hold the budgets that currently pay for the duplication, they employ the people the program serves, and they are the ones who have been coping without help. A plan that takes their budgets before it has earned their trust turns the constituency it needs into the opposition that stops it.

Literature review

2 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented. The research below is not, and it is recorded in data/literature.yaml with the date each source was read.

For the Halden Systems capability program.

Bottom line. The evidence says the gap is not effort and cannot be closed by more training of the kind already delivered. 88 percent of organizations have adopted AI and 6 percent are real value from it.

The one-line version

88 percent of organizations have adopted AI. 6 percent are getting real value from it. The gap is not effort.

What the evidence says, in seven lines

1. One program for everyone is worse than none. Support that helps a beginner makes an expert perform worse. Not a preference. A measured effect.
2. Recordings teach the steps and skip the thinking. That is the half that transfers.
3. Sitting near someone who knows beats being trained. It predicts capability better than any course does.
4. Using the assistant does not teach judgment about it. Usage is up. Trust is down. More usage will not fix that.
5. Fear makes people retreat to what they know. That is the exact behavior we are trying to change, and half the staff are afraid.
6. Paying people to finish a course buys finished courses. We already have those. What we lack is understanding.
7. The time does not exist. 3 in four have no learning hours that are not stolen from delivery.

The three numbers to remember

The third one is the argument for this program in a single ratio, and it is worth being exact about what it compares. DORA measured how much each technical capability lifts organizational performance, then split the teams by the quality of their internal documentation.

Version control returned 278 percent for the teams whose documentation was above average, and 27 percent for the teams below it. The same practice, adopted by both groups, paid back roughly ten times more where the writing was good.

Good means quality here rather than volume, and the distinction is the whole finding. DORA scores documentation on eight attributes, among them whether it is clear, whether people can find it, and whether it can be relied on. Nobody was asked how much of it they had.

The claim is therefore not that teams should write more, which is what a learning function is usually assumed to be proposing. It is that the quality of the writing already being produced decides how much the engineering investment beside it returns. Documentation is a multiplier on that spend, not a line item competing with it.

What we got wrong, and are keeping in

PwC surveyed 50,000 workers and found the opposite of what we assumed. Daily AI users feel more job-secure, not less, at 58 percent against 36 for occasional users.

Fear is therefore not a wall to clear before people start. Use appears to reduce it.

That flips the plan. We do not need to resolve the anxiety first. We need to get people using the thing safely, in small ways, quickly. The fear comes down as a result.

Both things are true at once. Fear makes people retreat, and using the tool reduces fear. It is a loop, and our job is to break into it rather than to argue with it.

Where the fear actually sits

Half the staff think this tool may cut their jobs. 2 in five think that getting good at it would prove they can be replaced.

1 in eight would say that to a manager. So every conversation leadership has had about this has been with the 1 in eight.

There is a hard finding here. Vague reassurance makes it worse, not better. We told people nobody is losing their job. Under a quarter believe we have been straight with them. Those are the same fact.

What replaces vague reassurance is a commitment specific enough that somebody could hold us to it. That means three things a reader can check, and the reassurance we already gave has none of them.

A date, so that the promise covers a stated period rather than an indefinite one. A scope, so that it names which roles and which sites it applies to instead of gesturing at everybody. Third, a notice period, so that if the position changes, people hear it on a known timetable rather than on the day it takes effect.

The promise we made, that nobody is losing their job, cannot be kept, because it was never specific enough to be broken, and staff read that accurately as costing leadership nothing to say. A commitment that could be breached is the only kind worth making, because it is the only kind that puts something at risk for the person making it.

What we will not cite

The claim that 70 percent of change programs fail. It is everywhere and it has no data behind it. It traces back through citations to an assertion.

We are naming it as unsupported on purpose. It is the most tempting number available to us, and saying so is what earns the right to make an evidence argument at all.

How to read the consultant reports

McKinsey, BCG, Deloitte, PwC and the analyst houses are all in here. They carry type: consultancy research in data/literature.yaml, so a reader can see exactly which entries this section is about instead of taking our word for the grouping.

Read them differently, because each is published by a firm that sells the remedy its own research calls for. The clearest case is the McKinsey survey we quote most often. It reports that adoption has run far ahead of value capture, and it is published under the firm's AI practice, which is visible in the URL recorded against it.

The finding names a gap and the publisher sells the work of closing that gap. PwC surveys the workforce and sells workforce transformation. The pattern holds across the tier, and it is the reason these sources sit in a group of their own.

None of that makes the findings wrong, and their samples are far bigger than anything we could field. What it means is that the choice of which problem to measure is not neutral, and the size of a number is no evidence that its subject is the thing most worth fixing.

We cite them for two things. Scale, because nobody else surveys 50,000 people, and what the sponsor has already read, which matters more: the COO has seen the McKinsey number before we walk in, and a director who cannot handle it accurately loses the room to a figure they never checked.

We do not cite them for whether something works. That is what the research tier is for.

Gartner and Forrester get a narrower job still. They belong in the vendor section as a market map. A procurement that cites a quadrant as its reason will be asked why, and will deserve it.

Verification status

Six sources opened and read on 2026-09-07: DORA, Stack Overflow, McKinsey, PwC, GitLab, and the paper debunking the 70 percent claim. Every figure above comes from those.

Eight more are named and unread. They carry no figure, and none of the argument rests on them.

The 13 research findings are stated at a level we can defend in a room, which is a lower bar than the papers behind them would support and the right one for a funding meeting.

What the evidence does not say

It does not say this will work. Every finding is about mechanism, and mechanism shapes a design without predicting a result here.

It says nothing useful about what multi-site coordination costs, which is the largest unpriced risk in the plan.

The work on trusting automated output also predates assistants of this kind. The effect is old and solid. The systems are new. We treat the carry-over as likely rather than proven, and the strategy document should say so in those words.

The capability survey

3 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Bottom line. 1,237 Halden Systems staff answered, a 41% response rate. The 78 and the 31 that every document quotes are not survey items. The 78 is a completion count from the learning platform. The 31 is the pass rate on a scored check of the 1,150 who work in engineering systems daily, described in the capability check below.

What this survey measured is what sits underneath that gap. The items least convenient for this program are in the results, because a survey where every item supports the proposal is a survey nobody ran.

The instrument

Two design decisions are worth stating, because both change what the numbers mean.

We surveyed all 3,000, not the 1,150 who work in engineering systems daily. Sampling only the inner population would have measured the program's convenience rather than the company's problem, and the assistant went to everybody regardless of whether their work touches a repository.

Free text came last. A respondent who has already answered 18 structured items has been reminded what the subject is, and writes something specific instead of something general.

The headline

The first row is not timidity. Somebody who cannot predict what a step will do is correct to fear an irreversible one, and the second row is the cost of that fear landing on an engineer. The 47 points between the 78 and the 31 is the finding the program exists to answer; the instrument that produced the 31 is next.

The capability check

The 31 is not an agreement percentage. It is the share of the inner population who could predict what one of our systems would do, on a scored check. It is the measure the program will be held to. Everything here is repeatable. The condition under which we would stop trusting it is stated in advance.

The six items

Each item shows a real state from one of our 4 engineering systems and asks what a named next action will do, and why:

• a branch that has diverged
• a preview that renders correctly against a build that fails
• an automation that read the wrong field
• a permissions error on an action that cannot be undone
• an assistant answer that is wrong and sounds certain
• a pipeline that failed on something other than the code

Scored against one correct outcome plus the reason, with partial credit for a right answer reached by wrong reasoning. Pass is 5 of 6. The reason is scored because a person who predicts correctly without being able to say why cannot do it on the seventh system, and the seventh system is already coming.

The distribution

Fielded over 2 weeks to the 1,150; 712 answered, a 62 percent response rate. Percentages are of the 712 respondents, not of the 1,150.

The middle row is the one to watch over time. It is the population that moves first, and it is where the first 2 quarters of the program should show up if the design is right.

Why the comparison is imperfect, stated in full

Different instruments measuring different things. Completion is an event. Prediction is a performance. Nothing makes the two arithmetically comparable, and we are not claiming a difference of means. We are claiming a direction.

Different denominators. The 78 is a census of 1,150. The 31 is 712 volunteers. Re-weighting the result by site and job family to the known shape of the population moved it by under 2 points. We report the unweighted figure, because the adjustment is not what carries the argument and a reader should not have to take a correction on trust.

Non-response runs in the flattering direction. A person who suspects they would do badly on a capability check is the least likely to take one. Completion is inflated for the mirror-image reason. Both errors push the gap down, which is why we describe 47 as a floor and claim nothing stronger for it.

What the instrument becomes

• An item bank of 30, fielded as parallel 6-item forms, so the check cannot be passed by having taken it before.
• Items decay with the systems. About 12 percent of the content library is wrong at any moment; items about those systems are wrong at the same rate, and the teams that own each system retire them on the same cadence they carry their release notes.
• The bank is published internally. Nobody is being trick-tested. A person who studies the bank and can then predict what the systems do has done the thing we wanted.
• Quarterly, census-attempted, with manager time protected, reporting the response rate alongside the result every time.
• Reported by site first. Proximity to help predicts capability better than job family does, and a single company number hides the 5 sites the program exists for.
• The half-time analyst owns it, including the judgment about when the number has stopped meaning anything.

What this number will never be asked to do

• Carry attribution. A rising pass rate is evidence the program is working. It is not proof that nothing else was happening.
• Benchmark against other companies. No comparable instrument exists outside Halden, and any figure offered for that purpose was invented by somebody.
• Appear in the revenue case. Revenue attribution is the weakest evidence this function offers, and mixing a capability measure into it is how a good number gets spent on a bad argument.

The assistant

The drop from 71% to 44% is where the rollout actually stands, and neither figure is the one that matters. Judging when the output is wrong is the skill, and 22% report having it.

What people will not say to a manager

The 34-point gap between the first 2 rows is why leadership's read of this is wrong. Every conversation on the subject has been with the 12%.

The last row sits against a reassurance we already gave. We told people nobody is losing their job, and under a quarter believe we have been straight with them. Those are the same fact.

Time, and what gets in the way

The third row is an equity problem before it is a capability problem. It selects for people without caring responsibilities, and any plan that assumes it will continue is choosing that.

Incentives, and what people would actually do

Rows 2 and 3 point in opposite directions and settle the incentive design. Paying for completion motivates 16%, and completion is already at 78%. Recognizing contribution reaches 61%, and contribution is the thing we have none of.

Row 4 constrains how. Any scheme that requires somebody to be visibly a learner reaches about a quarter of the population, and loses the reset expert entirely.

By site and by language

The 22-point gap is wider than the gap between job families, which is the finding that makes proximity to help a better predictor of capability than role.

The 19% is reported rather than hidden. It is the site we understand least, and it is one of the 5 with nobody to ask, so the true picture there is probably worse than these results suggest.

The results that are inconvenient for this program

Kept because removing them would make the rest untrustworthy.

29% found our previous training useful. That is this function's own report card, and it is the strongest argument against giving this function more money.

Only a third think more training is the answer. They are largely right, which is why the program is built around local help, contribution and time rather than courses.

18% would attend an optional session. Any plan resting on voluntary synchronous attendance is refuted by its own survey before anybody costs it.

Free text, coded

3 free-text items, 1,237 responses, 7 themes. Counts are responses coded to each theme, and a response can carry more than one.

"I have been a writer for fifteen years. I was the person people asked. Now I copy commands from a document and hope."

The largest theme is not about tools. It is about having been competent and no longer being so, and a program that treats it as a skills gap will be answering a different question than the one people are asking.

The people this is for

4 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Bottom line. 6 learner personas and 1 sponsor, drawn from Halden Systems staff and derived from named survey themes. The 6 account for 93% of the population, not 100%, and the missing 7% is left visible. Every persona names what it rules out, because a persona that refutes nothing is decoration.

The six, and what each one refutes

The right-hand column is the working half. A design that survives all 6 of those constraints is narrower than the one anybody would have proposed, which is the point of building them first.

What each one needs

The reset expert, 19%. She was the person others asked. The documentation moved into the repository and her expertise did not move with it. She needs a mental model rather than a course, and she learns fast once something is explained instead of demonstrated. Any material that requires her to publicly identify as a beginner will not be opened. Themes: competence reset, fear of permanence.

The stranded newcomer, 18%. Her question is answered 18 hours later, by which time she has worked around it. She needs help that does not depend on somebody being awake, and written material good enough to answer the second question as well as the first. Themes: no local help, fear of permanence.

The workaround builder, 16%. He keeps a private file of exact commands and a standing favor with one engineer. He is productive and he is invisible to every measure we have. His private file is most of a good runbook already. Theme: coping machinery.

The quiet complier, 16%. She attends every session, completes every module, and uses none of it. She is the reason 78% can follow the steps and 31% understand them. She needs a specific answer about what the tool will and will not be used for, not another reassurance. Themes: the replacement bind, no time to absorb, competence reset.

Burned by the assistant, 14%. It gave him a process that did not exist, in confident prose, and he caught it barely. He is a rational non-user, and counting him as an adoption failure would push him back toward the behavior that nearly cost him. He needs the skill nobody taught: how to tell which answers need checking. Themes: burned once, competence reset.

Never knew different, 10%. She learned the repository in her first week alongside everything else and does not understand why her colleagues struggle. She should be recruited rather than trained. A tenth of the population is already the answer to the other nine tenths, and it is the cheapest capacity in the building. Themes: none, and that absence is the finding.

The seventh, who is not a learner

The regional sponsor. Site director, Asia-Pacific, 200 staff, 0% of the learner population and the person who decides whether any of this works.

He has bought training twice from his own budget, because waiting for a central answer cost more than paying for a local one. Both purchases overlap with what other sites bought. He is not the cause of the $410,000 of duplication; he is a rational response to having no shared owner.

What he needs is a reason to stop buying, which means something arriving faster than his own procurement does. Consolidation that reaches him a year from now will be ignored, correctly.

He rules out any plan that starts by taking the budgets back, and that one limit removed the easiest saving from the strategy.

The 7% nobody speaks for

The 6 learner personas sum to 93%. The remaining 7% is not assigned, and the gap is left in rather than distributed.

Personas that sum to exactly 100% have been rounded until they did. The people in that 7% are mostly at the 2 smallest sites, where the response rate was lowest, and the honest statement is that we do not know enough about them to write one. That is a finding about our sampling, and it belongs in the numbers rather than in a footnote nobody reads.

How these were derived

Each persona names the survey themes it rests on, and every theme in the survey reaches at least one persona. Both directions matter. A persona with no theme behind it is a character somebody invented, and a theme with no persona in front of it is evidence the design has quietly dropped.

"Never knew different" carries no themes on purpose. She was built from the absence of complaint in a cohort that joined after the migration, which is a different kind of evidence and is labeled as such rather than dressed up as the same kind.

The first 90 days

5 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

The entry plan for a director newly hired into Halden Systems.

Bottom line. The first 90 days end with a funding decision made and procurement in flight, not with a signed contract. 10 days to find out what is true, 20 to gather evidence, thirty to build the case, thirty to ask for the money.

Why a newly hired director writes this

These documents are written by somebody hired into the situation, not by an observer describing it. That frame is worth adopting for three reasons, and the third is the one that matters.

It is the frame a director interview already uses. Some version of "what would you do in your first 90 days" is asked in nearly every one, and answering it with artifacts rather than assertions is a better answer than the question expects.

It sequences the set. Ten documents with no narrator arrive in an arbitrary order. With a start date they arrive in the order somebody would actually produce them, and the sequence is itself an argument about how this work should be done.

It also answers the question the set would otherwise raise. A reader looking at a strategy document with a survey of 1,237 people in front of it will ask where that came from and who authorized it. The answer is that it was the first month's work, and that a proposal written before it would have been an opinion.

Ten, thirty, sixty, ninety

The usual plan has three phases. This one has four, and the extra phase is at the front.

Days 1 to 10 produce nothing that proposes anything. The output is a written list of what is not yet known. The sponsor, the VP of Engineering, all 9 site directors, and a sample of the population. Read the prior rollout materials, the ticket queue, and every line of regional training spend, and ask each site director what they bought and why without implying it was wrong, because it was not.

10 days is deliberately short. A plan produced inside it is one that arrived in the new director's luggage, and the fastest way to lose the 5 site directors who decide whether this program reaches their people is to arrive holding the answer.

Days 11 to 30 are evidence, and it arrives on day fifteen.

A thirty-day survey is a hard thing to ask a sponsor for, and it was the wrong design. Here is the replacement.

The pilot starts on day 11 at 1 site with a local expert and one without. It already exists and costs nothing to begin, and that comparison is what the scaling case will need.

The long instrument is a second pass. It deepens the picture rather than gating it.

What does not happen here is committing to a number in front of the Chief Operating Officer before the pulse lands. The cost of guessing early is that the evidence then has to agree with the guess.

Days 31 to 60 are the case. The survey closes on day 41; analysis and personas to day 46; the strategy document to day 53; the project plan to day 58. Early pilot data arrives across the same period and goes into both.

No hiring. The shape of the team follows from the strategy and the procurement decision, and a requisition opened in month two is a guess that gets defended for two years.

Days 61 to 90 are the ask, with procurement started and not finished. Deck to day 64, readout around day 65, statement of work to day 70. The request goes to vendors around day 70 with responses due near day 100, and the evaluation weights are fixed and written down before any submission is opened. The scaling proposal completes by day 76.

The two things this plan will not claim

It does not close a vendor contract. A response window is 40 days and reference calls take longer than that. A ninety-day plan that ends with a signature tells anybody who has run a procurement that the writer has never run one, and it is the most common way these plans give themselves away.

It does not centralize regional budgets in year one. Roughly $410,000 a year is being spent twice across 9 sites, and it is the most obvious saving in the case. It is also the one that would cost the program the regional site directors, who are buying locally because waiting for a central answer costs them more. They stop when something arrives faster than their own procurement does, and not before.

Both refusals are in the plan on purpose. A ninety-day plan is read for what it promises, and the two most informative lines in one are usually the promises it declines to make.

Capability strategy

6 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Bottom line. Of the 1,150 non-technical staff who work in our engineering systems, 78 percent can follow our documented steps and 31 percent can say what those steps do. That gap costs about $6.1M a year in absorbed engineer time and duplicated spend. We are asking for $2.1M over three years to close it, decided this quarter.

Two kinds of number appear below. Figures about Halden Systems and its staff come from data/scenario.yaml and data/survey.yaml, and are invented for a fictional company. Figures credited to DORA, Stack Overflow, McKinsey or PwC are real, were read on 2026-09-07, and are recorded in data/literature.yaml. They are never mixed unlabeled.

For the Chief Operating Officer. Prepared in the first 90 days, and the decision it asks for is a funding commitment, not an approval to plan.

The gap, and what a year of it costs

Over 4 years we moved most of our non-engineering work into engineering systems, and we ran every one of those moves as a tooling rollout rather than as a capability problem. The tooling arrived. The capability did not.

78 percent of the people who work in those systems can follow the documented steps. 31 percent can say what those steps do. That 47-point gap is the diagnosis, and our completion dashboard reports it as a success because completion is the only thing it measures.

A person who can follow steps without understanding what they do is a person who escalates whenever the steps stop matching what is on the screen. That happens 2.3 times a week per person, across roughly 1,150 people, and each escalation lands on an engineer.

The sums are plain on purpose. Every term in them is already written down somewhere we can go and look.

Nothing in that table requires a new measurement. The interruptions are in calendars, the duplicate spend is in nine regional budgets, and the tickets are in a queue with their answers already written down somewhere else.

That is the cost of the year we just had. It is also the cost of the year ahead, because none of the four moves that produced it is being reversed and a fifth has already started.

What we are not solving

A strategy that addresses everything is a wish list, and an executive reading one correctly concludes that nobody has chosen. This program does not attempt the following, and each omission is a decision rather than an oversight.

We are not retraining the engineering organization. Their capability is not what is failing, and a program that arrives asking for their time on top of the interruptions will be read as a second tax.

We are not building a learning platform. The budget document costs that decision and recommends buying. We have no advantage in that market and no reason to acquire one. We are building everything that runs on it, which is a different sentence and the one that matters.

We are not centralizing regional training budgets in year one. Nobody who bought duplicate training was wrong to: waiting for a central answer costs a site director more than buying locally. Taking that authority away before we have earned it converts our most useful constituency into an opposition, and the regional-sponsor persona refutes the plan that tries.

We are not promising a revenue number we can defend. See the ordering below.

We are not fixing the fifteen years of undocumented internal knowledge that sits behind those 1,900 tickets. That is a real content project and it is not this one.

How we will know, before what we will do

The measurement plan comes first on purpose. A reader who sees the solution before the measure has no way to tell what would count as failure, and by then the answer is designed to fit.

We report against the four levels our learning function already uses, and we say plainly which of them we can reach today.

Level 1, reaction. Whether people can use what we give them. Reachable now, from the same route counters the documentation already carries.

Level 2, learning. Whether somebody can now do the thing. This is the level the whole program turns on, because it is the level where the 47-point gap lives, and it is the one most programs skip because completion is cheaper to collect. Each unit publishes criteria you can observe, and a unit is admitted only when somebody who worked through it alone can meet them.

Level 3, behavior. Whether the work changes. Measured as escalations per person per week and as median days to a first merged change, both of which we are already able to count.

Level 4, results. What it costs the business. Engineer hours returned, tickets deflected, duplicate spend consolidated. Reachable for cost and efficiency, and honestly not reachable for revenue, which is why revenue is ordered where it is.

The failure conditions are stated with the same numbers. If escalations per person do not fall within two quarters of a site going live, the design is wrong rather than the rollout. If the completion rate rises while the understanding rate does not, we have bought more of the metric we already had too much of.

The case, in the order it will be heard

Revenue leads because it is the largest number. Cost and efficiency come second and carry the argument, because they are the ones we can prove.

We say that out loud rather than hoping nobody notices the ordering, and the reason is not modesty. Revenue attribution for an internal enablement program is the weakest evidence any learning function offers, and every function that has overclaimed it has been caught doing so by somebody in a finance review. A reader who spots the ordering before we name it stops trusting the rest of the document.

Revenue, and the weakest evidence. Solution engineers spend about 6 days per new enterprise customer teaching material a certification program would carry, across 240 new enterprise customers a year. 95 partner implementations a year depend on partner staff being certified, and each is delivery capacity we do not have to hire for.

This is the part of learning that earns rather than spends. It is also the part where attribution is an argument rather than a measurement, and we will be asked which it is.

Cost, and the easiest to verify. The $5.7M of absorbed engineer time is the largest single line and the one a skeptic can check without our help. The $410,000 of duplicate regional spend is the fastest saving available, because consolidating it needs an owner rather than a behavior change.

Efficiency, and the one that compounds. Median days to a first merged change is 41 company-wide and 58 at the 5 sites with nobody to ask. The pilot runs at nine. We are not targeting zero: a first change that takes an hour would mean the task was not real.

It compounds because the person who reaches a first merged change stops being a source of escalations and starts being somebody a colleague can ask. That is the same mechanism as the 22-point site gap, run forwards instead of backwards, and it is why the number to watch is the 5 sites without a local expert rather than the company median.

What the evidence says about the design

Four findings from the literature review shape the program, and each one rules something out.

One program for everyone is worse than none. Support that helps a beginner measurably degrades an expert's performance. The program is therefore tiered by what somebody can already do, and a single mandatory curriculum is refuted before it is proposed.

Sitting near somebody who knows beats being trained. Proximity to help predicts capability better than role does, and our own 22-point confidence gap between sites with and without a local expert is larger than the gap between job families. The unit of the program is therefore a person at a site, not a course in a catalog.

Recordings teach the steps and skip the thinking, which is the half that transfers. That is precisely how we produced a population at 78 percent completion and 31 percent understanding.

Paying people to finish a course buys finished courses. Completion is already at 78 percent. Buying more of a metric that is nearly full is the definition of spending without effect, so the incentive is built on contribution rather than completion. Somebody who answers a colleague's question, fixes a runbook, or lands a review is doing the thing we want more of, and all three are countable without a new system.

There is external evidence for the shape of this, and one figure carries it. DORA measured how much each technical capability lifts organizational performance, then split teams by the quality of their internal documentation. Version control returned 278 percent above average and 27 percent below it. The same practice, adopted by both groups, paid back roughly ten times more where the writing was good.

The commitment we owe people, and who owns it

Half our staff think this tool may cut their jobs, and 2 in five think that getting good at it would prove they can be replaced. 1 in eight would say either thing to a manager, so every conversation leadership has had about this has been with the 1 in eight.

We have already tried reassurance. We told people nobody is losing their job, and under a quarter believe we have been straight with them. Those are the same fact: a promise with no date, no scope and no notice period cannot be kept, because it was never specific enough to be broken.

What we owe them is a job-security promise specific enough to be broken, owned by somebody rather than offered in a town hall. It reads:

"No role will be cut as a direct result of adopting the assistant before June, and if that changes you hear it from us 90 days ahead."

The Chief People Officer owns it and publishes it where anybody can hold us to it. A date, a scope and a notice period are what make it a promise rather than a mood.

This is not a soft item. PwC surveyed 50,000 workers and found that daily AI users feel more job-secure than occasional ones, at 58 percent against 36. Fear makes people retreat to what they already know, and use appears to reduce the fear, so the two findings are a loop rather than a contradiction. Our job is to break into the loop safely and early, not to argue with it.

AI, which is a chapter and not a program

The assistants went to everybody, into the same workflows, with the same rollout playbook that produced the gap we are already paying for.

71 percent have used the assistant. 38 percent would sign their name to its output. 22 percent say they can tell which answers need checking, and that last figure is the actual skill. 57 percent have had an answer that was wrong and sounded certain, which is the best predictor we have of somebody having quietly stopped.

The market is not ahead of us here. McKinsey found 88 percent of organizations have adopted AI and 6 percent are capturing real value, and the gap did not close between their 2025 and 2026 surveys. Two years of a flat gap is a structural finding rather than an early-days one.

Stack Overflow found developer use rising from 76 to 84 percent while distrust of accuracy rose from 31 to 46 in the same population of 49,000 people. More adoption is not producing better judgment.

None of that argues for a separate AI program. It argues that the assistant is the fourth thing we have handed this population without teaching them what it does, and it will not be the last. A strategy whose subject is a tool expires with the tool. This one is about the capability underneath, so the next arrival is a chapter rather than a rewrite.

Who builds it, and who keeps it true

The platform is bought. Everything a reader learns from is written here, and the question a reviewer should ask is who writes it, who keeps it correct, and who says it is good enough.

The enablement function, 2.5 people. A program lead who designs the thing and owns the standard. A content lead who writes the core units and edits everything else against that standard. A half-time analyst who runs the 4 levels of measurement. That is the whole permanent team, and it is sized against a library of 79 pieces rather than the 140 modules we have. The content plan says which of the 140 survive the audit and what replaces the rest.

The teams that own each engineering system own the truth of what we say about it. Our 4 systems ship continuously, so anything we write about them is wrong within months. A central team of 2.5 cannot chase 4 release trains and should not try. Each owning team carries its own pages the way it carries its own release notes, and updating them is part of shipping rather than a favor to us.

The enablement function holds the standard, not the text. It sets what a unit must do, edits for it, and refuses one that does not meet it. That refusal is the quality gate, and it is the same bar as level 2: a unit is admitted only when somebody who worked through it alone can meet the criteria it publishes.

The local experts deliver and do not author. This is worth stating because the opposite is the natural reading. They are given 4 hours a week and a title, they run units, they coach, and they report what is wrong. Asking 9 part-time volunteers to write the curriculum would produce 9 curricula, which is the duplicate spend we are trying to end.

The row that carries the most risk is the fifth. It asks 4 engineering teams for something they did not ask for, so it is on the risk register with a named owner, and gate 3 does not close until each of the 4 has accepted it in writing.

Who owns it

The Chief Operating Officer funds it, because the problem crosses every function and no single department can pay for it out of its own budget.

It is not owned by engineering, and that needs saying because the VP of Engineering is its loudest advocate. It is their engineers absorbing the 760 hours, so their enthusiasm is rational. A program owned by engineering also gets built for people who think like engineers, which is the population that is not failing.

The nine regional site directors are the constituency that decides whether this works, because they are the ones currently paying for training out of their own budgets and coping without a shared owner. They are consulted on the design before it is funded, not briefed on it afterwards.

What we are asking for

$2.1M over three years, against an annual gap cost of $6.1M, decided this quarter. The model is in the budget document and the first year is recovered inside the first year, which is a lower claim than these programs usually make and one we can hold.

Procurement is already in flight and no vendor contract is signed inside the 90 days. A plan that signs inside the window tells anybody who has run a procurement that we have not.

The scaling proposal carries the kill criteria. If the program cannot be run by somebody who did not design it, it is a consulting engagement with an internal invoice, and we should stop it rather than fund a second year.

The objections, and what answers them

7 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Two kinds of number appear below. Figures about Halden Systems and its staff come from data/survey.yaml and data/scenario.yaml, and are invented for a fictional company. Figures credited to DORA, Stack Overflow, McKinsey or PwC are real, were read on 2026-09-07, and are recorded in data/literature.yaml. They are never mixed without being labeled.

Bottom line. 3 objections arrive every time, all reasonable, and two of them are partly right. None of them changes the recommendation, and the answers are below.

Every strategy of this kind meets the same 3 objections, all of them reasonable, and two of them partly right. Each is answered below with the evidence rather than with reassurance.

"We do not need a study. We need to start."

This is the strongest objection and it deserves the strongest answer.

We are not proposing to wait. We are proposing to start on day one and hold the money until day sixty.

The pilot runs from day one. It already exists and costs nothing to begin. Eight other things start in the first week, and every one of them is listed below. Nothing is on hold except the spending commitment, which is the only decision that gets harder to reverse.

The external evidence

88 percent of organizations have adopted AI. 6 percent report real value. That is the action-first path, measured across the whole market by McKinsey in 2025. Two thirds have not begun to scale it. The difference between 88 and 6 is not who moved fastest.

Developer AI use went from 76 to 84 percent in one year. Distrust of its accuracy went from 31 to 46 percent. More adoption, worse outcome, same 49,000 people. Doing more of the same thing is not the missing ingredient.

The same investment returns 278 percent or 27 percent depending on documentation quality. That is DORA on version control, and the pattern repeats across every practice they studied. Acting before checking the precondition wastes the action rather than accelerating it.

The internal evidence, which is harder to argue with

Scenario figures from here to the end of this section.

We have already run this play three times.

Three migrations, each with a demonstration, a recording and a channel. 29 percent rate the training useful. Around $410,000 a year goes to regional training bought twice because waiting for a central answer cost more than paying locally.

The bias for action has already been exercised here. That is the invoice.

One more thing worth saying out loud

You get one credible relaunch. A second attempt at the same population meets more resistance than the first, because people remember. Choosing wrong in week one means defending it for two years.

"30 days for a survey is too long."

Correct, and the plan changed rather than being defended. There is real evidence on day fifteen, and the table below shows how it arrives that early.

The pulse is 6 questions open for 7 days, which is short enough that people answer it. The long instrument is a second pass that deepens the picture, and by the time it lands we have already been acting for a month.

"This is a training problem. Buy training."

Partly right, and the part that is wrong is the expensive half, because it buys more of the thing the organization already has too much of.

Completion is already at 78 percent. Understanding is at 31. We can buy more completion and it will change nothing, because completion was never the thing in short supply.

16 percent say a reward for finishing a course would motivate them. The population has worked this out already.

What starts in week one

Nine things start immediately, none of which waits for the survey to close or needs a budget line approved first.

1. The runbook pilot, at 1 site with a local expert and one without. That comparison is what the scaling case will need.

2. Stop reporting completion. While the dashboard says 78 percent, nobody believes there is a problem.

3. Cancel one competing initiative. Two thirds of staff report more changes than they can absorb. Removing one is the only credible way to say this matters.

4. Promise in writing that the assistant will not cost anybody their job. "No role will be cut as a direct result of adopting the assistant before June, and if that changes you hear it from us 90 days ahead."

   A promise with no date, no scope and no notice cannot be broken, so it costs nothing to make. That is why only 23 percent believe the one we already gave.

5. Name local experts at the five stranded sites, with time in the role rather than a favor asked.

6. Open a wrongness log for cases where the assistant was confident and wrong. Turns private burns into shared knowledge.

7. Senior people ask basic questions in public, weekly, in writing.

8. Change the question managers ask from "did you finish it" to "what did you get stuck on".

9. Pull the existing data. Tickets, interruptions and regional spend are sitting there already.

Five of those nine, items 2, 3, 4, 7 and 8, are decisions rather than projects, which means they can be made in an afternoon by somebody who already has the authority to make them.

What we deliberately do not do fast

We do not take the regional training budgets. That $410,000 is the most obvious saving in the case and it is the one that would cost us the 5 site directors who decide whether this reaches their people.

They buy locally because waiting for a central answer costs them more. They stop when something arrives faster than their own purchasing does, and not before.

We do not sign a vendor inside 90 days. A response window is 40 days and reference calls run longer. A plan that ends in a signature tells anyone who has bought software that we have not.

What to change that is not training

8 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Two kinds of number appear below. Figures about Halden Systems and its staff come from data/survey.yaml and data/scenario.yaml, and are invented for a fictional company. Figures credited to DORA, Stack Overflow, McKinsey or PwC are real, were read on 2026-09-07, and are recorded in data/literature.yaml. They are never mixed without being labeled.

Bottom line. 11 changes worth making that are not training. Most cost nothing, and the cheapest are the ones that decide whether any training lands at all.

10 recommendations. None of them is a course. Most cost nothing, and the cheap ones are the ones that move the numbers.

The reasoning is the same each time. People are behaving sensibly given what the company rewards and what it has told them. Change those and the behavior follows. Leave them and no amount of good material will help.

The four that matter most

1. Make a promise about roles that can be checked

We told people nobody is losing their job. Under a quarter believe we have been straight with them.

The research on job worry is blunt about why: a reassurance you cannot check reads as a reason to worry. It raises suspicion rather than settling it.

Replace it with something falsifiable. A scope, a date, and a commitment to give notice if it changes. "No role will be cut as a direct result of adopting the assistant before June, and if that changes you hear it from us 90 days ahead."

Half the staff think this tool may cut their jobs. Two in five think that getting good at it proves they can be replaced. Until that is answered, we are asking people to build the case against themselves.

2. Cancel something

Two thirds report more simultaneous changes than they can absorb. Three quarters have no learning time that is not taken from delivery.

Asking for hours that do not exist gets ignored by people acting sensibly, and then gets reported as a motivation problem.

Remove one competing initiative. Nothing says this matters like taking something away to make room for it. It costs a decision and no money.

3. Stop reporting completion

78 percent can follow the steps. 31 percent can say what the steps do.

While the dashboard shows 78, the organization believes the problem is solved. The number is not wrong. It is measuring the wrong thing, and its existence is the obstacle.

Retire it. Report work product instead: pages corrected, changes merged, questions answered.

4. Put helping into promotion, not into badges

19 percent feel their effort to learn is noticed by anyone who matters. It is the lowest number in the survey.

61 percent would answer colleagues' questions if that were visible and credited. Three times as many.

That is the cheapest capacity in the whole program, and it is unlocked by recognition rather than by hiring.

One warning from the research. Rewards tied to finishing something reduce the motivation people already had, and the effect lasts after the reward stops. Do not pay for completion. Credit the contribution, in the system where credit actually counts, which is promotion.

The other seven

5. Have senior people ask basic questions in public

Half of staff have avoided asking a question they needed answered, because of how it would look. That is worse among people with long service.

Asking is learned from watching. If the most senior person at a site asks something basic in writing every week, the cost of asking drops for everyone below them. It costs nothing.

6. Keep a wrongness log

57 percent have had the assistant give them an answer that was wrong and sounded certain. Two thirds of developers surveyed elsewhere report the same thing.

Right now each of those is a private event that teaches one person to stop using the tool.

Collect them in one open page. It turns individual burns into shared knowledge, and it teaches the one skill nobody has taught: telling which answers need checking. 22 percent can do that today.

7. Write it down before you decide it

GitLab runs a public handbook on one rule: if it is not written down, it is not real. A change is documented before it is announced.

That is a norm, not a course. It makes writing load-bearing, which is the only thing that keeps documentation alive.

8. Look it up before you ask

The other half of the same practice. It sounds unfriendly and does the opposite: it means the written answer has to be good enough to find, so the effort moves to where it helps everyone.

Pair it with rule 5 or it will read as a rebuke.

9. Give the local experts a title and hours

Five of 9 sites have nobody who can answer a question during the working day. Those sites are 17 days slower to a first merged change.

Name a person at each, and give them a fifth of their week. Unpaid goodwill decays, and then the fix looks like it failed.

10. Write for the second language by default

People working in English as a second language report confidence 14 points lower, after allowing for which site they are at.

Prose pitched higher than it needs to be is a tax on them and on everyone else. This is a writing standard, applied to what already exists. It is not a program and it does not need a budget.

11. Celebrate the attempt in a channel anyone can post to

19 percent believe that effort to build these skills gets noticed. 61 percent would answer a colleague's question if it counted for something. Between those two numbers sits every person who tried, got somewhere, and told nobody.

Open one channel for it, and post in it yourself. What went in, what came out, what broke. A half-working script, a wrong turn that cost a day, a runbook somebody fixed. Name the person each time.

Three rules keep it safe enough to use. Anyone may post, including somebody 3 weeks in. A failed attempt is as welcome as a working one, and the senior people go first on those, because a channel where only wins appear teaches people to wait until they have one. Nothing posted there is ever quoted in a performance review, which is the fear that keeps the 51 percent quiet.

This is the cheapest of the 11 and it is the one that compounds. It gives the local experts of item 9 somewhere to be experts in public, it feeds the wrongness log of item 6, and it turns the contribution we want to promote in item 4 into something visible enough to promote.

What this costs

Six of the 11 are decisions. They can be made in an afternoon and cost nothing: the role promise, canceling an initiative, retiring the completion metric, senior people asking in public, the two GitLab norms.

Three are cheap and ongoing: the wrongness log, the writing standard, and the channel.

Two need real money: the local expert time, and changing promotion criteria, which needs the people team rather than a purchase.

Not one of them is training, and together they move more than the training will.

The content plan

9 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Bottom line. Halden Systems is not building 140 modules. We audited the 140 we have, 96 of them are being retired, and the library that replaces them is 79 pieces of which almost none is a course. Nothing runs longer than 15 minutes and most of it takes under 4.

Why the format changes and the volume falls

The evidence rules out doing more of what we did. 78 percent can follow our documented steps and 31 percent can say what those steps do, so the gap is not coverage. 29 percent rated our previous training useful, which is this function's own report card. 34 percent think more training would help, and they are right to doubt it.

A library of 140 modules is what produced those numbers. Replacing it with a larger one would be buying more of a metric that is already full.

The audit

Every one of the 140 was read against a single question: does somebody who works through this come out able to predict what the system will do. 96 could not pass it.

That leaves 44 surviving units. 35 new pieces are written to fill what the audit exposed, which is a library of 79.

The 19 duplicates are worth naming separately. They are the $410,000 of regional spend showing up as content: 9 sites each solving the same problem, and none of them wrong to.

What a piece of content is now

Nothing here is a course and nothing has a completion certificate. Each piece is read at the moment somebody needs it, and the measure is whether they then do the thing, not whether they reached the end.

Casual in register and exact in content. Written the way a colleague explains something at a desk, which is the register 61 percent of people said they would answer a question in.

One thing in the program is not in this table and matters more than any of it. The facilitated first change is 45 minutes, once, with a local expert, on a real task the person actually has. That is the intervention the Dublin pilot ran, and it is what moved days to a first merged change from 41 to 9.

The 79, by subject

Grouped by the system somebody is working in, because that is how the need arrives.

The last group is 6 pieces against a fear held by 64 percent of the population, and it is the smallest group that carries the most weight. Somebody who knows which actions are reversible stops needing permission to try.

What this costs to keep true

79 pieces against 4 engineering systems that ship continuously. At the rate those systems change, about 12 percent of the library is wrong at any moment, and a central team of 2.5 cannot chase 4 release trains.

The teams that own each system own the pieces about their system, the way they already carry release notes. The enablement function holds the standard and edits against it. That split is in the strategy and it is the reason the authoring line in the budget halves over 3 years.

What we are not making

No onboarding curriculum. A new joiner meets the same job aids as everybody else, plus the facilitated first change. A separate track for new people is a second library to keep true.

No video. Recordings teach the steps and skip the thinking, which is how the 47-point gap was made. Where motion genuinely helps, it is a 20-second clip inside a job aid rather than a recording somebody sits through.

No certificates of completion, except for the customer and partner certification, which is a different product for a different audience and is priced in the revenue case.

No content for the outer 1,850 in year 1. They have an assistant and no repository work, so the 11 pieces on judging its output are theirs and the rest are not. Writing for them before we have fixed the inner population would be starting a fifth rollout.

Project plan: closing the capability gap

10 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

For Halden Systems, across 9 sites.

Bottom line. 4 phases over 18 months, each ending at a gate with a named decider and the evidence they decide on. Phase 1 is already running and costs nothing. No phase begins before the gate ahead of it closes, and 2 of the 4 gates can stop the program.

The phases

Phase 1 is running. Dublin has already produced its result, and the survey is in the field, so the first gate is about reading evidence rather than waiting for it.

The gates, and what closes them

A gate is not a review meeting. Each one names a number, and the number is available before the meeting.

Gate 1, is the gap real. Closes on the survey showing a completion-to-understanding gap above 30 points, and on the baseline escalation rate being measurable from calendars and ticket queues rather than estimated. Opens if both hold. Stops the program if the gap is under 15 points, because at that size the cost of the program exceeds the cost of the problem.

Gate 2, does it work without its author. Closes on 2 sites running the unit with no involvement from the person who designed it, and on median days to a first merged change falling below 20 at both. Stops the program if either site needs the designer to run it, because a program that cannot be handed over is a consulting engagement with an internal invoice.

Gate 3, is the platform earning its cost. Closes on the vendor meeting the acceptance criteria in the statement of work. Does not stop the program: a failure here changes the vendor or reverts to building, and the capability work continues either way.

Gate 4, is this permanent. Closes on escalations per person per week falling below 1.2 across the inner population, sustained for 2 quarters. A failure here does not stop the program; it stops the expansion and returns the function to maintaining what works.

Dependencies, including the ones we do not control

The last row is the dependency most likely to be missed, because nothing breaks visibly when it slips. It is on the risk register for that reason.

Risks, with owners

The first risk is the one most plans omit. A program whose own plan cannot describe the condition under which it should not exist is asking for trust rather than a decision.

What runs in parallel, and what cannot

Content authoring, assessment design and the local-expert network all run from month 4 and do not wait for procurement. That is deliberate: the parts that depend on a vendor are the parts we should be least attached to.

Procurement cannot start before gate 1, because an evaluation matrix written before the survey would be weighted against a problem we had guessed at.

Scaling cannot start before gate 2. Running the unit at 9 sites when it has worked at 1 is how a program that worked becomes a program nobody trusts.

Statement of work: learning platform and content services

11 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Between Halden Systems and the selected supplier.

Bottom line. 4 deliverables, each with acceptance criteria a third party could apply without us in the room. Payment follows acceptance, never a date. What is out of scope is listed at the same length as what is in, because that is the half every dispute turns on.

Deliverables and acceptance criteria

Each test below is one a stranger could run. Where a test needs judgment, it says who judges it and against what.

D4 is the one vendors negotiate hardest and the one we hold. A platform that cannot report level 2 leaves us measuring completion again, which is the failure the program exists to correct.

Out of scope

Listed at length on purpose. A vendor who has read this and signed cannot later present any of it as a change order, and we cannot later expect it for free.

Writing any of the material. The vendor moves the 44 surviving units onto the platform and writes none of them. Our own people write it: a content lead who holds the standard, and the team that owns each engineering system for the pages about that system. The material is the capability, and buying it would leave us with a subscription instead of one.

Anything that touches our engineering systems. The platform reads who somebody is from our sign-in service and nothing else. It cannot reach a repository, join a build, or write to any engineering tool. That is a security line, not a preference.

Translation and localization. 4 continents and we are still delivering in English. That is a known gap, it is recorded in the strategy, and it is not being solved by this contract.

Change management and internal communications. The vendor does not talk to our staff. Adoption is our problem and buying it produces a rollout with no owner inside the company.

Any measure beyond the 4 levels. No scores for taking part, no leaderboards, and no completion dashboard sold to us as an outcome. We have too much of that number already.

Data migration out. Export is in scope. Anything the vendor would do to help a successor is not, and we have priced our own exit accordingly.

Payment against acceptance

No milestone is released on a date. A vendor who is late is late, and a vendor who is late and paid has been told that the schedule is ours to worry about.

The 30-day tail on D4 exists because reporting is the deliverable most likely to pass a demo and fail in use.

When acceptance fails

First failure. The vendor has 15 working days to remedy, at their cost. The clock on dependent milestones stops. This is expected at least once and is not a dispute.

Second failure on the same deliverable. We take a 15% reduction on that milestone and either accept the remedy or move the deliverable out of scope with a matching reduction. Which of those happens is our choice, not theirs.

Third failure, or any failure on D3. We end the contract for cause, they lose the retention, and they must hand our data back at once. D3 stands alone here because a security line that fails twice is not a quality problem.

If we cause the failure. Where acceptance fails because we did not supply access, data or people on time, the remedy period pauses and the vendor is entitled to a schedule extension of the same length. Stating this protects the relationship: a buyer who never admits a cause is a buyer vendors price defensively.

Governance after signature

We review the vendor monthly, against the scorecard in the budget document. Most of the money in a deal like this is lost after signing, not before it, and a statement of work that stops at acceptance has described the cheap part.

Budget model and vendor evaluation

12 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Bottom line. $2.1M over 3 years against a gap costing Halden Systems $6.1M a year. We recommend buying the platform and building the content, because the content is the capability and the platform is not. The evaluation weights below were fixed before any vendor was approached.

Total cost of ownership, 3 years

Internal time is in the model. A buy that removes a license cost and adds 0.5 of a person has moved the money rather than saved it, and a model that leaves internal effort out is the standard way that gets hidden.

The 2.5 people are a program lead, a content lead and a half-time analyst. They design the program, write the core pieces and hold the standard. They are sized against a library of 79 rather than the 140 we have, and the authoring line above falls by half over 3 years because the teams that own each engineering system take on the pages about their own system, the way they already carry release notes.

The zero row is deliberate and is the number a reviewer should push on. Local expert time is real and it is not new money: those people already answer these questions, at 760 engineer hours a week. The program moves that time rather than adding it, and if it does not, the model is wrong and gate 4 will show it.

Consolidating the $410,000 of duplicate regional spend covers most of year 2 and year 3 on its own. We have not netted it off above, because a saving counted inside the cost of the thing producing it is how a budget stops being checkable.

Make or buy, component by component

"Build against buy" is not one decision. The program has 7 pieces and we made the call separately on each, because the answer is different for a platform than it is for the material that runs on it.

The only line where the choice is close is the first, so that is the one costed below. Everything else is settled by what it is: the material encodes how our systems actually work, and a vendor writing it would teach a generic tool rather than ours.

The platform decision, with the arithmetic

Content and the enablement function cost the same either way, so they are not in this comparison. What differs is 2 lines.

We recommend buying. It is $564,500 cheaper over 3 years and live 7 months sooner, which is the opposite of what a build-against-buy comparison usually concludes.

It reads that way only because the engineering time is priced. Build looks cheaper the moment somebody treats those 1.5 people as free, and they are not free.

They are the same engineers absorbing 760 hours a week of interruptions, which is the problem this program exists to reduce. Treating them as free is the same error as a $0 row in a budget, and there is one of those above that we have asked you to push on.

Building also puts an internal team between every content change and the people who need it, which is the exact shape of the problem we are trying to fix.

Evaluation matrix

These weights were fixed on 2026-09-07, before any vendor was approached. This file's history shows it. Weights chosen after seeing submissions are a justification rather than an evaluation, and a procurement reader can tell the difference immediately.

License cost is weighted last on purpose. It is 28% of the model and the easiest thing to negotiate after selection, and weighting it heavily selects for the vendor best at discounting rather than the one best at level 2.

Scorecard after signature

Reviewed monthly by the Director of Enablement, reported quarterly to the COO. This is where the money is actually lost.

The last row has no tolerance because a regression there breaks a commitment we made to our own staff, and a target with a tolerance is a target that will be spent.

Scaling proposal

13 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

How the program reaches all 9 Halden Systems sites.

Bottom line. This has to run without the person who designed it. One unit is 1 local expert supporting 25 people for 6 weeks, at about $4,100 of time nobody is currently accounting for. 9 sites need 46 units over 18 months. If the unit cannot be run by somebody who did not design it, we stop, and the kill criteria below say when.

What one unit is

The unit is a person at a site, not a course in a catalog. That follows from the evidence: a 22-point confidence gap between sites with a local expert and sites without one is wider than the gap between job families, so proximity to help predicts capability better than role does.

The direct cost is genuinely zero and the time cost is genuinely $4,100. Reporting only the first is how programs get approved and then quietly starve.

Dublin ran this once already and produced median days to a first merged change of 9 against a company median of 41.

The train-the-trainer path

A unit is run by somebody who was in the previous unit. That is the mechanism, and it is why the program compounds rather than scaling linearly with the founder's calendar.

A site is self-sufficient when it has 2 people at stage 4. 4 sites have somebody at stage 1 today, which is where the 22-point gap comes from, and 5 have nobody at all.

The material a new expert needs is a runbook, a session outline and the assessment. All 3 exist already, which is what makes stage 3 a real handover rather than an aspiration.

What breaks at 10 times the size

Named specifically, because a caveat that says "scaling brings challenges" tells a reader nothing and costs whoever wrote it nothing.

The check-in does not scale and fails silently. At stage 3 the enablement function spends 30 minutes a week per new expert. At 46 concurrent units that is 23 hours a week against a function of 2.5 people. It breaks somewhere around 20 concurrent units, and the failure mode is not a crisis, it is check-ins quietly being skipped. Fix: stage 4 experts take the check-ins from unit 15 onward, which is why stage 4 exists.

Content goes stale faster than 2.5 people can revise it. 79 pieces against 4 engineering systems that ship continuously. At the current change rate, roughly 12% of the content is wrong at any moment. Fix: content ownership moves to the teams that own each system, with the enablement function holding the standard rather than the text.

Assessment integrity. At 25 people a facilitator knows whether somebody understood. At 1,150 they do not, and the assessment becomes the only signal at exactly the point where it starts being gamed. Fix: assessment against a real change in a real repository, which cannot be answered from a recording.

The 5 sites with nobody to ask stay last. Every scaling plan reaches the sites that already have an expert first, because those go faster, and the 22-point gap is at the other 5. Fix: the sequence is fixed in the project plan and starts at 2 of the 5, which costs us speed in year 1 on purpose.

Kill criteria

The conditions under which we stop. A scaling proposal with no such condition is a budget request wearing a plan's clothes.

The last row is the one that matters. A program that cannot describe the world in which it should not exist is asking for trust rather than a decision, and the person being asked can tell.

Stopping is not failure in 2 of these 5 cases. It is the finding.

Presentation standard and brand

14 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Bottom line. 9 slides, 16:9, one idea each. The ask is on slide 1 and the decision is on slide 9. Everything here is written so that somebody who was not in the room can build the deck and get the same result.

The brand

The mark

Halden Systems uses a wordmark with a single glyph, and no illustration.

The cut corner is the whole idea: a system with a piece taken out of it. Do not round it, fill it, animate it, or add a second one.

Color

5 values, and every pair below has been measured.

The last 4 exist because signal and slate were each used against two backgrounds and each cleared AA against only one. A palette of 5 that fails half the time it is used is a palette of fewer than 5. Each variant is the nearest color to its parent that passes.

Every ratio here was measured rather than estimated. The first four were written from memory, and each was wrong by a tenth or two. That is close enough to be believed and far enough to matter. Signal on paper was recorded as 3.4:1, which clears the 3:1 a large heading needs. The measured figure is 2.8:1, which does not.

The last row is the one that gets broken. Signal is a bar color on a light slide and a text color only on a dark one. It was broken in 4 places, on the 31 percent figure and on the total row of the cost table, and nothing caught it for a month. A darker orange, #B8481A, carries the same meaning at 4.9:1 and is what small signal text uses now.

Type

One family, 2 widths, 3 weights. A deck that needs a fourth weight needs fewer words.

Söhne is the intent and Inter is what ships. Söhne is licensed and Google Slides cannot load it, so the built deck uses Inter and Roboto Mono, which are close in width and have the same flat, unfussy shapes. A standard that names a face nobody can install is a standard that gets ignored quietly.

Nothing below 37px, which is 28pt. The old floor here was 22px, and it was set by looking at a deck on a laptop. A slide is not read, it is projected, and the number that matters is the one a person 40 feet back can resolve. 37px is 14pt against a 405pt reference slide, scaled to this canvas, and it is the floor slidekit check enforces by default.

The deck used to break the old floor in 23 places and the new one in 90. It no longer breaks either. Raising it cost one slide its layout: the value case put a heading and a full sentence in a 225px-wide column, which held at 21pt and collided at 32pt, so the column is wider now and the bars start further right. That is the usual price of a floor, and it is worth paying once.

Grid and safe area

1920x1080, 12 columns, 80px gutters, 120px outer margin. Title sits on the baseline 200px from the top and never moves between slides, because a heading that jumps is the thing the eye tracks instead of the content.

The same canvas in points is 1440x810. A pixel here is three quarters of a point. A browser pixel is a 96th of an inch and a point is a 72nd, so the two units differ by exactly that much. The Slides API speaks only in points and reports this deck as 1440x810pt. A standard written in pixels alone sends anybody working against that API to the wrong numbers, and it did.

Nothing that carries meaning goes within 120px of any edge. That is wider than broadcast safe area and exists for the room, not the camera: the bottom of a screen is behind somebody's head.

The wordmark is the one exception and it is deliberate. It sits 24px from the bottom left corner, carries nothing a reader has to recover, and belongs beside the composition rather than in it. Every other element holds the margin.

What we do not do

No stock photography of people at laptops. No gradient meshes. No drop shadows. No icon sets where a lightbulb means an idea. No logos of vendors we have not chosen. No build animations, because a build tells the room you are about to say something they cannot yet read, and they stop listening and wait.

How these slides are built

The deck is 9 slides for a 30-minute meeting: about 12 minutes of talking, and the rest is theirs. That ratio is the design.

One idea per slide, and the headline is the idea. The headline is a sentence with a verb, not a label. "78 percent can follow the steps. 31 percent can say what they do" is a headline. "Survey results" is a filing category.

The slide carries the evidence and the speaker carries the argument. Nothing on a slide is read aloud. If a line is only there to be read out, it belongs in the note.

One visual per slide, and it is the claim. A chart that shows the gap is the claim. A chart that shows everything we measured is a chart the room reads while you talk.

Progressive disclosure across slides, never within one. Each slide assumes the one before it and adds a single move. Adults following an argument hold about 4 new things; 9 slides at 1 each is inside that, and 9 slides at 3 each is not.

Repeat the sticky sentence 3 times. They can follow the steps, they cannot say what the steps do. Slide 2 states it, slide 6 uses it, slide 9 closes on it. A sentence heard 3 times in 12 minutes is the sentence quoted in the next meeting you are not in.

Relevance before evidence. An executive audience gives attention to a problem they own before they give it to a number. Every slide answers "why is this mine" before it answers "how big".

The ask is first and last. Primacy and recency are the only 2 positions anybody keeps. Everything in between is support.

Two things the built deck needed and this standard had not said

Both were found by generating the deck and comparing it against these pages, which is the only way a specification is tested.

A disclaimer slide, before the ask. Every artifact in this set carries a line saying the company is invented, and a deck leaves that set the moment somebody exports it. It is slide 0: the mark, and one sentence reading "This is not a real presentation. It is an example from philhwagner.com." The 9 slides below are unchanged and the deck is 10.

A title. A deck inherits a filename, and a filename is what a recipient sees in a share sheet, a tab and a meeting invitation. It is "Funding Proposal: Closing the $6.1M Gap": the subject and the number, so the deck is findable months later by somebody who remembers neither the sender nor the date.

One deviation was right and is now the rule. The 2 figures on the ask slide render in paper rather than signal. 2 numbers in the accent color compete for the same emphasis and neither wins, so the accent is spent on 1 thing per slide as the color section says, and on that slide the 1 thing is the rule between them.

The 9 slides

Each entry gives the headline, the one visual, what is on the slide, what the speaker adds, and what is deliberately absent.

Slide 1. The ask

Headline: We are asking for $2.1M over 3 years to close a gap costing $6.1M a year.

Visual: None. Type only, centered, on ink.

On the slide: The 2 figures at 128px, signal on ink, side by side with a thin slate rule between them. Below, in 28px paper: "The decision today: fund it this quarter, or tell us to keep absorbing the cost."

The speaker adds: That procurement is already moving and no contract is signed. Then stops talking. The silence after the ask is doing work.

Absent: Agenda slide. An agenda tells a room the ask is coming later and teaches them to wait for it.

Slide 2. What is broken

Headline: They can follow the steps. They cannot say what the steps do.

Visual: 2 horizontal bars, 78 and 31, wash and signal, on paper. No axis, no gridlines, no legend. The 2 numbers sit at the end of their bars in mono.

On the slide: One line beneath: "4 years of moving work into engineering systems. Every move run as a tooling rollout."

The speaker adds: Our dashboard reports the 78 and calls it success. That sentence is the first time the room hears that we have been measuring the wrong thing.

Absent: The other 14 survey items. They are appendix A1.

Slide 3. What it costs to leave alone

Headline: $6.1M a year, and every figure is already in a system we own.

Visual: A 4-row table, mono, right-aligned figures, one signal row for the total.

On the slide: 760 engineer hours a week. $145 fully loaded. $5.7M a year. $410,000 duplicate regional spend.

The speaker adds: None of this needs a new measurement. The interruptions are in calendars, the spend is in 9 regional budgets, and the tickets are in a queue.

Absent: Any projection. Every number is the year we just had.

Slide 4. Where the value is

Headline: Revenue is the biggest number here and the weakest evidence.

Visual: 3 stacked blocks, largest at the top, wash for revenue and signal for the 2 beneath. Size is proportional to the claim, which is the point.

On the slide: Each leg carries its own figure, and the figures are named here because revenue has no dollar amount and asking for one produces the overclaim the next slide refuses.

Revenue's is a quantity rather than a currency amount, on purpose. A dollar figure would need an attribution argument we have already said we cannot win, and putting one on a slide is exactly how a learning function gets caught.

The speaker adds: The ordering, out loud, before anybody spots it.

Absent: A total. Adding these together would be the overclaim this slide exists to refuse.

Slide 5. The number we will not defend

Headline: Every learning function that has overclaimed revenue has been caught.

Visual: None. A single sentence on ink, 54px, with the rest of the slide empty.

On the slide: Nothing else. The empty slide is the emphasis.

The speaker adds: We lead on revenue because it is the largest, and we rest the case on the 2 below it. We would rather say so first.

Absent: Any hedge. This slide is a concession, and a concession with a caveat is a defense.

Slide 6. Why more training will not fix it

Headline: 4 findings, and each one rules something out.

Visual: 4 lines of text, each with a signal rule to its left. No icons.

On the slide: One program for everyone degrades the experts in it. Proximity beats training. Recordings skip the thinking. Paying for completion buys completions, and completion is at 78 percent.

The speaker adds: So the incentive is contribution, not completion.

Absent: Citations. They are appendix A5, and reading a citation aloud is how a room learns you are unsure.

Slide 7. AI is a chapter, not a program

Headline: 22 percent can tell which answers need checking.

Visual: 3 bars, 71 / 38 / 22, descending, with only the last in signal.

On the slide: McKinsey's 88 and 6, in mono, small, beneath the bars.

The speaker adds: The descent is the story. Adoption is fine and judgment is not, and nobody measured judgment before the rollout.

Absent: The word "AI" in the headline. The subject is the capability.

Slide 8. How you will know it worked

Headline: And how you will know it failed.

Visual: One real table. A header and 4 level rows, with a reachable column and a not reachable one. The rows are fixed and so are their answers, because this is the slide most likely to disagree with the strategy and a reader who spots that has stopped believing both.

It was 21 shapes arranged to look like a table until 2026-09-08: 12 text boxes and 9 rectangles drawn as rules. That is why level 04 was missing for a month. Adding a row meant moving every shape below it by hand, so nobody did, and the slide quietly contradicted the paragraph under it. A table takes a row.

The slide carries the short form of that column, a yes or a dash, with revenue in signal on the last row. The sentences above are what the speaker says, not what the room reads.

Level 4 is never dropped for space. It is the level the revenue argument rests on, and a deck that omits it has removed the concession that makes the rest credible.

On the slide: The 2 failure conditions in signal beneath the table: escalations do not fall within 2 quarters, or completion rises while understanding does not.

The speaker adds: Level 4 revenue is honestly not reachable, which is why it is ordered where it is.

Absent: A target date for each level. Dates here invite a schedule conversation instead of a funding one.

Slide 9. The decision

Headline: Fund $2.1M over 3 years, this quarter.

Visual: None. Type on ink, matching slide 1 so the room recognizes it.

On the slide: What the money buys, in 3 lines: a platform, 2.5 people, and content written here. What you get in 90 days. What you do not get, which is a signed vendor contract.

The speaker adds: If it cannot be run by somebody who did not design it, we will tell you and stop it. The kill criteria are ours to enforce.

Absent: A thank-you slide. The last thing on the screen during the discussion should be the decision.

Where the built deck is

The deck produced from this standard is published on Google Slides, and the executive readout links to it. It is linked rather than embedded, because this site promises that nothing third-party loads on it and an embed would break that promise on every page carrying one.

Two things would need fixing before the embed code Google hands out is used anywhere. It is a fixed 960 by 569, which overflows a phone and does not scale, so it needs a wrapper holding a 16:9 ratio instead. It also carries no title, so a screen reader announces it as "frame" and a reader has no way to learn what it holds before entering it.

The appendix

6 slides, never presented, each reachable by name when asked. Survey instrument and response rates. The site confidence gap. The 3-year total cost of ownership and build against buy. The evaluation matrix with its weights. The literature review and the claim we refuse to cite. What we are deliberately not solving.

An appendix that is walked through is a second deck. Its only job is to make a hard question end in an answer rather than in a follow-up meeting.

Executive readout: the capability gap

15 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Bottom line. $2.1M over three years, against a capability gap costing $6.1M a year. The decision asked for today is funding, this quarter.

Two kinds of number appear below. Figures about Halden Systems are invented, and come from data/scenario.yaml and data/survey.yaml. Figures credited to DORA, Stack Overflow, McKinsey or PwC are real, were read on 2026-09-07, and are recorded in data/literature.yaml.

Open the built deck, built from the specification in the presentation standard. It opens in a new place rather than on this page, and that is a decision rather than an oversight. This site promises that nothing third-party loads on it, and an embedded deck would make that promise false on the page carrying it. A link costs one click and costs the promise nothing.

9 slides for the COO, around day 65. The strategy document is the argument; this is the version that survives a thirty-minute meeting with a finance review after it. Everything that is not a decision is in the appendix, and the appendix is a separate file on purpose. A deck that contains the strategy document is a strategy document nobody read.

What follows is the script behind those slides: what is on each one, what the speaker adds, and what is deliberately absent.

Slide 1. The ask

We are asking for $2.1M over three years to close a capability gap that costs us $6.1M a year.

The decision today: fund it this quarter, or tell us to keep absorbing the cost.

Procurement is already in flight. No vendor contract is signed, and none will be inside these 90 days.

Speaker note: the amount and the decision go on the first slide because an executive who has to wait 6 slides to learn what is being asked spends those 6 slides guessing.

Slide 2. What is actually broken

78 percent can follow the steps. 31 percent can say what the steps do.

Four years ago we moved most non-engineering work into engineering systems. Every move was run as a tooling rollout. The tooling arrived and the capability did not.

Our dashboard reports the 78 and calls it success.

Slide 3. What it costs to leave alone

Every figure is already in a calendar, a budget or a queue. None of it needs a new measurement, and none of it is a projection.

Slide 4. Where the value is, in order of size

Revenue. Six solution-engineer days per enterprise customer, 240 customers a year. 95 partner implementations that need certified partner staff.

Cost. $5.7M in engineer time. $410,000 in duplicate spend.

Efficiency. 41 median days to a first merged change, and 58 at the sites with nobody to ask. The pilot runs at nine.

Speaker note: revenue opens the room because it is the largest number. Say the next line out loud, because somebody in the finance review will say it first if we do not.

Slide 5. The number we will not defend

Revenue attribution for an internal program is the weakest evidence we have.

We lead on it because it is the largest, and we rest the case on cost and efficiency because those are the ones a skeptic can check without our help.

Every learning function that has overclaimed revenue has been caught doing it. We would rather be the one that said so first.

Slide 6. Why more training will not fix it

Four findings, each ruling something out.

• One program for everyone measurably degrades the experts in it.
• Proximity to help predicts capability better than role does. Our own gap between sites with and without a local expert is 22 points, wider than the gap between job families.
• Recordings teach the steps and skip the thinking, which is exactly the population we have.
• Paying people to finish courses buys finished courses. We are at 78 percent completion already.

So the incentive is built on contribution, not completion.

Slide 7. AI is a chapter, not a second program

71 percent have used the assistant. 38 percent would sign their name to its output. 22 percent can tell which answers need checking.

That last figure is the skill, and it is the one nobody measured before rollout.

McKinsey: 88 percent of organizations have adopted AI, 6 percent capture real value, and the gap did not move between 2025 and 2026.

A strategy about a tool expires with the tool. This one absorbs the next arrival instead of being rewritten for it.

Slide 8. How you will know it worked

And how you will know it failed. Escalations do not fall within two quarters of a site going live. Failure also looks like completion rising while understanding does not, which means we bought more of the metric that is already full.

Slide 9. The decision

Fund $2.1M over three years, this quarter.

What the money buys. A platform, and 2.5 people. The platform is bought because we have no advantage in that market. The content is written here, because the content is the capability: a content lead holds the standard, and the team that owns each engineering system owns the pages about it. The 9 local experts run the program and do not write it.

What you get in 90 days: the funding decision made, procurement in flight, the pilot running, and a named owner on the promise that the assistant will not cost anybody their job.

What you do not get: a signed vendor contract. That is deliberate.

If it cannot be run by somebody who did not design it, we will tell you and stop it. The kill criteria are in the scaling proposal, and they are ours rather than yours to enforce.

Appendix

Kept separate so the deck stays 9 slides. Reach for these only if asked.

• A1. Survey instrument, sample and response rates, including the items inconvenient for the program. data/survey.yaml.
• A2. The 22-point site confidence gap, by site.
• A3. Three-year total cost of ownership, and the build-against-buy analysis.
• A4. The evaluation matrix, with weights fixed before any vendor was named.
• A5. The literature review, and the one claim we refuse to cite.
• A6. What we are deliberately not solving, and why each was cut.

What this set cost to produce

16 of 16 · read this one on its own page

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

Bottom line. What the set represents, and what assistance changed. About 168 working hours unassisted and 69 assisted, a factor of 2.4. The calendar barely moves: 133 elapsed days against 100, a factor of 1.3, because most of the calendar is waiting for other people.

The set is the 11 documents describing Halden Systems, listed in the table below.

Every figure below is an estimate, not a measurement. An estimate presented as a measurement is the same failure as an unverified statistic.

The headline, with the qualifier attached

Those two rows describe the same work, and the gap between them is the point.

Per artifact, which is where the pattern is visible:

Assistance compresses the hours somebody spends. It barely moves the calendar, because most of the calendar is waiting: 3 weeks of a survey in the field, a vendor response window, references who answer when they answer.

Reporting the first number as delivery speed is how this claim is usually overstated. Anyone who has run a procurement will catch it in the room.

The honest version is more useful anyway. It says where to put the assistance and where not to bother.

Where the compression is, and where it is not

The survey is the clearest case in the set: 45 percent fewer working hours and 11 percent less clock time. The instrument can be drafted in an afternoon. The 3 weeks in the field do not move, and the pilot before it does not move either.

The budget and vendor work has the longest elapsed time of anything here and is the least affected. 45 days becomes forty. The response window is the response window.

The literature review compresses hardest on the finding-and-summarizing and least on the part that matters. Assistance is good at locating sources and stating what they claim. Deciding which are load-bearing, and which are a vendor citing its own survey back to itself, requires having read them. That reading is most of the 8 hours, and skipping it is how unverified figures enter a document and stay there for a decade.

What did not compress at all

Every artifact in data/effort.yaml carries a line naming the part assistance did not touch, and they have a shape in common. Each one is a decision rather than a draft.

Knowing that revenue is the largest number in the case and the weakest evidence in it. Choosing to say so on the slide, rather than hoping nobody asks.

Deciding what each persona rules out. That is the difference between six plausible people and an instrument that refutes a bad proposal.

Writing the out-of-scope section of a contract, which is specific to what this buyer will assume. Writing kill criteria for your own program. Cutting the deck.

That distinction is the argument this portfolio is making about AI, and it is the same argument the program in the scenario makes to 3,000 people: assistance compresses drafting and synthesis, and does not compress deciding. A leader who cannot tell those apart will either refuse the tool or over-trust it, and both failures are visible in the survey data.

Why this belongs in a summary a recruiter reads

Two reasons, and the second is the real one.

It sets the scale. A reader can tell in one line whether they are looking at a weekend's work or a month's, which is otherwise guessed from polish.

It also demonstrates the competence being hired for. A director of learning will be asked what these tools do to their function's capacity, by an executive who has heard a tenfold claim and does not believe it. The answer here is 2.4 on hours, 1.3 on the calendar, with the boundary named. That answer is worth more in the room than a larger number would be, because it can survive the follow-up question.