Hard Situations and the Human Texture
Overview
Section titled “Overview”The decisions are made. What remains is the part of the job that does not appear in any diagram, and that determines whether the plan survives.
Three situations recur often enough to prepare for. None has a clean resolution, which is why they are worth naming in advance rather than meeting unprepared.
Platform against product
Section titled “Platform against product”The most common structural conflict in engineering organisations, and it is not a disagreement about facts.
Product work has visible results on a schedule people can see. Platform work makes future product work cheaper and shows nothing this quarter. Both are necessary; the two sides are measured differently; and the conflict is therefore permanent rather than resolvable.
What does not work: arguing that platform investment is obviously correct. The product side is not making an error — they are responding accurately to how their results are judged.
What does work is narrower. Attach structural work to the product work that needs it, so the seam gets built because a feature requires it rather than because it is architecturally right. The previous topics did exactly this: characterization tests justified by an action path that needs them, seams justified by a migration that needs them. The structural result is identical and it is funded by something with a visible outcome.
And where that is genuinely impossible — where the work is pure infrastructure with no near-term product need — the honest move is to say so and let it be prioritised against features on its merits, rather than disguising it. Module 9’s one-backlog discipline applies: structural work that cannot survive an honest comparison usually should not be first.
Inheriting someone else’s decisions
Section titled “Inheriting someone else’s decisions”You will spend most of your career inside decisions you did not make, many of which look wrong.
Three failure modes, in order of how expensive they are:
Condemning them. The reflex, and it is almost always both unfair and costly. The previous section’s point stands: a decision that looks indefensible today was usually correct against constraints that no longer exist, and the people who made it are often still present and still needed.
Defending them past their expiry. The opposite error — inherited decisions acquire a kind of institutional protection, and whoever inherits them often becomes their advocate without ever having examined them.
Reopening everything at once. The newcomer’s mistake. Every inherited decision looks like a candidate for revision, and revising several simultaneously consumes all your credibility on work that is mostly not load-bearing.
The usable discipline is the recovery heuristic from Module 9: follow the arguments, not the architecture. Revisit the inherited decisions that are currently costing something or currently being disputed. Leave the rest recorded and alone. An inherited decision that nobody is arguing about and nothing is blocking is not your problem, however much it offends you.
graph TD
A["An inherited decision<br/>looks wrong"] --> B{"Is it costing<br/>something <b>now</b>?"}
B -->|"Yes"| C["Re-derive it against<br/>today's constraints"]
B -->|"No"| D["<b>Record it and<br/>leave it alone</b>"]
classDef ev fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
classDef q fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
classDef act fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
class A ev
class B q
class C,D act
The filter that keeps a new architect solvent. Most inherited decisions pass to the right.
Responsibility without authority
Section titled “Responsibility without authority”The structural feature of the role, established in Module 1 and worth returning to near the end of the guide with what it has added.
The position is genuinely difficult: you are accountable for outcomes you cannot command, your work is mostly invisible when it succeeds, and the feedback arrives years late or not at all. Treating that as a personal failing is the most common mistake people in the role make, and it is simply a misreading — the gap between responsibility and authority is in the job’s design, not in your performance.
Three things that make it sustainable, and they are practical rather than inspirational:
Keep a record of what you decided and why. Module 9’s practice has a second function nobody advertises: in a role where outcomes are slow and diffuse, a decision set is the only concrete evidence that you did the work. It is also what lets you learn from a decision whose result arrives three years later.
Measure your own contribution by decisions, not outcomes. Outcomes depend on execution, market, timing and luck. A decision can be judged on whether it was sound given what was knowable, which is the only thing you actually controlled. Architects who judge themselves by outcomes in a role with this much variance will reach the wrong conclusion about their own competence in both directions.
Know which battles you are not fighting. The credibility reserve is finite, and the people who burn out in this role are usually not the ones with the hardest problems. They are the ones who treated every wrong thing as theirs to fix. Module 9’s deferral discipline applies to your attention as much as to governance: naming what you are deliberately not doing, and why, is the same skill pointed inward.
Feeds the workbook
Section titled “Feeds the workbook”This shapes how your legacy strategy is framed and argued, and it is where the rubric’s capacity constraint becomes a human one: a plan is only executable if the people whose agreement it needs can say yes to it.
→ The system can be changed. The last question is what the job of changing it is becoming. — Threat and opportunity