Given two teams (or companies or individuals), we can ask what is their mode of interaction? Are teams collaborating? Is one team providing X-as-a-service? Is one team coaching or facilitating another? Or is the interaction fuzzy and undefined? These modes lead to different modes of ownership and expectations.

For example, if Team A provides X-as-a-service to Team B, Team B can expect certain quality, up-to-date, and usable documentation, as well as access to knowledge-sharing sessions on new topics. Team A also likely owns the artifacts and documentation, and expects Team B to follow the prescribed way. All with the aim of lowering context load and achieving a more sustainable flow for Team B.

On the contrary, if teams are expected to collaborate, the context load for both teams increases. The cost of extra context load then needs to be weighed against the benefits of collaboration. Current context load needs to be considered as well; what if it’s already too high? In collaboration, artifacts are likely co-owned, and expectations revolve around engagement.

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.

We started by clarifying what he truly wants for himself. He realized that what matters most is clarity about the process. He cares less about the outcome itself and more about understanding where things stand and what to expect.

Next, we explored what he wants in terms of the relationship with his manager. We identified that he doesn't want to come across as pushy or overly eager towards the manager.

We then examined the interpretation he had formed around the situation. He had begun to conclude that there might be malicious intent behind the delay. By looking more closely at the facts, we identified that there could be several alternative explanations, and that his initial interpretation was one of the possible narratives.

Finally, we discussed which communication channel would work best. He chose to draft his message in writing first, based on our exploration, giving himself the space to articulate his thoughts clearly. He will then follow by a one-on-one conversation to continue the discussion in person.

While there are many dynamics at play, there are three that have become clearer to me.

First, criteria. Criteria for decision-making might not be clear, or there might be no intention to clarify the criteria. If that's the case, people tasked with exploration may invest effort, enthusiasm, and energy in things that don't actually add value to the decision. That can be deeply frustrating: people want to contribute, yet see their work effectively go to waste.

Second, authority and hierarchy. There could be someone in the group who has a higher position and is, in reality, the decision-maker. If this person has already made a decision on part of the problem, but communicates the whole process as collaborative and democratic, it can create confusion. People might assume the process is egalitarian and that they can democratically steer the outcome, when in fact they cannot. It seems healthier to acknowledge these roles explicitly, so the group can support the decision-maker by filling in gaps where they actually matter.

Third, consolidation. Many people seem to appreciate consolidation, that is, higher-level summaries of what a group has learned so far. I think this is because people value big-picture clarity. With the big picture, people can better orient themselves in the problem space, see the next steps and also see how their effort contributes to the overall effort.

Some questions one can ask:

1. Criteria: Are people aligned on the decision criteria? Do people interpret the criteria, and their weights, in the same way?

2. Decision ownership: Is there an implicit owner of the decision? How is that role recognized within the group? How are decisions and remaining open points communicated back to everyone?

3. Consolidation: Is learning being consolidated and summarized at a high level?

Decisions often need to be made quickly or with limited information. However, one-sided decision-making could cloud the fuzzy, complex reality we actually live in. That cloud often leads to extra effort needed to achieve success. It can even actively undermine success.

Acknowledging at least one honest downside in a proposal can help to see the reality more clearly.

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.

1. What's the intended outcome?

2. How can success be observed/measured?

After that, mentally let go of the output you were working on. (This detachment could be hard.) Instead, look into the measure and try to identify the best opportunities to achieve success. Choose the best opportunity and execute it. Afterwards, validate if the opportunity has moved the measure as intended.

Going through these steps, you might run into issues, such as:

• There are multiple outcomes we are after, which one to choose?

• How to measure something intangible?

• What if the opportunity will positively impact one metric, but negatively impact another metric?

• We currently don't have anything to measure this or see where the opportunities are.

• The measures are out of our team's control.

• Is this outcome something we want to focus on right now?

This newly gained unclarity is valuable. You have just turned unknown unknown into a known unknown.

I have found these steps to be generally applicable, from low-level engineering work to higher-level business decisions.

1. Write down the problem or question you’re facing

2. Try to understand the underlying need

3. Brainstorm approaches to address that need (at least two)

4. Write down what you think about each approach

5. If the problem is difficult or complex, introduce more structure: define criteria, then evaluate each approach against those criteria

Example: How should we do estimates: fibonacci, t-shirt sizing?

Many teams discuss on the level of this question, but we first need to ask something else: What underlying need are we actually trying to address here? It could be something like:

• Predictability for the business?

• Engineers aligning on scope and approach?

• A requirement to follow a given process?

• Something else we’re not seeing yet?

These discussions often feel like stepping into the unknown, which can be uncomfortable. Some people tend to rush through.

So let’s say it’s predictability, and we choose not to explore that need further. How can we make the work more predictable? Some approaches:

1. Point estimates: might still be too micro-level to be truly predictable?

2. Fixed project time (e.g., 6-week cycles like Shape Up): requires the ability to adjust scope accordingly

3. Continuous evaluation: requires incremental delivery and ongoing alignment with the business

4. No change, keep doing what we’re doing: maybe suitable if there’s too much other stuff going on right now?

5. Something else?

Capturing this thinking and decision-making process in writing or in a diagram can be helpful as well.

When you make a decision after this kind of exploration, you’ll likely have a clearer understanding of both the problem you’re trying to solve and the solution space. As a result, the choice you make is likely to be stronger.

Miro board from the video is here.

I recently spoke with a product owner about his experiences working with engineers who are also focused on outcomes rather than just delivering requested features. Here's what he shared:

"When engineers focus on the outcome, I find myself trusting them more with technical decisions."

"Focusing on outcomes opens up new opportunities and ideas. The outcome is the key to having discussions about solutions."

"I love discussing outcomes with engineers because they simply have a different perspective than I do."

"I can create tickets for all these ideas, and then we'd have to discuss them. But then an engineer looks at it and thinks: I can fix this in half an hour. These everyday low-hanging fruits are really valuable."

The role of a product owner, as we know it, is to serve as the exclusive conduit of business value between IT and the business. But what if that model isn't working as well anymore?

Here's an excerpt from Mark Schwartz's The Art of Business Value on the topic.

Many people see customer-centricity as being about external customers, that is, the people who pay money for the services. But it turns out there are other types of customers as well. In our exploration, it turned out the team was doing work for four different types of customers:

1. paying customers

2. internal ops (customer care, finance, etc.)

3. other engineering teams

4. the team itself (improving efficiency, speeding up onboarding, etc.)

(Although not technically a customer, we included the team itself as well, because a lot of energy has been put into improving the team's way of working.)

We went further in the exploration:

• Who's driving value for which customer type?

• Does the team want to serve all these customer types?

• Who's responsible for measuring impact for the different customer types?

Understanding who the customer is seems to have given the lead more clarity, particularly about responsibilities, roles, and the team's focus.

• Invoice status synced in two cloud systems

• Code ownership defined in two places

• Customer data living in two systems

Some inconsistencies are ok, some are not. Without clarity on the required degree of consistency, you might find yourself in confusing situations.

If inconsistencies are not ok, then you might need two things:

1. Measuring the degree of inconsistency

2. Ensuring the inconsistency stays within an acceptance range.

Once you open up to the possibility of measuring inconsistency, you might find that measuring could be straightforward. For example:

• A SQL query across two dbs that have already been ETLed to the shared data analytics db

• A script in the CI/CD pipeline scanning for code ownership

Having the measurement at hand also helps communicating your technical work to your non-technical colleagues, who now have a better overview of the problem.

But again, it could be that inconsistencies are ok. Inconsistencies might have low business impact, or the systems are planned to be replaced with something else.

As with other things, you might benefit from understanding the surrounding technical and business context to choose the right action and the level of consistency that is acceptable to your particular situation.

In engineering, things often seem impossible to measure. Especially the soft, intangible things. But if something is valuable, it should be observable in some way.

After this book, I started asking much more: how can we observe the success we are after? (Which often opens the question of what success actually is.) And then trying to incrementally find a way to capture that observation into a measurement.

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.

What are the subjects of your sentences? Underline the subjects of your sentences and ask yourself if they match what the reader is interested in.

Does this translate to engineering work as well? When we work, what are the subjects of our daily discussions? Are the subjects things like: “ticket”, “sprint”, “points”, “goal”, “review”? Or are they more like: “customer”, “error”, “decrease”, “bet”?

Could it be that the subjects of our sentences signal what we actually value and what we optimize for in our work?