First team rollout — week 1 to week 6

TL;DR. Take a single pilot user and turn them into a working team of 5–10 inside six weeks, without burning out the sponsor or scaring IT. Six weeks, six milestones: Observe → Operator productive → Co-design → Onboard three teammates → Harvest skills → ROI checkpoint. The sequence matters more than the length.

The 6-week shape#

Pin those dates on a calendar before week one starts. The forcing function is the date, not the activities.

Week 1 — Observe#

Goal: understand the work before you change it.

• Two shadow sessions of 90 minutes each with the pilot operator. Watch them work; do not intervene.
• One pain/gain map per role, on a single page.
• Inventory of recurring document types and the time each takes today.
• Workspace folder created and CLAUDE.md skeleton in place.

Deliverables: shadow notes, pain/gain map, baseline time data.

The temptation in week one is to skip to building. Resist. Two days of observation prevent two months of building skills nobody asked for. The full method is on Observe → Co-design → Ship, with deeper how-tos on Shadow sessions and Pain/gain mapping.

Week 2 — Pilot operator productive#

Goal: one person ships real work daily.

• Three Cowork sessions on real tasks the operator already does.
• Iterate prompts until two are reliable enough to be saved templates.
• Save those prompts in CLAUDE.md.
• Daily 15-minute check-in between operator and pilot owner.

Deliverables: two production-quality prompt templates, one before/after time-savings number you can defend.

The two-prompt threshold is intentional. One template proves nothing; three is too many to debug. Two is enough to prove the loop and learn what makes a prompt sturdy.

Week 3 — Co-design with team#

Goal: extend from the operator to two more teammates.

• A 90-minute design workshop. Walk teammates through the saved prompts; ask what is missing.
• Co-write any new prompts on the spot, run them live, accept the awkward silences while Cowork thinks.
• Add roles to CLAUDE.md: who approves what.
• Identify which workflows are good candidates for skills (reusable units bigger than a prompt).

Deliverables: shared prompt library inside CLAUDE.md, role assignments, list of skill candidates.

Co-design beats hand-off. Teammates who watched a prompt born will defend it when it stumbles; teammates handed a prompt cold will quietly stop using it.

Week 4 — Three teammates onboarded#

Goal: three or four people in the function actively using Cowork weekly.

• One-on-one onboarding sessions of 45 minutes each.
• Each onboarded person ships at least one real artifact through Cowork.
• Light KPI tracking begins: hours saved per role per week.

Deliverables: active-user count, first KPI snapshot.

If onboarding stalls — one of the three teammates does not ship anything — find out why this week, not in week six. Usually it is a workspace-access issue or a prompt that does not fit the second person's flow.

Week 5 — Skills and templates harvested#

Goal: the team's best prompts are no longer prompts; they are skills.

• Convert the top three saved prompts into Cowork skills (a Tinkso engineer or your own technical lead does this).
• Publish skills to the workspace; the team can invoke them by name.
• Update the change-management plan: how does the team learn about a new skill?

Deliverables: three production skills, documentation, runbook for adding a fourth.

Skills compound. The first three are the hardest; the fourth and fifth come faster because the team knows what good looks like.

Week 6 — ROI checkpoint#

Goal: a defensible answer to "is this working?"

• Re-measure the baseline metrics from week one.
• Sponsor, pilot owner, and Tinkso (if engaged) review the numbers together.
• Decide one of three: scale to the next function, hold and stabilise, stop.
• Publish a one-page internal note for the sponsor's stakeholders.

Deliverables: ROI memo, scale decision.

The decision is the deliverable, not the meeting. Even a stop decision is a win — you stopped before the second function got the same shape and proved the same lack of value.

Common rollout failure modes#

• The unstaffed pilot. The owner gets pulled to other priorities; the pilot stalls in week three. Defend the owner's calendar in week one.
• The "everyone gets a licence" buy. Without role mapping, half the seats sit idle. See Cowork vs Chat vs Code.
• The over-engineered week one. Trying to build skills before observing. This is the most common pushback we give clients in week one.
• The unmeasured pilot. No baseline equals no ROI equals no wave two. Take the time to write the numbers down.
• The shadow rollout. Sponsor not aware; IT finds out via help-desk tickets. Loop IT in from the pre-flight meeting.

Tinkso's take#

We size most pilots at six weeks because it is the shortest stretch where you can both observe and ship. Compress to three weeks and you skip the observation; stretch to twelve and the team forgets the why. The sequence matters more than the length: Observe before Co-design, Co-design before Ship.

The other reason for six weeks: the sponsor can defend the budget over six. Twelve becomes a programme that needs steering committees.

Try this#

Right now, pick the date for your week-six checkpoint and put it on the sponsor's calendar. Backdate weeks one through five from there. Send the calendar invite this afternoon. The forcing function is the date, not the activities.