The key thing I've learned this week is that safety really matters when it comes to difficult conversations, especially those involving multiple people, higher stakes, diverging opinions, and rising emotions.

What sometimes happens in such conversations is that the energy in the room goes sideways. People either fight to be heard, strong-elbowing their way into the conversation, or they retreat into silence and observation. None of that seems like a healthy contribution to the dialogue.

I'm starting to see the importance of focusing not just on the content of the discussion, but on the condition of the discussion itself. The book Crucial Conversations opened my eyes to how important it is to observe that safety. Many of the problems I see seem related to the absence of safety and the conditions where people feel free to speak honestly.

I'm beginning to see that one of the key conditions for safety is to have enough time and space for these conversations to unfold, along with a facilitator willing to observe that space. Last weekend, I unexpectedly found myself in a two-hour personal sharing circle. People shared their parenting struggles and the impact of parenting on their relationships. It took time for people to start feeling comfortable and for the discussion to unfold. After two hours, we had reached deeper levels. However, we were forced to stop, because the time was up.

Last week, I spoke to the CEO of a 200-person SaaS company. He shared that his leadership team struggles to take a step back from the daily whirlwind, to pause for a moment, and have a slower, more deliberate conversation about where the company is heading. There's a sense from the leadership that such discussions are inefficient because the time spent in the discussion isn't spent on solving urgent problems. The discussion doesn't feel like progress.

Perhaps that is true in the moment. But what we both agreed on is that those slower, deeper conversations, with the focus on safe expression of opinions, could prevent dozens of problems down the road.

When I face a complex project with many stakeholders, stakeholder mapping has been an indispensable practice over the years.

I typically map stakeholders in Miro. This example is an anonymized version from a project involving 20+ people across 3 companies.

When mapping, I try to capture the essentials: name, role, company, and any important context. I then cluster names by team and place high management at the top.

The mapping doesn't need to be complete, its purpose is to help me and the team to quickly navigate the stakeholder landscape.

When building something new, try starting with an embarrassingly simple UI wireframe. It doesn't have to be perfect, just trying to capture the bare functional minimum. The goal is to start cross-functional conversations as early as possible and get early feedback from the end user.

Such wireframes seem especially important if there's no UI/UX designer available, or if the designer doesn't have the capacity to understand the project in depth. The wireframe doesn't have to be started by a product manager or a frontender; a backender can do as well.

For the initial wireframe, I like google sheets. We can focus on functionality over form, and people are familiar with the tool. Also, we often already have a project-specific gsheet, so it's a natural fit.

Cross-functional discussions over the wireframe often open up interesting questions. Sometimes, the questions touch upon strategic choices about customer experience, the frontend stack, or the backend architecture. For example:

• This task is async on the backend. Do we notify customers async, or do we keep customers waiting for the result to appear on the page? What are the downsides of switching to sync? How are we handling async in other flows?
• Is our data model on the frontend/backend/db aligned with the domain language concepts we are working towards? Do we have all the data we need on the backend?
• How will we handle unhappy paths? What will we show the users? How do customer care agents currently handle async unhappy flows? What's their experience? How can we improve that?
• For internal projects: Would new colleagues understand the process if there's employee turnover?

All in all, wireframes seem like a cheap and fast way to help prevent surprises down the road and increase cross-functional alignment.