In our recent phased rollout of Claw (the internal CLI tool for environment management and deployment), we faced predictable but significant resistance from a segment of our engineering staff, primarily senior developers in the monolith team. Their objections centered on perceived cognitive overhead and a disruption to established, manual workflows. The standard company-wide demo and documentation repository saw a less than 30% adoption rate among this group after two weeks.
To combat this, we designed a structured, high-touch intervention: pairing each identified "reluctant user" with a pre-existing "champion" (an early adopter from their own product team) for their first five concrete Claw tasks. The protocol was as follows:
* **Pairing Criteria:** Champion and reluctant user shared a product vertical and had a pre-existing working relationship.
* **Task Selection:** Tasks were curated from the user's actual upcoming work backlog, translated into Claw commands. Examples:
* "Spin up a preview environment for PR #4512" -> `claw env create --pr 4512 --tier staging`
* "Fetch logs from the payment service in production from the last hour" -> `claw logs --service payment --env prod --tail 1h`
* "Drain and restart the canary pods for the user-api" -> `claw deploy restart --canary --service user-api`
* **Session Structure:** A 30-minute, dedicated screenshare session where the champion drove the first task, explaining the command structure. The reluctant user drove the next four, with the champion providing real-time correction and context.
* **Data Collection:** We captured pre- and post-session sentiment via a quick Likert scale survey and, more importantly, analyzed subsequent Claw usage logs for autonomous activity.
The quantitative results over a cohort of 22 reluctant users were significant:
* **Adoption Rate:** 86% (19/22) executed a Claw task independently within 48 hours of the pairing session.
* **Task Completion Speed:** For the standardized task "create a staging environment," median time dropped from ~15 minutes (manual process) to ~3.5 minutes (Claw) in post-pairing usage. The champion-assisted first attempt averaged ~7 minutes, showing the learning curve.
* **Sentiment Shift:** Pre-session, the average "comfort with Claw" score was 2.1/5. Post-session, it was 3.8/5. A follow-up survey two weeks later showed a rise to 4.2/5, indicating growing confidence with sustained use.
The qualitative feedback was more revealing. The primary friction point shifted from "I don't see the point" to specific, actionable feature requests ("I wish the `logs` command could do live tailing to my local terminal"), which we've since prioritized. The social proof component was critical—seeing a trusted peer efficiently solve a known pain point was more persuasive than any central platform team documentation.
However, the strategy had clear resource costs and limitations. It required:
* Significant time investment from champions (approx. 2.5 hours each including prep).
* Careful scheduling to avoid disrupting delivery timelines.
* A "playbook" for champions to ensure consistent messaging, which we provided as a simple checklist.
This approach proved far more effective than broad-based training for overcoming initial inertia in a skeptical, performance-sensitive user base. The key was embedding the learning within the user's immediate, concrete work context, facilitated by a peer rather than an "outsider" from the platform team. Our next experiment will be to scale a lighter-touch version of this for the next wave of onboarding, perhaps using recorded pairing sessions from these initial cohorts as training artifacts.
Data over dogma