Stating Your Boundaries

Overview

Module 1 claimed that the charter’s what I will not decide section carries the weight. This topic explains the mechanism, because the claim sounds like modesty and is actually about credibility.

Stating the limits of your responsibility increases trust rather than reducing it.

Four reasons, and then the instrument that makes it practical.

Why a bounded claim is more credible

An unbounded claim is not believable. Someone who implies competence across everything — architecture, product, security, the monolith’s internals, the support team’s workflow — is judged as competent at nothing in particular. Breadth without edges reads as a lack of depth anywhere.

Boundaries make your agreement worth something. If you have a strong opinion about every decision, your opinion about any one of them is cheap. Scarcity is what gives a judgement weight, and a stated boundary creates it honestly.

It removes a threat. Engineers resist an architect who might take their autonomy, and that resistance is the quiet-sabotage risk from Section 2. A written boundary is a guarantee rather than a reassurance, which is why Module 1 put I do not choose which libraries teams use; I set the constraints they must satisfy in the charter.

It is checkable. A boundary is a claim people can verify you against. Keeping it builds exactly the consistency the previous topic identified as a trust mechanism — and breaking it costs you twice, because you have both overreached and broken a stated commitment.

Three useful forms of “I don’t know”

The instrument. Each form does different work, and knowing which to reach for is most of the skill.

graph TD
  A["<b>'I don't know —<br/>I'll find out by Thursday'</b><br/><i>the default</i>"] --> D["Credibility<br/>rises"]
  B["<b>'Not mine to know —<br/>X owns that'</b><br/><i>the boundary</i>"] --> D
  C["<b>'Nobody knows. Here is the<br/>uncertainty and what would<br/>resolve it'</b><br/><i>the strongest</i>"] --> D
  E["<b>A confident guess</b>"] --> F["Credibility falls<br/>when checked"]

  classDef good fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef best fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef bad fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A,B good
  class C best
  class D good
  class E,F bad

Three admissions and one guess. The guess is the only option that feels better in the room and the only one that costs you afterwards.

“I don’t know — I will find out by Thursday.” The default, and it works because it converts an admission into a commitment with a date. The thing that makes it credible is delivering on Thursday.

“That is not mine to know; X owns it.” The boundary form. It does two things at once: it declines the question and it tells the asker who to ask, which is useful rather than obstructive. It also reinforces the other person’s ownership, which is how you build allies among people who feared you would encroach.

“Nobody knows. Here is the uncertainty, and here is what would resolve it.” The strongest with senior people, and the least used. It demonstrates that you have mapped the problem well enough to know where its edges are — which is a more advanced claim than having an answer. It also hands them a decision: fund the thing that would resolve it, or proceed with the uncertainty stated.

The failure mode: answering everything

An architect who answers every question feels maximally helpful and is corrosive, for a reason that takes a moment to see.

Some of those answers are wrong. And to the person asking, a confident wrong answer is indistinguishable from a confident right one — they came from the same person in the same tone. So the effect of answering everything is not that people get more information; it is that all your answers become equally unreliable, including the good ones.

Narrowing what you claim is what makes the claims mean something.

What it costs

Two real costs, worth accepting with open eyes.

You will sometimes be seen as unhelpful. Some stakeholders want an oracle, and “that is not mine” disappoints them. State the boundary anyway: the alternative is Module 1’s accumulation trap, where you end up accountable for everything and empowered for nothing.

It is slower in the moment. A guess ends the conversation; a commitment to find out extends it. That trade is almost always correct, and the exception is a genuine emergency where a provisional answer labelled as provisional is better than nothing.

The boundary that will be tested

The Module 1 charter drew the lines: accountable for the initiative meeting its business drivers, satisfying compliance, and not damaging work already in flight. Deciding cross-team structure, technology constraints, where data may live, and the escalation model between automation and human. Not deciding implementation choices inside those constraints, staffing, product scope and priority, or the release date.

What the “not deciding” list buys, specifically. Tomas Beck owns 140 engineers who did not ask for an architect. The sentence I do not choose which libraries or storage engines teams use; I set the constraints they must satisfy is the single cheapest thing available for converting that constituency from suspicious to neutral. It costs nothing, because those choices were never yours, and it removes the threat Section 2 identified as the root of quiet resistance.

The boundary that will be tested, and the answer. Workbook exercise 1 posed it: your charter says you do not decide product scope. Priya Shah asks you to drop a compliance requirement to hit the two-quarter commitment. Is that product scope?

No — and the clean answer uses both the boundary and the escalation. Scope is yours: which features ship, in what order, by when. Whether the system may process regulated customer data outside its region is not scope, it is a constraint, and it is Lena Fischer’s to waive rather than mine or yours. What I can do is show you what scope fits inside the constraint by your date.

That reply declines the request, respects her ownership, names the actual decision-maker, and offers something useful — which is the shape of every good boundary statement.

And the “nobody knows” form, where it applies right now. Asked whether the deflection target is achievable, the honest answer is that the 38% figure is a claim about the documentation rather than about the tickets, nobody has tested it, and a two-day audit of fifty tickets would resolve it. That is a stronger position than either optimism or pessimism, and it converts a disagreement into a funded task.

Feeds the workbook

Your three audience framings each need a boundary: what you are not claiming in that document. And the rubric’s requirement that uncertainty be stated somewhere is the third form of “I don’t know”, applied in writing.

→ You know what you are claiming. Four different people need to hear it four different ways. — Translating across audiences