Matěj Kaninský's opening lecture changed how I read my own role as a designer. He named something I had been doing without noticing. Designers aren't here to deliver finished answers. We're here to create the conditions under which other people can find them.

The frame that stayed with me was his reading of design maturity. Organisations sit at different levels of it, and the most adult thing a designer can do is recognise where they actually are, not where they wish they were. Bringing an advanced solution into a low-maturity environment doesn't help. It alienates the team and burns the credibility you'll need later.

"A designer's first job isn't to bring answers. It's to hold the room while answers find their way out of it."

That sentence isn't a direct quote, but it's the standard the course set in my head

I noticed something uncomfortable about my own habits. I had been trained to arrive with overviews, metrics, frameworks, recommendations. Useful, when called for. But often the harder and more valuable work is the soft work. Holding space. Watching. Being patient. Letting the team's own maturity start to surface, rather than overwriting it with mine. Shortly after the lecture I had a chance to test this. I was running a workshop that was meant to be a UI revision. Instead of phasing it the way I normally would, I opened with a long mapping exercise where we just named problems, without sorting or solving. The room was uncomfortable for the first twenty minutes. Then it shifted. The discussion that came out wasn't polished, but it was real. The output came from people who actually used the product, not from my facilitation logic. I learned something about resistance there. The discomfort wasn't a sign the method was wrong. It was the cost of not jumping to structure too early.

The course also ran as a team project, mostly asynchronous, mapped collaboratively in Miro. I gravitated toward organising the structure, proposing frameworks, connecting topics. What I didn't always get back was clear feedback. Did people accept what I'd added? Reject it? Just not see it? That ambiguity became the second thing I had to think about.

It changed how I see facilitation in everyday team settings. It doesn't have to be a formal role. It's the small acts of holding direction. Asking where we are. Summarising. Naming what's unclear. When someone in our group naturally took that role, the team moved more smoothly. When no one did, we drifted.

I also started noticing psychological safety differently. Our team had it on the surface, an open and respectful atmosphere, no one pushing or judging. But that informality also created room for quiet disengagement. Safety isn't built once. It has to be actively maintained, by feedback, by genuine interest in others' opinions, by visible appreciation. Otherwise it becomes politeness without participation.

A few principles I want to actually apply, not just nod at.

Read the design maturity of the environment I'm working in, and adapt the role I play to fit it.

Cultivate the facilitator stance over the solver stance, especially in moments when offering an answer would feel productive but actually closes the conversation.

Hold uncertainty as part of the process instead of trying to resolve it too quickly.

Use short reflections after key meetings or workshops, not just to capture what was said, but to track how the team's thinking is evolving over time.

The deeper realisation is the one Matěj kept returning to. Useful designers aren't the fastest or the most polished. They're the ones who can read the context, support other people's growth, and stay present in the moments when something is actually changing. That's the standard I want to keep working toward.