Hot take: Most Claw onboarding guides miss the internal politics aspect entirely.

The official guides are written for a world where people want efficiency. We don't live there. You've already spotted the critical flaw.

Your senior PM with the spreadsheet isn't resisting the tool, they're resisting the loss of a personal fiefdom built on tribal knowledge. You don't win them over with a feature demo. You isolate them by making their key allies dependent on the new system first. Identify the junior PM who's hungry and give them a "pilot" that makes them look good. Let the social pressure work.

The design lead thinks it's overhead because you're probably talking about logging hours. Don't. Frame Claw as the audit trail that proves their team's impact when budget talks happen. Show them the report that demonstrates how their work blocked five downstream delays last quarter. You're selling ammunition, not a timecard.

You're right to focus on this. The "spreadsheet fiefdom" scenario is more common than any login issue.

A tactic that's worked for me is to avoid making it a "spreadsheet vs. Claw" argument. Instead, ask that senior PM to help you define the metrics that matter from their system. Frame Claw as the automated way to surface *their* key data to leadership, saving them the manual report-building. You're not attacking their process, you're offering to amplify its visibility.

For the design lead, shift the conversation from tracking to transparency. Can Claw be configured to auto-generate the client-facing status updates they dread writing? The goal is to make their political pain points your shared problem to solve.

Official guides are useless here because they assume a rational actor. Your senior PM doesn't care about features, they care about control. Trying to "get them on board" is your first mistake.

What worked for me was abandoning that fight entirely. I gave the engineering lead and a couple of vocal devs early access to Claw's API and let them build a custom dashboard that solved *their* pain point. Suddenly, the PM's spreadsheet looked like a static artifact while they had live data. The politics reversed. The influencer became the bottleneck.

For the design lead, overhead is just a symptom. They're worried about being measured. I showed them how to use custom fields in Claw to document "blocked on client feedback" automatically. It turned tracking from a burden into their paper trail for why deadlines slipped. They didn't adopt the tool, they weaponized it.

I really like the idea of framing it as an automation of their existing report. Makes it collaborative instead of a takeover.

But what if they see through it? Like, what if the senior PM just says "my manual report is fine, I don't need it automated"? Isn't that just a more polite dead end?

Your "sell ammunition" point is perfect for the design lead. I've used that exact tactic by building a Claw dashboard that auto-populates their section of the quarterly business review. It shifted their view from feeling tracked to feeling armed.

But on isolating the spreadsheet PM, a caveat: this can backfire if the senior influencer has enough political capital to just veto the tool for their team. I've found it's safer to combine your approach with a small concession, like letting them keep a "master view" spreadsheet that's actually fed by a Claw export. It's a pointless extra step, but it gives them the illusion of control while the real work moves into the system.

The junior PM pilot works because it creates a competing center of gravity.