Tech Update / Adventures with Claude Code #25

Rolling out Claude Code to your team – the first 30 days

Buy licences, send a link, done? That's how most rollouts fail. Three weeks later two people use Claude Code enthusiastically, and the rest tried it once and "weren't really convinced".

Here's the approach we now recommend in almost every project.

🗓️ Week 1: one pilot, one project

Two or three developers, a real project, not a sandbox. First goal: a good CLAUDE.md (part 4) and a set of permissions (part 7) checked into the repository. No skills, no plugins yet.

🔧 Week 2: automate the most annoying routines

Each pilot picks the one task that annoys them most and turns it into a skill (part 3). Fetch a ticket, create a branch, write the changelog. Small wins you can show off.

👥 Week 3: bring in the team

A short demo with real examples from your own code, no slides. Then pairing: a pilot sits next to each new colleague for an hour. That beats any training course.

📦 Week 4: standardise

What has proven itself goes into a plugin (part 14) and, where needed, into centrally managed settings. And: a short retro. What saved time? Where did Claude create more work than it took away?

A word of caution:

The biggest hurdle isn't the technology, it's the way of working. Anyone used to typing every line themselves first has to learn to describe tasks well and review results well. That takes longer than 30 days. Don't expect big numbers in the first weeks, expect lots of small "aha" moments.

My rule of thumb:

  • Start small: one team, one project, one real task.
  • Make wins visible: demos from your own code instead of marketing slides.
  • Standardise once something has proven itself, not before.

← Back to overview