Some engagements begin with a brief. This one began with a decommission notice.

The system processed a significant chunk of daily financial data. A risk management platform, wired deep into a legacy mainframe that was still very much alive, and very much a black box. Outside that mainframe sat a single overbloated component doing the work of several, holding the integration layer together through years of accumulated dependencies nobody had ever fully mapped.

Then the directive came down from the top. Decommission that component.

The mainframe kept running. The transition period that followed was supposed to be the space to find a replacement.
What it revealed, instead, was everything that had never been documented: dependencies spreading in every direction, functionalities duplicated across systems with no clear owner, and no clear answer to the question the decommission had quietly made urgent. What replaces that component without rewriting everything built around it?

I spent months going deep into the system. Then a workshop.
I walked in with three options. By the end of the meeting, option B was on the roadmap.

I had not made a decision.
I had only provided options.

What happened in that meeting

Option B meant nine months of work: redesigning the responsibility boundaries across the architecture, introducing an orchestration hub to coordinate between all parties, consolidating data that had been scattered across three separate parts of the architecture into a single source, adding a cache layer to ease the read load, and above all, keeping the legacy mainframe untouched throughout.
It was the middle option. Not the cheapest. Not the most ambitious. The one the room converged on because the framing made it the path of least resistance.

The room did not fail. Everyone there made a rational call from the options in front of them.
That is how this works: you shape the option space, step back, and the room decides.
The choice is theirs. The framing was mine.

If my framing drove that result, whose problem was it?

The comfortable alibi

Architects don’t decide. They frame options. This sounds like humility. It is, in practice, the most consequential act in the room.

When you define the option set, you define what is thinkable. The choices the room debates are the choices you put there. The ones they never consider are the ones you left out. Gregor Hohpe put it plainly:

Excessive complexity is nature’s punishment for organisations that are unable to make decisions.

The architect who frames the options shapes what is decidable. That is a decision upstream of the formal one.

Uncle Bob comes at it from a different angle:

The strategy is to leave as many options open as possible, for as long as possible.

Correct. But choosing which options to leave open, and which to foreclose, is where the real work happens. The framing is not neutral. It never was.

The alibi is comfortable because it is technically true. You did not sign off on the decision. You did not chair the meeting. You built the whiteboard. But the whiteboard was yours, and the room worked from it.

What staff++ won’t say

The industry did not ignore this tension. It promoted it.

Staff-plus, principal, distinguished: the IC ladder that scales your scope without granting you a reporting line.
The shorthand is “influence without authority,” which is a precise way of saying you are accountable for outcomes you cannot mandate. Will Larson’s staff++ architect “shapes an organisation’s technical direction.” Camille Fournier goes further:

You have to be the one who makes things happen, even when you have no authority to require others to do anything.

Both are describing leadership. Neither says so.

The role expanded from there. Cross-team alignment, technical strategy, stakeholder management: reasonable additions, in theory. In practice the architecture competed with the management-adjacent work for time, and the management-adjacent work usually won.
The core job became the thing you did when there was room. The problem is having the thing you were hired to do treated as the remainder.

The structural constraint is simple: staff++ is domain-scoped. A principal engineer in payments has no standing in identity, data, or infrastructure. In a small company, informal influence bridges those gaps. In a large organisation, domain boundaries harden and that bridge is not there.
Architecture is cross-domain by definition. The role provides depth inside a domain; the job requires reach across them.

The industry invented a career track built on four distinct archetypes : tech lead, architect, problem solver, right hand. Each a genuinely different operating mode. The title implied all four at once, loaded the role with cross-domain obligations it cannot structurally support, and called it influence. The architect operating inside this frame does not gain leverage. They absorb the incoherence.

The weight of the framing

The options you put in front of the room are the end of a private decision process, not the start of a shared one.

By the time you walk into that workshop, you have already made dozens of micro-decisions: what constraints to accept, what approaches are worth comparing, what the evaluation criteria should be, what is technically feasible given the time and team available. None of that is visible in the slide deck you walk in with.
The room sees three options. They do not see the options you ruled out before they arrived, or the assumptions that bounded the space.

Sébastien Page, in The Psychology of Leadership, writes:

In business, listening is a superpower.

The implication for architects is specific: the options you frame are only as good as the listening that preceded them.
If you misunderstood the team’s constraints, missed a dependency, or underweighted a risk, that gap is what you carry into the room. The room cannot correct for what they cannot see.

That gap is what the room decides from. Your reading of the system, not the system itself.

Page is blunter:

Don’t run your business like a democracy — be disagreeable, sometimes.

The architect who presents three options and watches the room converge on the wrong one, in silence, is not being neutral. They are abdicating.
You shaped the conditions that made the bad decision possible. The time to say “not that one” is before it lands on the roadmap.
After that, “I only provided options” is not a description of your role. It is an alibi.

The strongest objection to this argument is a fair one. Leadership without accountability is a real failure mode. The architect who accumulates informal influence and never owns the consequences is a genuine problem. I wrote about that pattern before. Critics like Camille Fournier are right that shadow leadership structures, where informal authority carries no formal accountability, corrode organisations.

Own the influence. Disclaiming it doesn’t make it go away.
You cannot shape every major technical decision and then step back from the results.
The framing was yours. The obligation that comes with it is yours too.

What claiming the framing actually means

Titles are beside the point. Nobody is asking architects to become managers.

Owning the framing means something specific: responsibility for the quality of the option space you put in front of people. For the rigour and intellectual honesty of what you hand the room to work from, not for the decision itself or every downstream consequence.

You built it. You own it.

That is the obligation. That is what accountability looks like when the authority is informal.

Call it leadership if you want. Architects already doing it.

The alibi held, technically.
I had not made a decision. I had spent months mapping a system nobody had fully understood, distilled it into three options, and stepped back when the room chose.
Call it neutral if you prefer. It is the most consequential part of the process, dressed up as advisory work.

That team did not need me to decide. They needed a better point of view and a nudge to decide well.

“I only provided options.” True. It is also how nine months of rework starts.