jarvis-at-skic
1a2d16bc91
Build and publish Eldorado documentation / build (pull_request) Successful in 1m30s
86 lines
8.8 KiB
Plaintext
86 lines
8.8 KiB
Plaintext
---
|
||
id: roadmap
|
||
title: Roadmap
|
||
description: Proposed month-by-month work, capacity, dependencies and decisions for a solo AI Architect.
|
||
hide_table_of_contents: true
|
||
---
|
||
|
||
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||
|
||
<div className="strategy-content">
|
||
|
||
## Six months, two investment decisions
|
||
|
||
<ArchifyDiagram name="strategy-roadmap" title="Proposed months 1–4: learn and test; months 5–6: retain or stop, then hand over" story />
|
||
|
||
**Humans direct, guide and review throughout.** This is a proposed plan, not an agreed schedule or budget. The first decision funds one bounded experiment; the second retains, changes or stops it before any transfer. The [six-month strategy](./target-operating-model.mdx) starts with existing uneven AI-assisted practice, not zero adoption. A Target operating model is only a conditional long-term reference.
|
||
|
||
**Month 1 — Discover and earn trust.** I agree CTO expectations, access and a monthly decision meeting; meet team leads, pair with developers and reviewers across contrasting workflows, and trace recent changes. Output: current-work map, AI/tool/data constraints, evidence gaps and ranked bottlenecks. Dependency: willing access to real work. Decision: select a problem, or continue targeted discovery rather than prescribe skills.
|
||
|
||
**Month 2 — Agree one experiment.** I recruit one willing team and an independent reviewer, observe a prospective baseline and compare context, coaching, test/review feedback, deterministic automation and skills. Output: the [experiment packet](./stage-01-skills-adoption.mdx), effort cap, acceptance rules and stop date. Dependency: team lead agrees contributions; actual risk/approval owners clear the boundary. No partner, reliable checks or lawful evidence means no live pilot.
|
||
|
||
**Month 3 — Work beside the team.** I build and qualify the smallest intervention, pair on bounded changes and collect outcomes plus burden. Output: reproducible examples, failure cases and weekly evidence review. Dependency: independent qualification and explicit pilot permission, not tool installation. Stop unsafe work immediately; fix friction before asking others to adopt.
|
||
|
||
**Month 4 — Compare and choose.** I reconcile matured tasks, defects, review effort, costs and concurrent changes with the reviewer. Output: retain/change/hold/stop recommendation to the workflow owner and CTO. Dependency: comparable matured tasks and reconciled sources. Low task supply or missing follow-up means inconclusive, not success. Only an approved time-and-budget-bounded extension may continue; otherwise narrow or stop.
|
||
|
||
**Month 5 — Transfer selectively.** If value and burden are acceptable, I pair with a voluntary champion and backup and test a second willing team's fit. Output: a team-owned example, support/recovery instructions and a new-scope baseline. Dependency: team capacity and funded upkeep. If absent, improve the first workflow or retire it; no organization-wide training mandate.
|
||
|
||
**Month 6 — Handover and CTO evidence review.** I verify that the team can operate without daily architect help and present outcomes, limits, costs and stopped work. Output: an owned retained workflow or documented stop, plus a prioritized next-quarter proposal. Dependency: independent evidence and actual owner acceptance. The CTO decides the next investment, not an automatic autonomy phase.
|
||
|
||
## Delivery first, replication only if earned
|
||
|
||
<ArchifyDiagram name="strategy-roadmap-adoption" title="One willing Delivery team → a separately agreed transfer, or stay and improve" story />
|
||
|
||
**Delivery keeps improving** whether transfer happens or not. The order of any other workflows is not yet decided. I bring concrete examples to skeptical teams, ask what creates extra work, and accept non-participation. A skeptic can help judge a demo without joining a pilot. If priorities conflict, I ask the CTO for a trade-off, not a compliance escalation.
|
||
|
||
## Keep one learning loop
|
||
|
||
<ArchifyDiagram name="strategy-roadmap-loop" title="Understand current AI work → baseline → choose intervention → bounded pilot → evidence → retain, change or stop" story />
|
||
|
||
Repeat the learning loop, not a predetermined tool rollout. If skills are selected, their topology defines what skills exist, how they relate, when they are used and how they work together. Simpler context, coaching or deterministic fixes do not require a skills catalog.
|
||
|
||
## Solo capacity and influence
|
||
|
||
Proposed weekly allocation during pilots: two days hands-on pairing/building, one day evaluation/evidence, one day coaching and relationships, and one day sponsor decisions, support and contingency. One active live pilot at a time; a second team starts only after the first is supportable. This is a capacity envelope, not known company availability.
|
||
|
||
Ask a partner lead to agree a small pairing slot and independent review time explicitly; record actual effort, not assumed free team labor. Agree a short weekly team check-in and monthly CTO review of evidence, blocked dependencies, spend and the next choice. Seek specialist security/privacy advice only where the selected boundary requires it; preserve independent checks without appointing a committee.
|
||
|
||
Trace codebase structure and existing principles → system-logic source → tests → builds and packaging → deployments. Repair critical acceptance/data gaps before live use. Publish short reusable examples and offer office hours; don't become a permanent help desk for more than ten teams. Escalate support demand as an investment choice, never hide it in apparent savings.
|
||
|
||
Follow the **illustrative Delivery workflow** in [the experiment packet](./stage-01-skills-adoption.mdx). Its diagram and worked decision keep benefit, burden and safety connected. [Measurement](./measurement/index.mdx) supplies optional definitions; [Baseline](./baseline.mdx) records actual starting evidence. Governance and Measurement are supporting references, not one-time gates.
|
||
|
||
<details>
|
||
<summary>Readiness questions behind the roadmap</summary>
|
||
|
||
These are readiness questions, not additional roadmap stages. Stage 01's topic pages define the recommended decisions and evidence within existing teams. Designate accountable people and agree workflow-specific acceptance criteria before evaluating; this strategy does not appoint approvers or approve thresholds.
|
||
|
||
### Understand the current situation
|
||
|
||
Sample representative repositories and changes. Retain repository revisions, tests and CI reliability, maintainability, technical debt and security findings. Trace ownership, review and release practices, handoffs, rework and bottlenecks. Keep baseline findings, a process map and prioritized gaps; hold selection if the sample cannot explain how work is delivered and accepted.
|
||
|
||
### Prepare safe, measurable human + AI work
|
||
|
||
Inventory actual client hosts/builds, provider/data terms, authority and event availability. Confirm accountable people and independent reviewers, forbidden actions, data/retention decisions, recovery and a reproducible baseline. Hold if accountability, lawful collection or critical acceptance checks remain unresolved.
|
||
|
||
Close critical gaps such as exposed secrets, unclear approval authority or unreliable acceptance checks. Broader refactoring and non-critical debt can run alongside the selected work. Stage 1 introduces no new privileged autonomous actions.
|
||
|
||
### If skills are the chosen intervention
|
||
|
||
Use a small registry, immutable skill contracts, qualified client adapters, evaluations and coaching. Verify the measurement calculations with synthetic fixtures before interpreting real outcomes. Require mandatory safety checks, independent task acceptance, reconciled source coverage and user feedback. Hold or narrow scope if quality or coverage is inadequate; usage alone does not justify expansion.
|
||
|
||
### Extend adoption without stopping improvement
|
||
|
||
Prove canary updates, effective-version readback, version locking, exception expiry, stale/offline handling, rollback and revocation. Hold if effective versions or controls cannot be verified or the catalog cannot be supported.
|
||
|
||
Use evidence to choose the next SDLC phase; no second or third phase is assigned here. Continue the improvement loop in Delivery and every phase already using skills.
|
||
|
||
### Consider autonomy only as a separate future option
|
||
|
||
Beyond six months may mean deeper coaching, deterministic tooling or no expansion. If additional autonomous authority solves an evidenced problem, [future options](./stage-02-autonomous-agent.mdx) require a separate authority/readiness decision. Recommended controls include exact-artifact approvals, idempotency, duplicate/outage recovery, separation of duties, audit and kill-switch drills. Prove human takeover; never infer permission from missing evidence. Keep sensitive decisions human. Changed client, provider, data or authority boundaries reopen the relevant checks.
|
||
|
||
</details>
|
||
|
||
**Next:** [Work through one bounded experiment →](./stage-01-skills-adoption.mdx)
|
||
|
||
</div>
|