6 Months Target
Proposed strategy · No company results or organizational commitments are claimed.
Improve the work, not the AI usage
The assignment describes close to 80 engineers, growing to around 100 by year end, across more than 10 teams. Every developer already uses AI, unevenly. I start solo, reporting to the CTO, with no formal authority over teams. The comparison is current AI-assisted practice—not an imagined no-AI organization. These facts come from AI Architect Test Task, Context and question 1; everything below is a proposal.
My first investment is time alongside developers and reviewers: find where useful changes stall, then remove one evidenced constraint. Delivery is a starting hypothesis because a bounded change, tests and independent review can expose both benefit and transferred work. Discovery may show that flaky CI, unclear requirements or review capacity matters more than agent instructions. Fix that bottleneck instead.
The month-by-month plan moves from trust and observation to one willing partner team, bounded experiments, then selective handover. I offer pairing and show verified examples rather than mandate tools. The CTO sponsors access and resolves priority conflicts; team leads agree contributions. Neither sponsorship nor this document conscripts a team.
Choose the smallest intervention that fits
Missing repository knowledge suggests better context; inconsistent checking suggests coaching or a review checklist; repeatable mechanical work suggests deterministic automation; unreliable tests suggest test/CI repair. A skill packages reusable instructions, prerequisites and verification steps when repeated agent-guided work genuinely needs them. It is one option, not permission and not proof of correctness. Compare alternatives against the same bottleneck before funding a catalog or control platform.
Use the worked experiment to connect a hypothesis, small initial measures, safety checks and a retain/change/stop decision. Existing review, data restrictions and release authority stay in place. The 16 metric contracts and skills references are optional depth, not startup bureaucracy.
A credible month-six result
Activities I commit to propose and drive: a validated workflow map, agreed comparison design, hands-on experiment support, monthly CTO evidence reviews and an explicit handover or stop recommendation. Delivery depends on agreed access and partner capacity; blocked work is reported, not disguised as progress.
Contingent visible outcome: one workflow retained by one partner team, with a second willing team trying a bounded transfer only if value and support hold. Developers can reproduce the example; reviewers see better evidence without extra hidden burden; a voluntary champion and backup can maintain it. Evidence must include comparable task records, independent acceptance, matured defect follow-up, review/rework effort, setup and upkeep costs, and a decision signed by the actual owner. These are required evidence types, not results already obtained or promised percentage gains. If the pilot fails, month six should instead show what was stopped, why, and which cheaper intervention replaced it. Neither scenario means rollout to all 80–100 engineers.
Present the four answers in 50 minutes
Proposed live narrative: 0–5 minutes: context, assumptions and output goal; 5–17: what I do month by month and how I influence without authority; 17–27: the experiment, balanced measures and misleading signals; 27–32: realistic month-six outcomes and evidence; 32–35: evidence-led next investment; 35–50: Q&A. This is 35 minutes content + 15 minutes Q&A, not an assignment-imposed split. Content matters more than visual polish. Walk the main story, then open references only for questions.
Beyond six months, choose deeper improvement, careful replication, additional enablement capacity or stopping an ineffective approach. Beyond 6 Months bridges this evidence to the long-term human-controlled autonomous SDLC Target. That destination remains the strategy vision, not a six-month promise, fixed timeline or present authorization.
Assumptions register — validate before depending on them
| Status / assumption | Validate when and with whom | If false |
|---|---|---|
| PDF fact: scale, growth, uneven existing AI use; solo CTO-reporting role without team authority | Restate with CTO in month 1; do not substitute the portal organization model for company evidence | Replan capacity and influence approach if the brief changes |
| Unknown: repositories, languages, tools, providers and data restrictions | Month 1, developers plus actual security/platform contacts | Use approved sanitized material; do not choose a client or send restricted code before clearance |
| Hypothesis: regression-evidence rework is an important Delivery bottleneck | Month 1, trace recent changes with developers and reviewers | Choose the observed bottleneck; do not force a skills pilot |
| Unknown: at least one team can volunteer review and pairing time | Month 1–2, team lead and CTO | Reduce scope to discovery/demonstration; ask CTO to resolve priorities, not impose uptake |
| Unknown: tasks, PRs, CI and defects can be linked lawfully | Month 1–2, evidence owner and privacy/security contact | Use a minimal approved worksheet; label missing outcomes and limit claims |
| Unknown: enough comparable tasks mature in the pilot window | Month 2, prospective baseline | Narrow the question or run feasibility-only work; no unsupported benefit claim |
| Unknown: a champion can own upkeep without the architect | Month 5, willing team and lead | Retain only within funded support capacity or retire; do not expand |
The portal's departmental model is not confirmation of Eldorado's actual reporting lines. Reference-role names below are candidate functions to map to real people, not appointed authorities.
Next: 6 Months Roadmap →