Who Owns the Problem?

Lars has the Pain Inventory taped to the wall from the last session - nine items, each tagged Code Problem or Structural Problem, three of them circled twice. He doesn't sit down. "We know what's broken. Now: who decides what we do about it?"

Elena starts to answer. Domain boundaries, team restructuring, a phased plan for splitting the monolith - she's three sentences into an architectural answer before Lars stops her.

"No. Who has the authority to make decisions that change how teams are structured, what they own, and how they interact with each other?"

Silence. It's a fair question, and it's not one an architect can answer by drawing a better diagram.

Priya Sharma walks in - invited, running late. She reads the wall on her way to a chair. "Half of these are my problems too. Engineering, not architecture." Lars nods. "That's why you're here." He picks the marker back up and writes two words on the board, big enough to read from the door: MANDATE. SCOPE.

Why architecture initiatives stall without one

There's a pattern here worth naming before you get anywhere near a single boundary decision, because it's the pattern that kills architecture initiatives before the architecture is even wrong. It shows up three ways, and you've probably seen at least one of them.

The first is political resistance that never announces itself as resistance. A team gets told its API surface is changing, or its ownership boundary is shrinking, and nobody on that team had a vote in the decision - so compliance is slow, half-hearted, or quietly reinterpreted. Nobody says no. The change just never quite finishes landing.

The second is the conversation that never converges. Without someone in the room whose word settles a disagreement, every design meeting reopens the same debate, because there's no cost to reopening it - no decision has actually been made, only discussed. Weeks pass. The whiteboard gets photographed and forgotten.

The third is the quietest and the most expensive: good architecture that nobody implements. An architect - a strong one - produces a genuinely sound design. It sits in a document. Teams keep building the way they were building, because nobody with the standing to reprioritize their roadmap ever told them to. The design wasn't wrong. It was ownerless.

All three failure modes share the same missing ingredient. It isn't a better framework or a smarter architect. It's an answer to Lars's actual question: who, specifically, can make this decision stick.

What actually belongs inside a mandate

A mandate isn't a mission statement, and it isn't a slide that says "empowered team." It's four specific things, and an Architecture Working Group is only as real as the weakest one of them.

Scope - what the AWG can decide on its own, without asking anyone's permission first. Not everything architectural belongs here. Scope is a boundary, and a mandate that doesn't say what's outside it is not a mandate; it's an invitation to relitigate the boundary every time someone doesn't like a decision.

Decision rights - which calls need a leadership sign-off before they're final, and which ones the AWG can simply make. This is the part people skip, because it feels like it's slowing things down. It's the opposite: a decision right that's explicit is a decision that doesn't get reopened three weeks later by someone who wasn't in the room.

Stakeholder representation - who has to be at the table for a decision to hold once it leaves the room. This is exactly what just happened with Priya. Half the Pain Inventory belongs to Engineering, not Architecture - so an AWG without Priya in it can produce a technically sound answer that Engineering has every reason to treat as somebody else's opinion.

Timeframe - how long this mandate runs before it's reviewed, renewed, or closed. Without one, an AWG either drags on past its usefulness or dissolves the moment attention moves elsewhere, with no clean handoff either way.

What Lars is doing at the whiteboard is not architecture. It's the precondition for architecture to matter. He's following something close to what Stephen Bungay calls the difference between an order and an intent: he isn't telling Elena and David what to design - that would be micromanaging a decision that isn't his to make in detail. He's establishing the direction (an architecture that lets teams ship independently, driven by the leadership team's decision to pursue an Inverse Conway Maneuver - designing the team structure around the architecture you want, not around the architecture you have) and then deliberately staying out of the how. Elena and David lead the technical reasoning; Lars translates between the leadership team that granted this mandate and the working group executing it. That's worth sitting with, because it's the opposite of what a lot of architecture initiatives look like in practice - usually it's the most senior technical voice in the room making every call. Here, the most senior person in the room is the one making the fewest technical decisions and the most governance ones.

There's a reason inclusion matters as much as authority here, and it isn't about being nice. Manns and Rising catalogued this pattern across dozens of real change efforts in Fearless Change: initiatives that get imposed from above - even correct ones - tend to get quietly slow-walked by the people who had no say in them. Elena and David aren't in this room to nod along with Lars's plan. They're here to lead the technical reasoning that Lars, deliberately, isn't doing himself.

One piece of context worth being precise about, because it changes everything downstream: the AWG isn't starting from zero convincing. The decision to pursue an Inverse Conway Maneuver was made by Velox's leadership team - Maya, Lars, Priya, and Kai together - before this working group ever existed. The AWG's job is to execute that decision, not to build the case for it from scratch. That's a very different starting position from an architect walking into a room trying to convince skeptical leadership that restructuring is worth the disruption. Hold onto that distinction. It matters for what comes next.

[Diagram: lesson_00.2image1.svg]

the mandate isn't what the awg can do - it's the line around what it can't

The mandate Velox already has - and the one most organizations don't

Here's the honest complication, and it's worth naming directly rather than letting the exercise below imply there's one correct AWG Charter template: what a valid mandate looks like depends on your organization, and it depends on it in ways that aren't cosmetic.

Three variables do most of the work. How much trust does the CTO have with the CEO - because that trust is what lets Lars walk into this room with real authority instead of a title and a hope. How much authority does engineering actually have over team structure - in some organizations, that decision sits with HR or with a VP of Engineering who isn't in this conversation at all, and no charter fixes that gap. And whether the organization is in a political moment where any restructuring reads as a threat - a mandate that would sail through in a calm quarter can become radioactive during a reorg rumor or a rough earnings call.

Here's what that means for you, concretely, not just as diagnosis. If CTO-CEO trust is thin, don't open with a mandate that asks for people-moves and reporting-line changes - charter something narrower, deliver one decision that holds, and expand the mandate once it's proven rather than once it's argued for. If engineering doesn't actually own team structure where you work, your charter's Decision Rights section needs an explicit row naming whoever does - a charter that pretends otherwise isn't a boundary, it's a fiction that gets exposed the first time a decision needs to move a person. And if the organization is mid-reorg-rumor or just missed a number, the thing to delay is the mandate conversation itself, before the architecture - a mandate granted in a defensive crouch gets quietly rescinded the same way it was quietly granted.

Lars has it relatively easy at Velox, and it's worth being honest about why: the leadership team already agreed on the direction before this meeting happened. In a lot of organizations, that agreement is the hardest part of the entire initiative - harder than any boundary decision this course will teach you to make - and it can take longer to establish than the architecture itself. If you're doing this in your own organization and the leadership alignment isn't already there, the charter exercise below won't create it for you. It will, at least, force you to write down exactly what's missing.

Further Reading

Exercise