Read the screen before you answer it
You will hear some version of "tell me about your leadership experience" in most senior design conversations. Before you answer, figure out which version they mean.
Evaluators asking about leadership are running one of two screens, and the screens require different evidence. Give function-builder answers to an organizational-steward screen and you sound junior. Give organizational-steward answers to a function-builder screen and you sound like a process person who cannot do the work. Pausing to figure out which question you are actually being asked is worth more than either wrong answer.
Listen to the vocabulary before you respond.
Function-builder vocabulary: "build," "stand up," "first design hire," "define the process," "greenfield," "create the practice," "establish design's role." The evaluator wants proof you can create organizational credibility for design where none exists. They care less about how many people reported to you than whether you built the thing people eventually reported into.
Organizational-steward vocabulary: "scale," "manage managers," "planning cycles," "calibration," "retain," "org design," "design ops." The evaluator wants proof you have run a functioning design organization through multiple cycles. Hired, developed, promoted, exited people through a management layer. Navigated headcount negotiations and performance calibration at scale.
Ambiguous middle: "player-coach," "hands-on but strategic," "lead a small team while still contributing." This is the most common framing and the least informative, because three companies can use identical language to describe three structurally different jobs.
Questions you will actually hear, and which screen they run
Scan this before the conversation. The bucket tells you which response path to prepare.
"What did you build first when you got there?" → Function-builder. They want the origin story.
"How did you establish design's credibility with the executive team?" → Function-builder. They want mandate creation.
"How big was your team?" → Organizational steward. They want a number and a reporting shape.
"How many direct reports, and did any of them manage others?" → Organizational steward. They are specifically screening for managers-of-managers.
"Walk me through your last calibration cycle." → Organizational steward. They want management mechanics.
"How do you balance staying hands-on with leading a team?" → Ambiguous. Could be either screen. Diagnose before answering.
"Tell me about your leadership experience." → Ambiguous. Too broad to answer without clarifying.
"Describe your management style." → Ambiguous, but leans steward. Listen to the follow-up before committing.
When you get an ambiguous question, the diagnostic question below is your first move.
Three current postings show why.
ServiceNow's Sr. Staff Product & Visual Designer posting calls for an "elite, hands-on craft visionary" who raises quality through pairing and code-backed workshops. No direct reports. No hiring accountability. Senior IC whose influence runs through the work, not through an org chart.
ServiceNow's Principal Product Designer for HR asks for someone who prototypes with large language models, sets the craft bar for agentic interaction patterns, and mentors other designers while remaining "genuinely, personally hands-on." Again, no direct reports. Principal IC with cross-team influence.
Amplitude's Head of Product Design also says "player-coach." But this role manages a 15-person team, hires and develops designers, owns design strategy across three product lines, and stays close enough to the work to push on production details. Formal people-management accountability plus craft proximity.
Same vocabulary, three different jobs. Confidence: high. When you hear "player-coach" and cannot tell which geometry the evaluator means, ask before you answer:
"When you say player-coach, what's the ratio you're imagining? Someone whose primary contribution is the work itself, with mentorship as a secondary channel — or someone who owns the team's output through hiring, development, and management, and stays close to the craft to maintain quality standards?"
That question is the best use of your first two minutes. It prevents you from spending ten minutes on a response path that does not match the screen.
If the screen is function-builder
Confidence: high. Your evidence is strongest here. Lead with it whenever the conversation allows.
The Alibaba.com mandate story answers this screen directly. You named the structural problem — a B2C interface serving professional B2B buyers — built the research case (32 interviews, gaze tracking, Baymard audit), secured executive buy-in for a platform-wide redesign, and led cross-functional execution across Design, Research, Product, and Engineering. You were building the research function across the US, Europe, and Southeast Asia. The case shows you creating organizational credibility for design through evidence, not through a pre-existing seat at the table.
The BCG Digital Ventures projects reinforce the pattern at venture speed. Equinox+: zero to MVP in three months, four designers and a researcher, multi-brand identity and omnichannel experience. Allē: dual-surface platform design — consumer app and provider back-office — with a design system built from scratch. American Red Cross: system consolidation under operational pressure. Each started without an established design practice and required you to define the process, set the quality bar, and ship.
TinyFish provides recent context for the same pattern in an AI-native environment — 0-to-1 in three months as Head of Product. Use it as a bridge to current technical depth, not as portfolio proof.
Recommended phrasing: "At Alibaba I created the mandate for a platform-wide redesign — built the research case, secured executive buy-in, and led cross-functional execution. At BCG Digital Ventures I led product design from blank canvas to shipped product across four ventures. My strongest pattern is creating organizational credibility for design through evidence and then building the team around the work."
That phrasing is specific, verifiable, and makes no overclaim. It describes what you built without inflating team sizes or implying reporting structures that the published record does not support.
If the screen is organizational steward
Confidence: use with caution. This is where you hit an honest boundary, and the right move is to name it before the evaluator finds it.
The Alibaba case shows you held the Head of Design & Research title for North America, described team scaling as part of your responsibility, and recruited for a cross-regional research organization. It does not document how many people reported to you, whether any of those reports were managers, or how many planning cycles you led. The BCG Digital Ventures projects show venture-team composition — one to four designers per project — not an organizational reporting tree.
I covered this boundary in the org-scaling gap dossier: the gap between function-builder evidence and organizational-steward evidence does not shrink with better phrasing. It sorts you into one pool or the other. Reframing around adjacent experience after the evaluator has asked twice erodes more credibility than the gap itself.
Recommended phrasing: "My record is strongest in building mandates and leading multidisciplinary product teams while staying close to the work. I haven't managed a 40-person org through multiple planning cycles, and I wouldn't claim that. What I bring instead is the ability to create a design function's credibility from scratch, ship under severe time constraints, and maintain hands-on technical depth in AI-native product design. If this role needs someone who has already run a large established org, I'm probably not the right fit — but if it needs someone who can build the practice and set the standard while the team grows around them, that's exactly what I've done."
Expand on that last point — technical depth in AI-native product design — if the evaluator asks. It means prototyping directly with language models, designing interaction patterns around model failure modes (when should the system ask versus act versus return control to the user), and making product-level judgment calls about AI behavior that require understanding what the model can and cannot do. Someone who has spent the last five years running a 40-person org has been solving organizational problems during the exact period when AI-native design practice was forming. That tradeoff is real, and it favors you in roles where the product surface is AI-driven.
State the boundary before the evaluator discovers it. A prior piece in this series established the principle: a confident senior operator names the limitation rather than spinning past it. The evaluator who hears you do that trusts everything else you say more.
When to stop reframing and qualify out
Confidence: high. Apply this when the conditions below are met.
Persistent questions about team size, reporting layers, or org-scale management are not always a perception gap you can close. Sometimes they are a genuine mismatch. The companion piece on when reframes fail covers the general principle. Here is how it applies to this objection specifically.
After two probes on the same dimension — team size, reporting depth, planning-cycle experience — where you have given your strongest honest answer and the evaluator returns to the question a third time, stop reframing. The evaluator is not waiting for better language. They are confirming a mismatch.
Switching to a different project that demonstrates the same evidence type will not help. The issue is the category of experience, not the example.
At that point:
"It sounds like this role needs someone with deeper experience managing at organizational scale than I have. I'd rather be honest about that than stretch my answer. If that's a requirement, I understand — and if there's flexibility on that dimension because the role also needs someone who can build from scratch and stay close to the work, I'd want to understand what that tradeoff looks like for you."
This stops the credibility drain. It gives the evaluator permission to either confirm the mismatch — saving everyone's time — or reveal that the requirement is softer than the question implied. That second outcome happens more often than you would expect, because hiring committees frequently disagree internally about what the role actually needs.
What the published record shows
Pull this up before a conversation.
Established in the published portfolio:
- Head of Design & Research title at Alibaba.com, North America
- Active hiring for a cross-regional research organization (US, Europe, Southeast Asia)
- Platform-wide redesign mandate created through original research, executive buy-in secured
- Cross-functional execution led across Design, Research, Product, Engineering
- Four 0-to-1 ventures at BCG Digital Ventures, teams of one to four designers each
- Recent AI-native product work at TinyFish (past tense, bridge context only)
Not established in the published portfolio:
- A specific Alibaba direct-report count
- Whether any Alibaba reports were managers
- How many planning cycles the Alibaba role spanned
- Formal reporting relationships on BCG DV project teams
- Managers-of-managers experience at any employer
One note on the homepage's "6 to 12 design team" figure. It sits above a career summary covering multiple employers and is not reliably attributable to Alibaba alone. Do not use it as an Alibaba-specific team-size claim. If you cannot attribute a number to a specific employer, do not use it — a number you can defend is more useful than a larger one you have to walk back.
The artifact gap and what to do about it right now
This objection is a hybrid. Part of it is a perception gap — your portfolio shows both IC craft decisions and leadership work, but evaluators scanning quickly may register only the organizational narrative (mandate creation, executive influence, cross-functional coordination) and miss the craft depth underneath. Part of it is an evidence gap — forward-looking visual design artifacts demonstrating IC craft at frontier complexity are not yet published. Until they are, the evidence architecture runs on three layers instead of four.
The Alibaba case does make your homepage, search, and product-detail design decisions inspectable. But the fastest proof of current craft depth — the kind that lets an evaluator see your hands-on judgment in thirty seconds — is not available from the portfolio alone.
Confidence: moderate. Every conversation where the IC question comes up requires you to narrate craft judgment verbally rather than showing it. That is a higher bar. Prepare two specific design decisions from your work before any conversation where this screen might be active. Pick one where you overrode an obvious pattern because the user context demanded it, and one where you chose constraint over flexibility. Walk through each at the interaction level — what the screen showed, what you changed, why, what happened. The evaluator screening for IC depth wants to hear you reason through a specific interface problem, not describe your philosophy about staying close to the work.
