89 lines
10 KiB
Plaintext
89 lines
10 KiB
Plaintext
---
|
||
id: skills-adoption
|
||
title: Skills adoption
|
||
description: Workflow-led coaching, client choice, feedback, manual path.
|
||
hide_table_of_contents: true
|
||
---
|
||
|
||
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||
|
||
<div className="strategy-content">
|
||
|
||
**TO-BE · Target operating model — not installed controls or company results.**
|
||
|
||
Optional reference when skills are the chosen intervention. The [6 Months Roadmap](./six-months-roadmap.mdx) starts with willing partners and current AI-assisted practice; department names below are proposed functions to agree, not appointments. The assembled [EXP-01 packet](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example) shows first-revision recovery, total effort, an inconclusive bounded extension and a stop decision.
|
||
|
||
## When should a pilot become a team workflow?
|
||
|
||
Expand only when a bounded canary produces independently accepted work and useful feedback. Teach people to verify artifacts and recover without AI, not merely invoke a skill. Compare **Workflow effectiveness** with the current-workflow baseline; observe **Skills effectiveness & health** separately as skills enter use. More adoption does not prove improved work, and before/after trends alone are not causal evidence.
|
||
|
||
<ArchifyDiagram name="strategy-adoption" title="Choose a workflow, coach a canary, verify outcomes and improve before expansion" story />
|
||
|
||
- **Team-led:** the departmental owner defines the outcome; People & Administration Squad supports learning.
|
||
- **Choice within support:** qualify the client path instead of promising identical agent behavior.
|
||
- **No adoption quotas:** retain a manual path; rejected suggestions and non-use are feedback, not poor performance.
|
||
|
||
## Run one bounded comparison, then make a decision
|
||
|
||
Bring the [Baseline](./baseline.mdx) comparison record, [Quality](./skills-quality.mdx) qualification report and [Governance](./skills-governance.mdx) pilot authorization—not merely an installed bundle. In the **illustrative Delivery workflow**, the developer and AI Agent prepare a bounded patch and regression tests on the qualified client; an independent reviewer accepts or rejects the exact work. Existing release controls still apply. Record failed and abandoned work as well as accepted changes, and use the manual path if the skill adds risk or effort.
|
||
|
||
At the agreed review point, the designated Product Engineering workflow owner considers the comparable outcomes and feedback, Quality Engineering's independent acceptance/quality evidence and any boundary or support findings from Architecture & Security and Platform & IT. These are proposed responsibilities; appoint actual people and agree criteria before the pilot.
|
||
|
||
- **Retain:** useful within the tested scope and supported controls; the designated owning approver records exact-revision approval after independent review and required boundary/support checks, then hands that revision and evidence to [Maintenance](./skills-maintenance.mdx). The pilot decision alone is not general approval.
|
||
- **Improve:** return failure cases and friction to the author and [Quality](./skills-quality.mdx); a changed candidate needs new evidence.
|
||
- **Expand:** propose a new bounded workflow/cohort, revisit [Baseline](./baseline.mdx) and obtain the relevant approval—not automatic organization-wide rollout.
|
||
- **Stop or hold:** unsafe behavior triggers containment; insufficient evidence means no benefit claim and no justified expansion. Preserve current practice or a safe manual path. Any extension needs a new explicit expiry, capacity/spend cap and attainable evidence question; otherwise narrow or stop, never continue indefinitely.
|
||
|
||
The output is a decision record with evidence, scope and remaining uncertainties. Qualification fitness and live outcomes inform it separately; apparent before/after improvement does not establish causality.
|
||
|
||
<details>
|
||
<summary>Onboarding responsibilities, coaching and feedback safeguards</summary>
|
||
|
||
**TO-BE · Target operating model.** This bounded comparison belongs to the [Stage 01 journey](./stage-01-skills-adoption.mdx); these pages do not describe installed controls or measured company results.
|
||
|
||
Start with a small set of useful workflows chosen by the existing teams. Product Management and the departmental owner identify the outcome; Data & AI helps turn it into a skill; Quality Engineering establishes acceptance; Platform & IT qualifies the client path; Architecture & Security clears the data boundary. People & Administration Squad coordinates learning and accessible feedback.
|
||
|
||
Onboarding should teach people to select the right skill, inspect the actual artifact, recognize untrusted instructions, use the exception and incident routes and recover without AI. A practice task ends with verified work and an explanation of limits, not just a logged invocation. Demonstrate the same portable skill on the supported local clients without promising identical agent behavior.
|
||
|
||
Use short worked examples, peer pairing, office hours and a clear catalog search path. Gather reasons for non-use and rejected suggestions without penalizing them. Preserve a manual path. Training feedback improves the skill only through review, not automatic self-modification of the approved catalog. Departmental workflow outcomes matter more than uniform uptake.
|
||
|
||
No developer rankings, individual productivity scores, minimum invocation quotas or inference of effort from token counts are part of this strategy. Report cohort-level evidence with privacy protection and balanced quality, flow, risk and cost. A participant may reasonably stop using a skill that creates more work or uncertainty.
|
||
|
||
</details>
|
||
|
||
<details>
|
||
<summary>Pilot evidence, illustrative report and expansion</summary>
|
||
|
||
## Apply the selected measures in the pilot
|
||
|
||
Use the relevant subset agreed in [Baseline](./baseline.mdx), not every entry in the [Measurement registry](./measurement/index.mdx). Keep its eligibility, independent acceptance and follow-up rules. Capture inputs as work happens; record exact skill revision and client configuration, leaving missing versions unknown. Do not reconstruct review effort from elapsed PR time.
|
||
|
||
The following questions are candidates, not a mandatory pilot bundle. Proposed owners and cadences need agreement before collection:
|
||
|
||
| If this question is selected | Evidence and pilot review |
|
||
| --- | --- |
|
||
| Are tasks reaching acceptance? | Join tracker starts to independent acceptance, failure and abandonment. Apply [validated task success](./measurement/validated-task-success.mdx) to matured starts; retain failed, abandoned and unresolved tasks in the denominator and show unknown outcomes and coverage. Proposed weekly reviewer: Quality Engineering. |
|
||
| Is quality holding up? | Link accepted changes to confirmed defects, severity and follow-up dates; retain PR/CI evidence. Apply [escaped quality](./measurement/changes-with-escaped-quality-issues.mdx) after follow-up, counting each affected change once, alongside severe incidents. Missing links are not clean work. Proposed monthly reviewer: Quality Engineering. |
|
||
| What does an accepted outcome cost? | Reconcile invoices and usage, sampled review/rework minutes at approved rates, unsuccessful attempts and allocated licenses/tooling. Apply [cost per accepted outcome](./measurement/cost-per-accepted-outcome.mdx) to the same matured start cohort; distinguish effort from waiting. Missing buckets make the estimate partial. Proposed monthly reviewer: Finance & Accounting; restate late invoices. |
|
||
| Can people confidently verify the work? | Use the anonymous 1–5 survey for confidence, manageable workload and usefulness as separate items. Report the [confidence measure](./measurement/verification-confidence-and-cognitive-load.mdx), distribution and response rate; protect small groups. Proposed reviewer after each pilot cycle: People & Administration. This is enablement evidence, not proven saved time. |
|
||
|
||
### What a pilot report looks like
|
||
|
||
**Illustrative arithmetic, not company results or targets.** The bundled synthetic fixture shows four matured starts: one accepted, one failed, one abandoned and one unresolved. Confirmed success is **1 / 4 × 100 = 25%**, with **75%** known-outcome coverage. A newer start has not finished its observation period and is shown separately.
|
||
|
||
Recorded compute spend is **EUR 60 / 1 = EUR 60** per accepted outcome—a **partial estimate** because licenses, tooling, review and rework are missing. Five survey responses total 20 points: **20 / 5 = 4** out of 5; response rate is **5 / 10 × 100 = 50%**. Reconcile the unknown task and missing costs instead of claiming a skills benefit. Reproduce it with `node scripts/ai-kpi.mjs`; [fixture and limits](./measurement/synthetic-example.mdx).
|
||
|
||
### Revisit selection as adoption expands
|
||
|
||
Selection precision/recall qualify named skill versions against labeled cases; they do not measure real-workflow acceptance. Keep any skill/version evaluation separate from the live task-success cohort. Skill-specific measures with no applicable population are N/A, not zero; missing evidence for an existing population remains unknown.
|
||
|
||
Keep relevant outcome evidence comparable; add reach measures only if they answer the expanded workflow's questions. For [supported bundle coverage](./measurement/supported-bundle-coverage.mdx), freeze the expected active installation inventory and compare observed bundle/adapter revisions to support and revocation records. Offline or stale entries stay in the denominator. Platform & IT is the proposed weekly and at-revocation reviewer.
|
||
|
||
For [approved-workflow adoption](./measurement/approved-workflow-adoption.mdx), freeze the lawfully enrolled participant cohort and distinguish qualified-adapter observations from labeled declarations. Report the observed lower bound with source coverage: missing use is unknown; installation and loading are not use. Data & AI is the proposed monthly reviewer. No invocation quotas or employee rankings. Return to Baseline for a new workflow rather than treating rollout as company-wide metric collection.
|
||
|
||
</details>
|
||
|
||
**Next:** [Maintain skills using the agreed evidence →](./skills-maintenance.mdx)
|
||
|
||
</div>
|