Architecture Liaison Function

Stood up the Architecture Liaison Function as a lightweight governance facilitator for architecture decisions that do not belong to any one squad but still need a named owner. The function connects Squad Architects, Domain Architects, Architecture Services, and the CTO along a single pipeline, with a bi-weekly forum as its backbone. The design applied the enabling-team pattern from Team Topologies (Skelton and Pais, 2019) to reduce cognitive load on stream-aligned teams while keeping architectural coherence across domains.

The problem

Architecture decisions were drifting across squads. Two teams in different domains could reach incompatible positions without either knowing about the other, and a decision raised in a squad Teams channel often never travelled up to the people who owned the roadmap. The friction was asymmetric: architects felt unheard, and R&D Leadership worked partially blind.

A reorg under a new CTO changed the shape of the organization on three axes at once. Architecture Services was reshaped as 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 combination did not create the drift, but it made the missing seam impossible to ignore: the organization now had named architects at every level, a named owner of the roadmap, and no named pipeline between them.

The approach

The function was designed around the Team Topologies pattern for enabling teams (Skelton and Pais, 2019). Architecture Services would serve stream aligned squads through two explicit team-interaction modes: facilitating, as the default long-term posture, and collaboration, for the heavier cross-domain decisions that needed it. The liaison role was the named carrier of the facilitating interaction.

Four concrete components shipped:

• A four-way chain. Squad Architect raises, Domain Architect aggregates, Architecture Services validates and standardizes, the CTO ratifies at roadmap level. Each handoff is named and owned.
• An RFC pipeline with explicit handoffs. Decisions travel as artifacts, not as Teams threads. The RFC template is the same across domains, which lets Domain Architects compare proposals rather than translate between formats.
• A bi-weekly architecture forum as the backbone. RFCs are reviewed in the forum; follow-through is tracked between forums; the liaison owns the agenda and the chase. The rhythm is the load-bearing element, not the process around it.
• A defined scope, including 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 protected the pipeline from becoming a dumping ground.

The outcome

Decisions now flow through the pipeline as a steady cadence rather than as ad-hoc surfacing. Four concrete artifacts anchor the shift:

• A killed duplication. Two squads in different domains were independently building the same capability on different stacks. The function surfaced the overlap in the forum before either had shipped, and the work consolidated into one owner.
• A ratified R&D strategy for agentic development. The RFC ratifying the organization’s approach to agentic tooling, the internal library, 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. Authored by Architecture Services 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 rather than six.
• A platform decision ratified by engineer adoption. A tooling selection ran through the pipeline with winning criteria measured in a pilot: actual engineer uptake and feedback, not demo quality. Alternatives failed the pilot.

Less visible but load-bearing: the feedback direction. Decisions made at the CTO level now reach Domain and Squad Architects quickly, closing the loop the old informal channels had never completed.

What I’d change

Hold the line on scope earlier. The function repeatedly got pulled into product-strategy conversations that were not architecture, which cost time and diluted the pipeline’s signal. Documenting what the liaison is not was as important as documenting what it is. Doing that earlier would have saved the negotiation cost of pushing back on those asks in the moment. Team Topologies offered the language for this too: enabling teams that absorb stream-aligned work stop being enabling teams.