Skip to content
On this page

Technical Leadership: Ownership Starts Before the Decision

Technical Leadership: Ownership Starts Before the DecisionAI-generated image

For a while, I treated information flow mainly as a communication problem. When something important happened in an architecture, operations, or cross-team discussion, I tried to make sure the relevant people heard about it afterward. I summarized decisions, shared links, and added notes where they could be found later. That helped with transparency, but I started to notice a limitation in this approach.

The people receiving the summary knew what had been decided. They had seen much less of how the decision had been reached.

See How the Decision Is Made

That difference became clearer when I began opening some of those discussions to colleagues who would normally only receive the outcome. Instead of always carrying the context back into the team myself, I shared where certain conversations were happening and invited people to join when the topic was relevant to their work. A few did.

What interested me was the kind of information that becomes available when someone is present before a decision is compressed into a summary. They hear which constraints matter, which options were considered, where uncertainty remains, and why one concern received more attention than another. They also see who owns which part of the system and where to go when a similar question appears later.

A written summary can capture the result and some of the reasoning. It rarely captures all of the judgment that produced it.

From Information to Independence

This has changed how I think about enablement. If I repeatedly attend the important conversations and then redistribute the conclusions, I can unintentionally become part of the dependency structure. People may have access to the information they need today while still depending on me to obtain the context they will need tomorrow.

There are practical limits, of course. Inviting everyone to every meeting would create noise and consume time. The useful question is more specific: who would benefit from seeing this type of decision being made because they are likely to face similar decisions themselves?

That question changes the purpose of an invitation. The aim is to bring people close enough to the reasoning, the constraints, the relationships, and the trade-offs that they can start building the context on their own instead of waiting for me to hand it to them. It is the same instinct behind How Google Works, where sharing information widely is treated as a leadership responsibility rather than a favor.

Involve People While the Context Is Forming

I have also become more careful about involving people early enough. An invitation after the important assumptions have already been established gives someone access to the conversation, but only partially. When I know that a person will eventually need to act independently in that area, bringing them into the context while it is still forming is often more useful.

Watching a decision form: the signals, options, and trade-offs become visible before the summary is writtenAI-generated image

A small experiment I now find valuable is to look at one recurring meeting where I regularly carry information back to others. Before the next session, I ask who should occasionally be in that room themselves because the context would help them make better decisions later.

The Question I Now Ask

Where in your own work are you still acting as the main carrier of context, and who could become more independent if they could see how that context is created?

That shift did create another question for me, one I take up in a follow-up piece: what happens when someone decides the opportunity I created is not useful to them?

I am curious how others handle this. Do you invite people in while the context is still forming, or do you share the polished result? Share your thoughts in the comments or reach out directly.

I read every response.