Expectations, and When to Leave

Overview

The module closes on the question most guides leave out, because an honest account of this material has to include the case where the right answer is to go.

Before that, the thing that prevents it: managing what people believe you will deliver.

The job you were hired for and the job that exists

These differ in almost every case, and the gap is not a communication problem to be smoothed over. It is the actual situation.

Three expectation failures, each with a different response.

Over-promised before you arrived. Covered in the previous topic. Someone described what an architect would do, to several people, in different terms. The response is the divergence diagnostic: ask each stakeholder individually what they expect in the first quarter, write it down, and take the contradiction to whoever sponsored the role. It is their decision to make, and handing it to them is not weakness — it is the only way it gets resolved.

The role is two jobs. You were hired as an architect and are also expected to be a delivery lead, or the person who rescues the migration, or the one who personally makes the new initiative happen. Each is a real job. Doing two badly is the default outcome.

The response is to name it and ask which one, explicitly, with the trade stated: I can own the architecture across these initiatives, or I can own delivery of this one. Both means neither gets done properly. Which do you want? Uncomfortable, and it is a question with an answer, which is better than a year of ambiguity.

Nobody expects anything. Worse than it sounds. If no stakeholder can say what they want from you, there is no demand for the role, and the position exists for reasons unrelated to need — a headcount that was available, a conference talk someone attended, a competitor who hired one. You are on borrowed time and the clock is invisible.

Hard versus impossible

graph TD
  A["<b>Hard — and normal</b><br/>no mandate · no capacity ·<br/>scar tissue · sceptical<br/>senior engineer"] --> B["Workable.<br/>This guide is<br/>about these"]
  C["<b>Impossible — structural</b><br/>two executives define the<br/>mandate differently and<br/>neither will resolve it"] --> D["Not fixable from<br/>your position"]
  E["<b>Impossible — informational</b><br/>you cannot obtain the<br/>information the job requires"] --> D

  classDef hard fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef ok fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef imp fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A hard
  class B ok
  class C,E imp
  class D imp

The distinction that matters. Everything in the amber box is the normal condition of the job and the subject of this entire guide; the terracotta boxes are not solved by working harder.

Hard is the normal condition. No mandate, no spare capacity, scar tissue, a respected senior engineer who thinks you are a risk — every one of those is hard, every one is workable, and the whole of Part 4 is about working them. An architect who concludes a role is impossible because it is difficult has mistaken the job for a problem with the job.

Impossible is structural. Two signals are worth taking seriously:

Conflicting authority nobody will resolve. Two executives define your mandate differently, you have surfaced it explicitly, and neither will settle it. You now cannot satisfy either without failing the other, and no amount of competence changes that. This is the most common genuinely impossible shape.

The information required is unobtainable. You cannot get access to the people who decide, or the organisation’s culture means the facts you need to do the job cannot be said out loud. Module 1’s chain — driver to requirement to decision — cannot run on information you cannot acquire.

The signals, and the honest trial period

Three further observations that suggest structural rather than difficult:

No decision you make is ever final; every one is relitigated by someone with authority who was not in the conversation.
A year in, nothing you have proposed has been adopted — not rejected with reasons, simply not adopted.
The role was created to avoid a reorganisation the organisation needed, and you are the substitute for structural change.

Before concluding any of that, give it a fair trial. Two quarters, not two months — the remit-building in this section works on that timescale by construction, and judging it earlier measures your onboarding rather than the organisation. And have one explicit conversation with your sponsor about what would have to change, because the answer is occasionally “that, and I can do that”.

Why recognising it early matters

Two costs. The first is a year of your career spent proving something unprovable. The second is that a failed architecture role teaches an organisation that architecture does not work here. That conclusion outlives you and makes it materially harder for whoever comes next — which is how the cursed role from the previous topic gets created. Leaving a role that cannot work, early and without drama, is a smaller harm than staying in it until the conclusion is drawn.

And the scope line from Module 1 holds here too: this guide teaches you to influence the organisation, not to own it. Influence has a limit, and recognising where it runs out is part of the skill rather than an admission of failure.

Hard, not impossible — and the thing that would change that

Run the assessment on the position as described.

Evidence that the role is supportable: a real sponsor in Maya Ortiz who owns the outcome and wanted the role. A real business driver with numbers attached. Approved budget — $1.2M a year from Dev Raghunathan, which is a commitment rather than an aspiration. A genuine problem that an architect is the right answer to: roughly 140 engineers with no decision record, colliding with themselves. And no predecessors, so no established pattern of failure.

Evidence of difficulty, all of it normal: no mandate, no formal authority, zero spare engineering capacity, an informal veto held by a respected principal engineer, scar tissue from 2023, and a compliance owner who can block outright. Every item on that list is the subject of a topic in this module. None of it is structural.

The verdict: hard, not impossible. Which is the answer for most first-architect roles, and it is why the positioning work in this section is worth doing rather than circumventing.

The specific thing that would change the verdict. If Tomas Beck and Maya Ortiz turn out to define the role incompatibly — Maya expecting an architect who owns delivery of the support platform, Tomas expecting one who stays out of his teams’ way and does not consume capacity — and neither will resolve it when it is named, then the role is two jobs with one occupant and no authority to choose between them. That is the impossible shape, and it is the one to test for early.

The test is the week-one diagnostic from the antipatterns topic: ask all seven what they expect by the end of the quarter, write it down, and compare. If Maya’s and Tomas’s answers are incompatible, that divergence goes to Maya as sponsor with a direct question about which job this is. Her answer — or her refusal to give one — is the single most informative thing you will learn in the first month.

What to do with the answer. If she resolves it, proceed. If she cannot, you have found the structural problem in month one rather than month twelve.

Feeds the workbook

Your positioning statement should end with the honest assessment: hard or impossible, the evidence, and the specific condition that would change your reading. A positioning statement that assumes success is an aspiration, which the rubric explicitly rejects.

→ You can read the organisation and hold a position in it. Nothing moves until specific people agree. — How trust is earned and spent