Question 1

How would you lead AI tool adoption on your team?

Accepted Answer

Give a staged plan with an exit criterion for each stage: 1. Pilot (2-4 weeks, 2-3 people). The goal is neither "speed gains" nor "everyone learns" — it is identifying which tasks actually benefit. Exit: a concrete list. 2. Repo preparation. CLAUDE.md, permission rules, the first 2-3 skills. Skipping this makes the rollout fail. Exit: a newcomer can start with zero setup. 3. Rollout. An onboarding doc, the rules, a help channel. Exit: active use. 4. Standardisation. Review rules, security, CI integration. 5. Measurement. Time to PR, bugs found in review, incidents. Not lines of code — that inflates. The most important point: don't mandate it. People who see the benefit adopt it. A mandate creates resistance and ends in performative use. The second point: listen to the sceptic on the team. Their concern is usually real — quality, responsibility, code nobody understands. Turning those concerns into rules both solves the problem and turns them into an ally.

Question 2

How would you measure the benefit of AI to the team?

Accepted Answer

Name the trap first: productivity metrics (lines, commits, PR counts) inflate easily with an agent and say nothing about quality. Making them KPIs is harmful, because teams optimise what is measured. Useful indicators: Cycle time — from task start to merge. This measures the real flow. Quality signals — bugs found in review, production incidents, hotfix count, flaky test count. If these worsen, the speed was bought on credit. Work that wasn't happening before — did untested modules get tests, did technical debt shrink. That is often the agent's most real benefit. Perceived quality (subjective but important) — a team survey: what works, what frustrates. Method: compare before and after the pilot. The trend matters more than any absolute number. Be honest at the end: these measures are imperfect — too many variables (team composition, project phase). So base the decision on numbers plus team feedback, not numbers alone.

Question 3

A team member says "AI will replace my job". How do you respond?

Accepted Answer

Neither dismiss the concern nor offer empty reassurance — both cost trust. Acknowledge it: "That concern is reasonable and it's widely discussed in the industry." Be concrete about what changes: The value of writing mechanical code drops. Framing the problem correctly, architectural decisions, verifying the result, and carrying responsibility — those rise in value, because they become the bottleneck as code volume grows. Deep knowledge of the system matters more, because the agent works without that context. Practical advice: "Your value isn't in competing with the agent at typing — it's faster than you there. It's that you know what should be written, whether it's right, and how it fits the system." What I would not say: "Don't worry, nothing will change." That isn't true and isn't convincing. The work does change — and saying so plainly lands better. End with a practical step: invite them into the pilot so they build their own experience. The unknown is always more frightening than the reality.

Stage	What happens	Success criterion
1. Pilot	2-3 people, one project, 2-4 weeks	A concrete list of which tasks it helps with
2. Repo preparation	CLAUDE.md, permissions, first skills	A newcomer can start with zero setup
3. Rollout	Open to the team plus an onboarding doc	Active use rather than sporadic
4. Standardisation	Review rules, security, CI	Quality metrics haven't degraded
5. Measure and improve	Periodic review of what works and what doesn't	Skills and rules stay alive

AI adoption across a team

📚 Sources and documentation