Setting Up Claude for Co-work

I want to push back on something before we start. The lesson frames configuration as a technical problem, but most team conflicts around AI tools aren't actually about settings. They're about people not agreeing on what they want the tool to do.

That is a generous reframing of what is, in practice, people not reading documentation. But fine — yes, the human element exists. It does not excuse ignoring the configuration cascade, which most users treat as a philosophical abstraction rather than a thing that will actively break their shared workspace.

Explain the cascade, then, because I think the lesson buries it.

Workspace settings form the foundation. They apply to everyone. Session-level adjustments sit on top and take immediate effect — but only for that session. The failure mode, which is extremely common, is someone making a session-level tweak and assuming they've changed how the tool behaves for the team. They have not. They have changed it for themselves, right now, and then it disappears.

Which sounds obvious when you say it like that, but I've watched experienced teams get burned by exactly that. Someone reformats outputs for a presentation, doesn't document it, and suddenly nobody knows why the shared workflow looks different on Tuesday than it did on Monday.

Version control issues in shared AI environments are not mysterious. They are the entirely predictable result of treating a collaborative tool as a personal one. The lesson is correct that team protocols matter. It is slightly less forthcoming about the fact that most teams will not establish them until after something goes wrong.

Is that a criticism of the lesson or just a criticism of teams?

Both. One is a design choice, the other is a chronic condition.

Here's what I actually think is the most useful thing in here, though — locking workspace settings first before anyone starts experimenting. That's not obvious to people new to collaborative AI workflows. The instinct is to play around individually and consolidate later. Doing it the other way round saves an enormous amount of retrospective tidying.

It does. Establish the baseline, then deviate from it with intention and documentation. That is not a complicated principle. It is, however, one that requires a certain discipline that ad hoc AI adoption tends to systematically erode.

You say 'ad hoc adoption' like it's a character flaw. Sometimes teams are just moving fast.

Moving fast and having no idea what state your shared environment is in are not the same thing, even if they are frequently found together. The argument that speed justifies configuration chaos is the same argument people use to justify technical debt, and it ages equally poorly.

That's fair. Though I'd add — the lesson could do more to show what 'documenting team protocols' actually looks like in practice. It states the principle without giving anyone a template or a starting point. Telling people to establish protocols is not the same as showing them what a protocol looks like.

A genuinely valid criticism. 'Establish clear protocols' is advice in the same way 'eat well and exercise' is advice — technically correct, operationally useless without specifics. I'll concede that.

Mark the date. The takeaway for anyone listening: configuration hierarchy matters, workspace settings go first, and session changes are temporary by design. Know which one you're touching.