Training Day

Psychological safety is an area that has had a lot of attention for some years. It is the most important of five characteristics that Google found in high-performing teams. Since they published that result, the amount of material and talks out there has just grown and grown, and it can be hard to get an overview. It can even be hard to tell the quality of the content. On regular basis, I see the misunderstanding that psychological safety is about feeling comfortable. And it is not.

Psychological safety is about feeling safe enough to try things out and speak up, to make mistakes and admit it. And in some situations, it is about feeling safe enough to be uncomfortable. For people to grow and learn, safety is a prerequisite (or makes it a lot easier).

It can be hard to understand what psychological safety actually means, and even harder to relate it the daily lives that we have. Because psychological safety is about how we feel, it can be many different things to different people. I have worked with psychological safety for over 8 years, and I am still learning all the time; come join me and start your learning journey :)

We will start the workshop by looking at definitions and discussing what that means to us, the people in the room. We will look into the difference between being safe and being comfortable, and try things out to get a good understanding.

Please be prepared to actively participate in group settings. This training will require your attention and contribution.

Most teams begin system design by describing features — feeds, notifications, dashboards. This feels fast and aligned. But beneath that surface, words carry different meanings, time and state remain implicit, and what looks like agreement often hides real misalignment.

In this hands-on workshop, we start with a simple, familiar design challenge and a set of feature ideas. Then we shift perspective — from outputs to structure.

• What capabilities must exist in the system?
• How are they related?
• What must remain true for the system to stay coherent over time?

Time and state are part of every modern system. Many familiar “features” are actually attempts to bridge gaps between these two realities — the system’s evolution and a person’s experience of it.

Participants will experience systems as evolving relationships, not just collections of features — and leave with a practical way to begin designing them that way.

This workshop builds on ideas from my book Learning Systems Thinking and my current work in progress Knowledge Flow. Architecting systems of software is my jam.

Participants will leave with:

• A concrete example of how to move from feature ideas to capability thinking
• Experience of how misalignment hides inside familiar terms
• A way to recognize when time and state are being handled implicitly (and causing problems)
• A simple modeling approach they can reuse to surface structure in design conversations
• A shared language for shifting discussions from “what should we build?” to “what must be true?”