After four years of managing designers, I realised the question I kept asking was the wrong one.
Every manager asks some version of it. In one-on-ones, in performance reviews, in the quiet conversations after a project wraps. What do you want to improve? Where do you feel you have gaps? What skills do you want to develop?
The answers are almost always the same: communication, presentation, confidence. Sometimes technical skills. Occasionally something more specific. And then the next project begins, the same patterns resurface, and six months later you're having the same conversation with the same person about the same gap.
The problem isn't that people are being dishonest. It's that they genuinely don't know. The skills they think they're missing are often the visible symptoms of something else entirely — something that only becomes clear when you put them in a situation designed to surface it.
What Colleagues See That the Team Can't
The feedback that finally pushed me to change my approach didn't come from my team. It came from the people around them.
Peers, cross-functional collaborators, people who worked with my designers in meetings and reviews. The pattern in what they said was consistent: your team is great at execution. Strong UI, strong UX. But they're silent in rooms. They're underconfident in front of clients. They don't question things the way you do. When it comes to product thinking, systems thinking, problem framing — those terms get used, but nobody knows how to actually build them.
This is the gap that doesn't show up on a KPI. You can define a designer's role requirements, set standards, measure output quality. But the soft skills that determine how someone operates in a room — how they read what's happening, how they question without hesitation, how they frame a problem before jumping to a solution — these are necessities that can't be mandated. You expect people to grow into them. And without intervention, many don't.
The Activity That Changed Everything
Before I could build workshops around specific skills, I needed my team to understand for themselves why those skills mattered. Not because I told them to. Because they had arrived at the conclusion themselves.
I sat the team down and ran a simple three-step activity.
Step one: quickly list everything you currently do as a product designer in this organisation. Not what you should do — what you actually do, today, in this role.
Step two: list what a product designer should be doing. Ideally. At the level the role demands.
Step three: together, categorise everything across both lists into buckets. Group the responsibilities, find the patterns, name the categories that emerge.
What came out of that exercise wasn't a list I had prepared. It was four or five categories that my team had identified themselves — the actual shape of the role as they understood it, with the gaps between what they were doing and what they believed the role required made visible without anyone having to say it to them directly.
From those categories, we built their roles and responsibilities together. Not imposed from above. Co-created from the inside. And because they had suggested the framework themselves, they connected with it differently. They could see where they were contributing. They could see where they weren't. And they wanted to close that gap — not because a manager had told them to, but because they had named it themselves.
The Four Skills I Was Actually Building Toward
Once I knew what the real gaps were, I could design the workshops around them. Not generic skills training. Four specific capabilities that I kept seeing fail in real rooms, in real meetings, in real client calls.
Systems thinking: the ability to see the whole before you design the part. To ask how this connects to everything else, what breaks if this piece disappears, what the failure modes are before they become client problems.
Storytelling: not presentation polish, not slide design. The ability to set up a problem before offering a solution. To make a room feel what's at stake before you reveal what you've built.
Observation: reading what's happening underneath a conversation. What the frustration in someone's tone actually means. What the question asked twice is really asking. What the silence after a demo is telling you.
Questioning: the confidence to pause a room. To say — before we go further, I want to make sure I understand what's being asked. To not leave a meeting carrying a confusion you never named out loud.
My team felt underconfident about all four. Not because they lacked ability. Because they'd never been given a structured opportunity to practise them away from the pressure of actual work. They'd sit in a client call thinking: maybe I don't have enough context to question this. Maybe my suggestion is too basic. Maybe I'll ask my manager afterwards.
That's what the workshops were trying to fix. Not through theory — I could have shared a framework document, a link to an article. But through practice. Doing the thing in a low-stakes environment until it becomes a habit that survives a high-stakes one.
The Person Who Thought They Couldn't Present
The most useful thing workshops surface isn't what people know. It's the gap between what they think their weakness is and what it actually is.
One person on my team came into the storytelling session believing they struggled with presenting. They were anxious about it. They'd been anxious about it in every review, every meeting, every client call. It was the thing they most wanted to improve.
They gave the best presentation in the entire workshop.
They opened with a question to the room — raise your hand if you've ever experienced this — and every hand went up. Crisp, structured, scripted just enough to be confident without being rigid. The S3 method executed with more clarity than anyone else in the session.
Presentation was not their gap. It never had been.
Their real gap — the thing the timed activities revealed — was on-the-fly thinking. Give them preparation time and they were exceptional. Put them in an impromptu situation with five minutes and no structure and the quality dropped significantly. The speed of thinking under pressure, the ability to represent thoughts coherently without having first arranged them — that was where they were actually falling short.
This matters because if I had taken their self-assessment at face value and focused our work on presentation skills, I would have spent months improving something that didn't need improving. The workshop told the truth. The self-assessment told a story.
What Pressure Reveals
The activities I've found most diagnostic are the timed ones. Give someone five minutes to build a system. Give a team fifteen minutes to build one together. Watch what happens when the clock is running and the stakes feel real even in a room with no clients, no consequences, no deliverable that matters.
Under pressure, the masks come off. The person who always seems confident in reviews goes quiet when they have to think out loud without preparation. The person who seems hesitant in daily work suddenly takes charge because the constraint has created clarity. The person who can carry a story beautifully in their own presentation stumbles the moment they have to pick up where someone else stopped.
These are the real data points. Not the portfolio. Not the performance review. The five-minute clock.
On Feedback After the Fact
I changed how I give feedback after running these workshops. Not softer — sharper. More specific, more direct, more focused on the process than the output.
Your story felt shallow there. That was the moment to lead on systems thinking and you stepped back. You didn't question them in that room and you had every reason to.
And then, always: what was your observation in that moment? What did you notice? What stopped you?
Because the feedback isn't the end of the conversation. The reflection after the feedback is where the actual learning happens. In biweekly check-ins, after client calls, after reviews that went sideways — I ask the same questions repeatedly. Not to make people feel they failed. To make them the observer of their own behaviour rather than just the subject of mine.
The goal is not quality of output. Quality of output is an outcome. What I'm trying to build is quality of process — the method, the style, the instinct that a designer carries from one project to the next. That's what stays. That's what grows.
For the Leader Who Says They Don't Have Time
The most common response I hear when I describe this approach is: I don't have time to run workshops. I give feedback in reviews. That's enough.
It isn't. And I say that with full awareness of how much a design leader's calendar costs.
Feedback in reviews is feedback on work that has already happened. It's retrospective. It prepares your team for the last project, not the next one. And it is almost always filtered through the work itself — which means you're commenting on output, not on the thinking and behaviour that produced it.
Workshops do something different. Because you designed the activity, you can curate it — the same challenge for everyone, but the topic chosen to push each person toward the specific gap you've identified in them. You can watch how they think without the noise of a real deliverable obscuring the signal. And you can remove your own biases: the assumptions you've formed about who is good at what, assumptions that are often just patterns from past work rather than a true picture of current capability.
There's also something that happens when the team realises you've invested this kind of time and thought in their development. Not a team-building exercise. Not a mandatory training. A session built specifically for the gaps in this team, run by the person who knows those gaps best, in a room that feels safe enough to expose them.
If I had been given this kind of guidance earlier in my own career — a manager who designed learning experiences around my actual gaps rather than the ones I reported — it would have changed things. The fear that most designers carry in startup environments — the fear of speaking in a room with high stakes, of failing publicly, of not being confident enough — that fear doesn't go away because someone tells you they have your back. It goes away because you've practised the thing you're afraid of in a room where it was safe to get it wrong.
That's what you're building. Not a workshop. A team that trusts itself.