Designing for Adoption¶
Finding Your Wedge¶
A wedge project is the right first experiment for your organization — bounded scope, low risk, high visibility, and close enough to real work that the results are credible.
The wrong wedge: a toy project that proves AI works on problems nobody cares about. The right wedge: a real problem that people are already frustrated by, scoped small enough to deliver in weeks.
| Wedge Property | What to Look For | Red Flag |
|---|---|---|
| Real pain | A problem people complain about regularly — slow deployments, manual compliance checks, repetitive data processing | "Let's pick something easy" — easy problems don't generate organizational urgency |
| Bounded scope | Completable by a small team in 2-4 weeks | If you can't describe the done state in one paragraph, scope is too large |
| Visible results | Outcomes that non-technical stakeholders can see and understand | Improvements that only developers appreciate don't create organizational momentum |
| Existing comparison | A current process to measure against — "this used to take X, now it takes Y" | No baseline means no credible before/after comparison |
The wedge works because it shifts the conversation from abstract ("AI could help us") to concrete ("AI did help us — here's the data"). The safe experiment pitch from Section 2 provides the framing; the wedge project provides the substance.
The Adoption Staircase¶
Successful AI adoption is not a single decision — it's a progressive staircase where each step builds the trust required for the next:
| Stage | What Happens | What Builds Trust |
|---|---|---|
| 1. Wedge experiment | One team, one bounded project, measured results | Concrete evidence that the approach works here |
| 2. Shared infrastructure | The wedge team's skills library and context architecture become templates for the next team | The next team starts from a working foundation, not from scratch |
| 3. Organizational standards | Quality gates, eval harnesses, and compliance scanning become pipeline requirements | The factory infrastructure becomes the organizational quality bar |
| 4. Self-sustaining capability | Teams adopt and extend the shared stack independently; the factory operates across teams | The system grows without depending on the original advocates |
The staircase mirrors the track you just completed: Lift 1 (individual toolkit) → Lift 2 (shared infrastructure) → Lift 3 (autonomous operations) → Lift 4 (organizational adoption). You experienced the staircase. Now you're designing it for others.
The architecture of participation from Lift 2 — legibility, modifiability, composability, shareability — applies directly to adoption design. The shared skills library you built is only useful to the next team if they can read the skills (legibility), adapt them (modifiability), combine them with their own (composability), and use them without adopting your entire setup (shareability).
Designing for the Next Person¶
The hardest adoption problem: the first user experience. If a new team's first interaction with your factory is a 50-page setup guide, adoption dies on page 3.
Design principles for adoption that sticks:
- Documentation is the floor, not the ceiling. Every team needs docs. What differentiates is onboarding that works through the tools themselves — the project context file bootstraps the AI coding assistant, the shared skills library encodes the workflows, the quality gates enforce the standards. A new contributor's first session should produce useful, correct output because the infrastructure does the teaching.
- Self-describing workflows. The skills library should be discoverable — a new contributor asks "what workflows are available?" and the system answers. Skills with clear intent descriptions (the As a / I want / So that format) are self-documenting.
- Progressive disclosure. Don't front-load everything. Let contributors discover the quality gates when they fail, the shared skills when they encounter a repeatable task, the context architecture when they wonder why the AI already knows the conventions. The infrastructure reveals itself through use.
- Measure adoption, not just deployment. Deploying the shared stack to 10 teams is meaningless if 8 of them never use the skills library. Track usage: which skills get invoked, which quality gates catch failures, which context files get read. Unused infrastructure is dead infrastructure.
Team Discussion: Your First Experiment¶
Format: Team Discussion Time: ~3 minutes
Think about your actual organization — the team, agency, or company you'll return to after this workshop.
Discuss: What's the wedge project? What's the real pain that people already complain about? Can you scope it to 2-4 weeks with a small team? What would the "before" look like, and what would the "after" look like — in terms a non-technical stakeholder could understand? Who needs to approve the experiment, and what evidence would convince them? And the adoption question: if the experiment succeeds, what's step 2 — how do you go from one team's success to the next team's adoption?
Key Insight¶
You can see further than most people in your organization right now. That's not a status — it's a responsibility. The factory you built is the proof of concept. The wedge project is how you make it real for others. The adoption staircase — from bounded experiment to shared infrastructure to organizational standard — is the same progression you just experienced across this track. The disruptor's mandate is not to transform everything at once. It's to find the wedge, run the experiment, show the evidence, and pull someone forward. Go back and do that.