The Question Lars Can't Answer Alone

Lars calls a bigger session this time. Maya Rojas, Priya Sharma, Lars, Elena, David - the whole leadership team plus the two people who've been doing the diagnostic work. One question on the board: "What must Velox be better at than anyone else - permanently?"

Maya answers first, without hesitating. "Reporting. Our three largest enterprise accounts bought Velox because their CFOs make budget decisions off our dashboards." Lars nods, and answers next - a different answer, not an agreement. "Planning speed. How fast a team can replan when priorities shift - that's the thing our best customers actually notice week to week." Priya doesn't let either of them settle. "You're both right. But what keeps customers from churning is integrations. If we break the GitHub connector, we lose accounts - not eventually, that quarter." And then David, who Lars invited specifically because he's the one person who reads every support ticket that comes in: "I've read twelve months of support data. The one thing everyone tolerates but hates is notification noise. Nobody puts it in a sales call. Everyone complains about it in week three of onboarding."

Four people. Four answers. All four backed by real data, from a real part of the business each of them actually watches closely. And all four pointing the architecture in a different direction.

Lars writes nothing on the board. Elena closes her laptop without saying anything. David looks out the window.

Four people, four answers, all of them right

It's worth sitting in that silence for a second, because the instinct in most rooms like this is to treat it as a problem to fix quickly - someone picks an answer, the meeting moves on, the whiteboard gets a headline. Resist that instinct here, because what just happened is not a disagreement that better facilitation would resolve.

Look at what each answer is actually built on. Maya is looking at the deals that already closed - the CFOs who bought Velox specifically because of the dashboards. Lars is looking at what makes teams stick around once they're customers - the workflow speed that shows up in usage patterns, not in the sales deck. Priya is looking at churn risk - the specific, concrete thing that ends a contract if it breaks. David is looking at a part of the product nobody else in that room has read closely: a year of support tickets, where the actual daily friction lives, invisible to anyone who only looks at revenue and churn.

None of these four people are wrong about their own evidence. That's the uncomfortable part, and it's the whole reason this isn't a communication problem. If it were a communication problem, someone in that room would eventually say "oh, I see what you mean" and the four answers would converge. They don't converge, because each answer is genuinely, independently defensible - and each one implies a different place to invest the architecture's scarcest resource: careful design, dedicated ownership, the kind of boundary you can't cheaply redraw later.

[Diagram: lesson_00.3image1.svg]

four real answers pointing at one undecided center - that's not a communication gap

Why "what differentiates us" isn't an architecture question

Here's the thing that makes this moment different from everything in the last two lessons. The Pain Inventory and the AWG Charter were both, underneath the org-design language, things a working group with the right mandate could actually resolve on its own. This question isn't that. Reporting, planning speed, integrations, notifications - Lars can't pick between these with an architecture diagram, because the diagram isn't what's actually undecided. What's undecided is a product strategy question wearing an architecture costume: what is Velox actually betting its future on.

There's a trap sitting in the middle of this question worth naming now, even though you'll meet the full framework behind it properly in a couple of modules. Architects have a common habit of treating "what's core to us" as something you look up once - a fixed label you attach to a part of the system and then stop thinking about. Nick Tune's answer to that habit, from a DDD Europe keynote a few years back, is blunt: there are no generic domains. What looks safely commodity today - a notification system nobody puts in a sales pitch - is exactly the kind of thing that turns into the one capability you can't afford to get wrong, if the market moves somewhere nobody predicted. Tune has a name for the surprise version of this: a black swan core. Hold onto why that matters here specifically. It means David's answer isn't disqualified just because it sounds smaller than Maya's or Priya's. Notification noise being "the UX problem nobody talks about in sales calls" doesn't make it less strategic - it might just mean nobody's decided yet whether it's strategic, one way or the other. What counts as core at Velox is a decision this room hasn't made. It is not a fact waiting to be discovered by looking harder at the four answers already on the table.

The boundary that gets redrawn the moment it's inconvenient

Here's what's actually at stake if this room does what most rooms do next, and it's worth being blunt about it: this is the moment most architecture initiatives skip. They take the loudest answer in the room - usually the CTO's - and call it the Core Domain. Then they design around it. Six months later, when the boundaries make it hard for the Sales team to build the reporting feature the CFO asked for, the architectural decision gets reversed. Not because the architecture was wrong - because the strategy question was never answered.

Notice what that pattern actually costs. It isn't just wasted design time, though it's that too. It's that every boundary drawn on top of an unresolved strategy question is politically vulnerable in a very specific, very predictable way: the moment it becomes inconvenient for whoever didn't get their answer picked, it gets renegotiated - and the renegotiation looks like a technical dispute, when it's actually the original disagreement resurfacing under a different name. If Lars had picked "planning speed" today because he's the one holding the marker, and Maya's reporting feature hits a wall in Q3 because the boundary wasn't built for it, that fight doesn't stay contained to a design review. It goes straight back to the CEO, and the architecture team looks like it made the wrong call - when the real failure happened today, in this silence, by skipping past it instead of naming it.

What Lars writes when he has no answer

The room empties. Lars stays at the whiteboard. He leaves the four answers up - doesn't cross a single one out. Then, underneath all four, he writes something else, bigger than the rest of the board:

WHAT ARE WE?

Elena comes back in for something she forgot, reads the board on her way past. "We can't design the system before we know what the system is for." Lars, not turning around: "And we can't know what it's for until someone makes a decision - not a consensus. A decision." Elena nods. Leaves.

That's the right move, and it's worth being explicit about why, because it looks like Lars failed to do his job. He didn't force a decision through. He didn't pick the answer that would let the meeting end with a plan. What he did instead was harder: he documented the question as open, and as a blocker for everything downstream of it, instead of quietly picking one and hoping nobody notices the other three answers were never actually resolved.

You've been in this room. Maybe not this exact room - but you know the feeling. The architecture is clear in your head. The boundaries make sense on the whiteboard. And then someone asks a question that has nothing to do with architecture - and suddenly nothing holds. "What differentiates us?" "What must we protect at all costs?" "What can we buy instead of build?" If your leadership team doesn't share an answer, your architecture is temporary. Every boundary you draw will be renegotiated the moment it becomes politically inconvenient. The next modules give you a method - not to skip this question, but to make the answer stick in the architecture itself.

Further Reading

Exercise