Your job as a senior leader isn’t always to make decisions — it’s knowing when to make them and when to ensure others do. People talk about ’empowerment’ all the time, but empowerment without context is just abdication. Empowerment with control is just micromanagement wearing a friendly T-shirt. What actually works is giving smart, senior people the right information and guidelines at the right altitude, then getting out of their way.
The difference matters. Control is top-down and creates bottlenecks. Context can be distributed and creates autonomy.
The Context: What It Actually Means
When I say “context,” I don’t mean dumping every slide deck, spreadsheet, and executive thought fragment into an engineer’s lap. Context is about giving people the right information: strategy, priorities, market forces, constraints, expectations, etc, and then trusting them to act accordingly. Context is not control. Control is telling them the answer. Control is believing your job is to be the smartest person in the room. Control is thinking you’re protecting the company by limiting decisions to a small circle at the top. You cannot scale people.
The Framework: What Decisions Get Made Where
Every leader is different, and you need to be explicit about the boundary between decisions you want to be involved in and decisions you expect people to handle autonomously.
Here’s mine:
- Make it yourself if the decision is low-risk and clearly in your domain.
- Bring it to your manager or the RFC process if it affects multiple teams or creates new constraints for other people.
- Bring it to the Global Architecture Meeting if it affects company-wide engineering architecture, product direction/strategy, or revenue risk.
- When you’re unsure, ask.
That’s it. Simple (ish) guidelines, not a flowchart.
The boundary won’t be universal. It depends on you, your organization, your people, and experience levels. But it all must be clear — or at least consistently heading toward clarity. Ambiguity creates bottlenecks (people escalate everything) or chaos (people guess wrong about what needed input). The reality is that people generally aren’t blocked because they lack a framework. They’re blocked because they’re worried they’ll make the wrong choice and get beat up for it. That’s why the framework only works if you’ve done the psychological safety work first.
The Psychology: Creating Safety
I sit in most architecture meetings, but not to run them. I’m there to help ensure that the right voices are heard, not always the same voices. I’m also there to ensure psychological safety exists and people feel comfortable to ask “stupid questions” or speak up. People need to be able to disagree without getting shot down in unconstructive ways. Early on, you have to actively reinforce this. You interrupt bad patterns. You model good disagreement and healthy, constructive conversation. You make it clear that “I don’t think that will work” requires explaining why, not just asserting superiority. The more consistently you do this, the less you need to intervene. The culture reinforces itself. But it requires active maintenance, especially as new people join.
What This Looks Like
We run a weekly Global Architecture Meeting where team leads present RFCs and discuss the implications. Everyone brings their expertise. We talk through pros, cons, and what moving forward actually means for the teams, the company and the overall strategy.
We record these meetings and document outcomes in the RFCs themselves. We share the recordings and other engineers can watch the discussions and even weigh in afterwards. This is how transparency and collaborative decision making works in practice. This helps people structure their thinking, improves how engineers communicate complex ideas, and ensures the democratization of information.
Our Monthly Town Halls complement this. We share product and technical strategy with the wider organization including some of the RFCs, decisions made in meetings, and updates to the “context items” like strategy, priorities, constraints, etc. Everyone gets the same baseline context about where we’re going, why, and what might have changed. This level of repetition is about ensuring the people making decisions have the information they need and the practice communicating it. Strategy isn’t strategy unless repeated.
Why This Works
This approach produces real outcomes:
- Better decisions and Fewer Bottlenecks: More brainpower applied to hard or important problems. Senior engineers often catch implications that wouldn’t surface in a top-down mandate.
- People Development: Watching senior engineers work through complex trade-offs is how other engineers learn to think at that level. Participating in these discussions builds judgment.
- Retention: Good people stay when they’re empowered to make meaningful decisions and see their input actually matter.
What This Requires From You
This is where things can get difficult. You have to be comfortable with decisions you wouldn’t have made yourself. If you trust people with context but then override them when they use it differently than you would, you’re not actually trusting them. You need to give them the goals/outputs and then let them get you (and everyone else) to that point. You have to invest in creating that context. Town Halls, recorded meetings, documented decisions — this takes time, effort, and most importantly practice. You’re trading your time for distributed decision-making capability.
You have to actively maintain psychological safety. It doesn’t just happen because you want it to. You have to be clear about the boundaries. Your senior people need to know what you expect them to decide and what requires broader input or signoffs.
The Alternative
The alternative is being the bottleneck. Every decision flows through you. You become the constraint on your organization’s ability to move quickly. Or worse, people make decisions without context and you spend your time fixing the cascading problems. Context isn’t easier than control, but it scales. And it builds the kind of organization where talented people actually want to work and feel empowered to deliver.
If you want senior engineers actively involved in business-critical decisions, the answer isn’t fancy processes or reinvented org charts. It’s communication. It’s context. It’s repetition. It’s trust. Give people the information they need, the guardrails to make good calls, and the psychological safety to use their judgment. Then be there for the support and reinforcement of a job well done.
—
