Claude Across the Team

"Everyone can use it for anything" is not a policy; it is the absence of one. A deliberate rollout starts by mapping where Claude genuinely helps in your practice and who is best placed to direct it there - because the person with the domain judgement to check the output is the person who should own that use.

Think in terms of jobs and owners rather than a blanket licence. Drafting and correspondence - proposals, emails, minutes, reports - sits naturally with whoever already owns that writing, now faster. Specification and schedule drafting belongs with your technical staff, who can catch a wrong clause. Research and precedent-gathering suits everyone but with the standing reminder that Claude's "facts" are leads to verify. Code and automation (Module 8) sits with the one or two people comfortable running and testing a script. The point is not to restrict for its own sake, but to match each use to someone who can judge the result - because Claude produces plausible output, and plausible-but-wrong is only caught by a competent human who owns that domain.

It also helps to name, lightly, what Claude is not for in your studio. Not for the final decision, the seal, or the client's trust. Not for pasting confidential material outside approved plans and settings. Not for anything a competent person will not check before it leaves the building. A one-page "how we use Claude here" note - the greenlit jobs, the owners, the hard nos - does more for consistency than any amount of individual enthusiasm.

Scale this to your size. A three-person studio needs a shared understanding over coffee and a shared Project, not a governance committee. A thirty-person practice needs written roles, named custodians for the shared Projects and prompt library, and someone accountable for the data settings. Either way the principle is the same: adoption is a set of deliberate choices about where a fallible, powerful assistant belongs, made by the people who will answer for the output.

The failure mode of most tool rollouts is a one-hour demo, a wave of enthusiasm, and a quiet return to old habits within a fortnight. Training sticks when it is grounded in the team's real work, teaches judgement rather than buttons, and is reinforced by the shared system rather than left to memory.

Anchor the training in this course's spine: Claude is a plausibility engine you direct and then judge, with scrutiny scaled to the stakes. A designer who internalises that one idea will use Claude well across tasks you never trained them on; a designer who only learned "type this to get that" is lost the moment the task changes. So teach the loop - direct, draft, judge, refine - and teach it on the studio's own jobs: bring a real spec, a real client email, a real option comparison, and have people run them through the shared Projects and prompt library. They learn the tool and the studio's way of using it at once.

Teach the failure modes as vividly as the wins, because a team that has seen Claude confidently invent a clause, a standard number or a citation checks its work; a team that has only seen it dazzle does not. Show a real hallucination. Show a plausible cost estimate that was wrong. Make verification feel like professional instinct, not bureaucratic drag.

Then reinforce it structurally so it does not decay. New starters get pointed at the shared Projects and the prompt library on day one, so the good path is the default path. Keep a short internal channel where people share prompts that worked and mistakes they caught - peer learning outpaces any formal session. And revisit briefly when models or features change, so the team's mental model stays current. Training is not an event; it is the shared system plus a culture of showing each other, which is precisely what Projects (9.1) and the prompt library (9.2) exist to support.

The commonest disappointment after a rollout is not that Claude fails - it is that the output is inconsistent. One person's client letter sounds like the practice; another's sounds like a chatbot. One spec follows the house format; another invents its own. This is not a Claude problem; it is a shared-foundation problem, and the earlier lessons of this module are the cure.

Consistency comes from everyone starting from the same base. If the whole team drafts from the same practice-wide Project (9.1) and the same reusable prompts (9.2), their output converges on the studio's voice and format by default, because the voice and format live in the shared context, not in individual habits. Where a rollout skips this and simply hands people the raw tool, divergence is guaranteed - each person supplies their own context, so each gets their own house style. So the single most effective consistency measure is not a style-police rota; it is making the shared Projects and prompt library the normal way everyone works.

Guard against the specific ways a rollout turns messy. Shadow usage - people using personal accounts with unchecked data settings - is both a consistency and a confidentiality risk; give the team the approved route and make it the easy one. Silent divergence - everyone quietly building private prompt collections - fragments the practice's knowledge; channel improvements back into the shared library instead. Uncritical adoption - output going out unchecked because "the AI wrote it" - is the dangerous one; the culture must be that Claude's draft is the start of your work, never the end of it. And over-standardisation in the other direction can flatten genuinely good judgement, so leave room for people to depart from a template when the job demands it.

The test of a healthy rollout is simple: pick any recent Claude-assisted document from anyone in the studio, and it reads like the practice, follows the format, and shows evidence of a human having checked it. If that is true across the team, the system is working. If output quality is a lottery depending on who sat at the keyboard, you have handed out a tool without building a system - go back to the shared foundation.

A studio rollout raises questions a personal habit never did, and the biggest is data. The moment more than one person is pasting client material into Claude, you need a clear, current answer to: what is safe to paste, on which plan, under which settings? Get this wrong and a rollout that saved time creates a confidentiality breach - the one mistake a practice cannot afford.

The honest position, sized conservatively and checked against current terms: on consumer plans, conversations may be used to improve Claude unless you opt out, and retention settings apply - so confidential client data, personal data and anything under NDA should not go onto consumer plans without deliberately checking and configuring the data settings. Business (Team and Enterprise) and API usage is generally not used to train models by default and offers stronger data controls and admin oversight - which is why, for a practice handling client work, a business plan is usually the right home, not a nice-to-have. Always strip or anonymise client identifiers where you can, and when in doubt, keep sensitive material out. This is the heart of Module 10.1, and it is the part of a rollout you cannot delegate to enthusiasm.

Business plans also buy the admin controls a team rollout needs: managing who has access, centralising billing, and setting data terms once for everyone rather than trusting ten individuals to configure their own. That single fact - one set of governed settings instead of ten unchecked ones - is often the strongest practical argument for putting a studio on a business plan. Treat plan choice as a governance decision, not just a cost one.

Write the rules down, briefly and plainly, as part of the "how we use Claude here" note: which plan and account the studio works in, what may and may not be pasted, and who to ask when unsure. Keep it current - plans, features and terms change, so revisit it, and note when you last checked. None of this is glamorous, and all of it is what separates a professional rollout from a lucky one. The reward for getting roles, training, consistency and data right together is real: a practice where Claude quietly makes everyone better, on a foundation you can defend to a client.