jarvis-at-skic
abe00994a1
Build and publish Eldorado documentation / build (pull_request) Successful in 46s
72 lines
6.8 KiB
Plaintext
72 lines
6.8 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.**
|
||
|
||
## 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.
|
||
|
||
<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.
|
||
|
||
<details>
|
||
<summary>Onboarding responsibilities, coaching and feedback safeguards</summary>
|
||
|
||
**TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.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
|
||
|
||
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>
|