Claude Cowork for Design Leaders

The hardest part of leading a design team isn't the thinking. It's the knowledge transfer.

By the time I became a Director, I had accumulated years of judgment about how things work. I knew which stakeholders needed proof before they'd support me. I knew when I needed to push back and when it was best to wait. I knew what "ready for promotion" actually looked like, beyond what the skills matrix said. I'd navigated reorgs, budget cuts, and executive politics. I'd made thousands of decisions and learned from most of them.

The problem was that all of my experience lived in my head. And the people who needed it most, the managers and senior ICs on my team building their own judgment, could only access it when I was in the room. Which I wasn't. Not enough, anyway.

I tried bringing promising leaders into senior meetings so they could see how decisions got made. I shared my thinking out loud. And still, one of the best leaders I ever hired told me, "I understand everything you said in that meeting, but I don't know how you got from where I am today to where you are."

She understood what I did. She couldn't see how to do it herself. The gap wasn't information. It was access.

In the first article in this series, I wrote about using Claude Cowork to build my own thinking infrastructure. Essentially a tool that structures my own judgment so I could retrieve it when needed. That article was about individual designers building thinking infrastructure for themselves.

This one is about leaders building for others.

The shift

The first article was about codifying your thinking so you can access it. This one is about codifying your thinking so your team can access it.

Design leaders don't lack thinking. They lack time to transfer it.

As strategic decisions are made, while positioning has been figured out, and when feedback has been given, the patterns of what works and doesn't have been learned. All of that thinking exists. It's just locked in personal notes, within 1:1 conversations nobody else hears, and in meetings where very few see the reasoning behind the reasoning.

Rather than expecting designers to figure it out, what if leaders where more hands-on? What if you could build tools that surface your thinking at the moment someone on your team actually needs it? What if the solution lies not in using AI to generate a new strategy or a chatbot to replace you, but in systems that make your existing thinking accessible so that when someone else faces a situation you've seen before, they can learn from your experience without scheduling an hour on your calendar.

Here are five things design leaders can build with Claude Cowork.

1. Build a leadership learning tool for your team

Every design leader develops an intangible methodology over time.

How to read a stakeholder. When to push and when to wait. How to frame a decision for different audiences. What questions to ask when someone brings you a problem. You've learned these patterns through painful trial and error, and now they run automatically.

The people on your team are developing their own methodologies through painful trial and error. They're making the same mistakes you made, learning the same lessons you learned, but because they don't have access to the pattern recognition you've built, they're experiencing the exact same frustrations you had while you were going thru it. But for the success of the team, you need them to move through this learning in a different way.

With Claude Cowork, you can build a Skill that encodes your methodology. Start with the situations that come up most often: a PM who isn't including design early enough, a stakeholder who's skeptical, a project that's going sideways, a direct report who needs to level up their communication. Capture how you think about each. Not just what to do, but how to diagnose the situation, what questions to ask, what patterns to look for.

When I built this for CDO School, I created a scenario detector that pattern-matches real situations to pre-built guidance. "My PM keeps cutting me out of decisions" routes to a specific framework for diagnosing partnership problems. "I have a board presentation next month" routes to a different set of questions and approaches.

Your version encodes your experience. When a new manager on your team faces something you've seen a dozen times, they can get your perspective without needing to wait for your next 1:1.

Cowork limitations: This only works if you can articulate what you actually do. Most leaders can't. Not because they don't know what they do, but because they've never had to put it into words. The process of building this will force you to make your intuition and judgment explicit. That's uncomfortable, and it takes time. But it's also the most valuable part.

2. Build a strategy and positioning reference

Every design leader has made strategic decisions about where the team focuses, how design is positioned in the organization, which battles to fight and which to defer. It's likely many of those decisions are documented somewhere, but they're scattered in strategy decks, planning docs, OKRs, and emails.

But documented isn't the same as accessible.

When someone on your team needs to understand why you're prioritizing platform work over new features, or how design is positioned with the product org versus engineering, or what the team's point of view is on a specific business domain, they have to either dig through random resources hoping to find the answer, or ask you directly.

Build a reference Skill that makes your thinking queryable. Upload your strategy documents, your positioning frameworks, the priorities you've documented, the constraints you've identified. Structure it knowing someone will ask: "Why are we focused on X?" or "How should I position this work with the PM team?" or "What's our stance on taking on this kind of project?"

The goal isn't to replace your strategic judgment. It's to make the judgment you've already established accessible to people making daily decisions. When the thinking is visible, your team has the confidence to make decisions that align with it without needing to check with you first.

Cowork limitations: Strategy evolves. The positioning that made sense six months ago might not fit today. You'll need to update the source material as your thinking changes. And for truly novel situations, the tool will surface relevant context but won't replace the judgment call. That's still yours. Or better theirs, if you're developing them to make those calls.

3. Build a feedback and development guide

You've given feedback to dozens, perhaps hundreds, of people over the years. You've made promotion decisions. You've coached managers on how to develop their teams. You have criteria in your head for what "ready for the next level" looks like that go beyond the leveling rubric.

Most of that stays in your head. Each conversation happens once, with one person, and the pattern recognition you used to give that feedback isn't captured anywhere. The next manager who faces a similar development question has to start from scratch or find time on your calendar. (See that pattern again)

Build a Skill that encodes your development philosophy. What do you actually look for when assessing readiness? What feedback patterns do you find yourself repeating? What's the difference between someone who's doing the job well and someone who's ready to grow into more scope?

Include the nuance. "Senior Designer" might mean something generic on paper, but you know the unwritten expectations and skills that translate to a promotion. The stakeholder skills, the communication maturity, the ability to navigate ambiguity. Capture those.

Cowork limitations: Development is deeply contextual. While a tool like this can provide frameworks and criteria, the application to a specific person still requires human judgment. Use this to accelerate calibration conversations, not replace them. And be careful about confidentiality. This should encode your general philosophy, not specific feedback about specific people.

4. Build an executive communication encoder

You've presented to executives. You've made business cases. You've learned what works in your organization: the arguments that land, the framings which get traction, and the things your leadership team cares about.

Everyone on your team who is presenting to stakeholders is expected to know this stuff. While they may well be experts in design, they're amateurs in communicating up.

Build a Skill that encodes what you've learned about communicating with senior leaders. Not another generic "how to present to executives" guide, but a repository of your specific knowledge of your organization. What does your CEO care about? How does your CFO think about design investments? What's landed in past presentations and what's fallen flat?

Upload presentations that worked. Capture the structure, the framing, the arguments that got buy-in. When someone on your team is preparing a presentation, they can check their framing against patterns you've seen succeed.

Cowork limitations: Every executive audience is different, and what worked last quarter might not work after a reorg or a strategy shift. The tool provides patterns, not guarantees. Use it for prep, but stay present in the actual moment.

5. Build a decision-making pattern library

Over your career, you've made hundreds of decisions. When to escalate and when to handle it yourself. When to fight for resources and when to work with what you have. When to push back on a stakeholder and when to give them what they're asking for even if you disagree. When to protect your team from organizational chaos and when to let them see it.

You adapt instinctively. You team is not there yet.

Build a Skill that captures your decision-making patterns. Think about the judgment calls you've made repeatedly: hiring for fit-for-purpose, budget conversations, stakeholder conflicts, team structure decisions, prioritization trade-offs. For each one, try to articulate the factors you weigh, the signals you look for, the criteria that tip you one direction or another.

"I just knew it was time to escalate" isn't useful. But "I escalate when I've tried two direct approaches that haven't worked, when the stakes are high enough that inaction creates real, measurable risk, and when I have a clear ask for what I need the escalation to produce" That's a pattern someone else can learn from.

Cowork limitations: Judgment is contextual. Your patterns might not apply to every situation. The goal is to expose your thinking as a reference, not to create a rulebook.

What this requires of you

These tools don't build themselves.

Most leaders have never had to explain how they make decisions. Not really. They've been rewarded for making good calls, not for documenting their reasoning. Building these tools forces you to slow down and make the implicit explicit. Why do you read that stakeholder as a skeptic? What signals are you picking up? When you chose to push back on that executive request, what factors made that the right call?

You'll discover that some of your "judgment" is harder to explain than you thought. You'll find gaps in your own reasoning. You'll have to commit to positions you've held loosely.

The leaders who shaped me most weren't just good at their jobs. They could explain what they were doing and why. They made their thinking visible. These tools are a way to do that at scale, and you're the only one who can do this work. Articulation of good leadership judgment falls squarely on you. If you do that well, you're not replacing your judgment. You're extending it.

This is the second in a series of three articles. Previously: Claude Cowork for Designers. Next: Claude Cowork for DesignOps. Five things to build when you're responsible for scaling good design.