Ivory Tower or Embedded

Overview

Section 1 was diagnosis. This section is what you do about it, given that you cannot change the structure, the culture or the size.

The first decision is where you sit — not your desk, but your proximity to the work. It is usually made by default, and it determines which decisions you are present for.

Two poles

Ivory tower. Architecture produced at a distance. Documents, diagrams, reference architectures and standards issued to teams who then build things. Cheap to produce. One document reaches ten teams. It scales, in theory. Easy to ignore. The teams know the author has no stake in the implementation, and voluntary compliance with an absent author’s rules trends toward zero.

Embedded. Architecture produced alongside the teams. You sit in their planning, read their pull requests, feel their constraints, and hear the thing someone says at the end of a meeting that changes everything. Hard to ignore. You are there, you know what it is like to build this, and your suggestions arrive with context. Does not scale. You can be genuinely embedded with two or three teams. Not ten.

The costs, precisely

Worth naming both sides, because each pole has a characteristic failure that its advocates do not mention.

The tower costs you credibility, relevance and adoption. Credibility, because a standard written by someone who has not built in this codebase is discounted automatically — often correctly. Relevance, because documents drift from reality and the author is the last to know. Adoption, because a rule nobody enforces and nobody believes is a rule in name only.

Embedding costs you coverage, capture and attention. Coverage, because the teams you are not embedded in get nothing. Capture, because sitting with one team for six months makes you a member of that team — you acquire their priorities, their blind spots, and their view of the other teams, which destroys the cross-team perspective that was your entire value. And attention, which is the scarcest input you have.

Capture is the subtle one and the more dangerous. An architect who has become a team’s senior engineer is doing useful work and is no longer doing the job.

The honest answer is a rotation

graph LR
  A["<b>Embedded</b><br/>two or three teams<br/><i>deep, narrow, credible</i>"] --> C["Your actual<br/>position"]
  B["<b>Tower</b><br/>everyone else<br/><i>wide, shallow, ignorable</i>"] --> C
  C --> D["<b>The real decision:</b><br/>where to be deep,<br/>reviewed every quarter"]

  classDef emb fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef tow fill:#D8D3CB,stroke:#B8B2A8,stroke-width:2px,color:#3F3F3F
  classDef pos fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef dec fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  class A emb
  class B tow
  class C pos
  class D dec

Neither pole is a position; every real architect is both at once. The amber box is the decision that actually matters, and it is the one usually made by accident.

Two practical rules make the rotation work rather than becoming drift.

Embed where the risk is, not where the interest is. The most technically interesting team is rarely the one where a wrong decision is most expensive.

Make the rotation visible. Teams need to know what to expect from you. “I am in your planning for this quarter and reachable but not present next quarter” is a usable statement; silently drifting away is how an architect acquires a reputation for being unavailable.

Positioning is decision-rights allocation

The reframe that makes this an architectural concern rather than a preference about working style.

A decision made in a team’s sprint planning is only yours to influence if you are in the room. An interface settled in a corridor is settled. By choosing where to be deep, you are choosing which class of decisions you will see at the point where they are cheap to change — and conceding the rest to whoever is present.

That makes positioning a form of decision-rights allocation, and it should be reasoned about the same way Module 1 reasoned about the charter: deliberately, in writing, with the concessions explicit. “I am not in those decisions” is a legitimate position. “I did not realise those decisions were happening” is not.

The cost of getting it wrong is specific: you discover a structural decision after it shipped, and your only options are to accept it or to spend credibility reversing something that already works.

Where to be deep

Four candidate places to embed, with roughly one and a half slots of real attention available.

The team building the AI platform — embed, deeply. This is where the risk concentrates: every decision from Modules 4 through 7 lands here, the blast radius includes money leaving the company, and the design has organisational preconditions nobody wrote down. If a boundary erodes, it erodes here.

The migration teams — tower. This is deliberate rather than neglectful. Ivan Petrov already provides technical leadership over the monolith and the extraction work, and embedding there would duplicate him while costing the one thing he actually has reason to resent: an architect reviewing his domain. The right relationship with the migration is a documented interface contract and regular contact, not presence.

Grace Adeyemi’s support team — embed, lightly, and this is the non-obvious one. No engineering team will ever surface whether the handoff package is usable, whether the confirmation volume is survivable across three time zones, or whether the degraded rung three actually deflects anything. Those three facts decide whether the initiative succeeds, and they are only observable from inside the support organisation. A standing half-day a fortnight with the people receiving the handoffs is worth more than a week of design review.

Leadership — neither. Maya Ortiz and Dev Raghunathan need artifacts and arithmetic rather than presence. Section 4 covers what to bring them.

The concession, stated explicitly: implementation decisions inside the Go services and the monolith are not mine. I will not see them, and that is the trade for being deep where the money moves. Written into the charter so it is a position rather than an oversight — and it is also the thing that buys goodwill from the engineers most inclined to resent the role.

Feeds the workbook

This is the first half of your positioning statement. Name where you will be deep, where you will be a tower, and — the part that makes it a plan — which decisions you are therefore conceding, to whom.

→ You know where to stand. Nobody has given you the right to decide anything from there. — Building a remit with no mandate