Architecture Liaison Function

Two squads in different domains were building the same capability on different stacks, and neither knew about the other. That is the kind of thing the Architecture Liaison Function exists to catch. I stood it up as a lightweight governance facilitator for the architecture decisions that belong to no single squad and still need a named owner. It connects Squad Architects, Domain Architects, Architecture Services, and the CTO along one pipeline, with a bi-weekly forum as its backbone. The design borrows the enabling-team pattern from Team Topologies (Skelton and Pais, 2019) to hold cognitive load down on stream-aligned teams while keeping architecture coherent across domains.

The problem

Architecture decisions were drifting across squads. Two teams in different domains could reach incompatible positions in complete ignorance of each other, and a decision raised in a squad Teams channel usually died there instead of reaching the people who owned the roadmap. The friction ran both ways: architects felt unheard, and R&D Leadership worked partially blind.

A reorg under a new CTO changed the organization on three axes at once. Architecture Services became a central function. The Domain and Squad Architect tiers were formalized and named. A new leadership layer took ownership of the R&D roadmap. The drift predates all of that, but the reorg made the missing seam impossible to ignore. The organization now had named architects at every level, a named owner of the roadmap, and a gap where the pipeline between them should have been.

The approach

I designed the function around the Team Topologies pattern for enabling teams. Architecture Services serves stream-aligned squads through two explicit interaction modes: facilitating, which is the default long-term posture, and collaboration, reserved for the heavier cross-domain decisions that earn it. The liaison role is the named carrier of the facilitating mode.

Four components shipped:

• A four-way chain. A Squad Architect raises, a Domain Architect aggregates, Architecture Services validates and standardizes, and the CTO ratifies at roadmap level. Every handoff is named and owned.
• An RFC pipeline with explicit handoffs, so decisions travel as artifacts rather than as Teams threads. One RFC template covers every domain, which lets Domain Architects compare proposals directly instead of translating between formats first.
• A bi-weekly architecture forum. RFCs get reviewed there, follow-through gets tracked between sessions, and the liaison owns the agenda and the chasing. The fortnightly cadence is what makes it work. The template and the tracker are scaffolding around it.
• A defined scope, including an explicit list of what the function is not. The liaison is not a product-strategy role, not a steering committee, and not an escalation path for individual-contributor disputes. Holding that line kept the pipeline from turning into a dumping ground.

The outcome

Decisions now arrive on a cadence instead of surfacing when someone happens to raise them. Four artifacts anchor the shift:

• A killed duplication. The two squads building the same capability on different stacks surfaced in the forum before either had shipped, and the work consolidated under one owner.
• A ratified R&D strategy for agentic development. The RFC covering our approach to agentic tooling, the internal ai-resources catalog, and enablement went through the pipeline and was approved at the R&D level. It reshaped what the program owned and how it would scale.
• A PRD plus TDD driven process as the paved path. Architecture Services authored it through the pipeline, with heavy investment in TDD review via automation and agents, peer review, and Enterprise Architect review. Domains now share one shape of development where they used to have six.
• A platform decision ratified by engineer adoption. A tooling selection ran through the pipeline with winning criteria measured in a pilot: real engineer uptake and real feedback, with demo quality carrying no weight. Alternatives failed the pilot.

The quieter result runs the other way, from the CTO back down. Decisions made at that level now reach Domain and Squad Architects within a forum cycle. The old informal channels left that loop open.

What I’d change

Hold the line on scope earlier. The function kept getting pulled into product-strategy conversations that had nothing to do with architecture, which cost time and diluted the pipeline’s signal. Writing down what the liaison is not turned out to matter as much as writing down what it is, and doing that sooner would have saved the cost of arguing it case by case. Team Topologies has language for this too: an enabling team that absorbs stream-aligned work has stopped being an enabling team.