> ## Content Index > Fetch the complete content index at: https://contextfirst.blog/llms.txt > Use this file to discover other available public pages before exploring further. # Outcome-Aligned Teams Around End-to-End Journeys - URL: https://contextfirst.blog/outcome-aligned-teams-journeys/ - Published: 2026-09-17T13:00:00.000Z - Updated: 2026-09-17T13:00:01.000Z - Description: Organize around journeys, not repos - Author: Iheatu Chris Wogu - Tags: Field Notes, Engineering Management, Agentic Delivery, Learning Journey 2026 Component teams optimize locally. Journeys die at the handoff. On a launch program with identity, registration, entitlement, and partner surfaces in play, every repo had an owner - and nobody owned "user completes the path." Org design and [SIT Phase 2 seams](https://contextfirst.blog/sit-63-workflows-team-seam-journey/) are the same problem. **Here's what this piece covers:** the leadership cost of feature-factory orgs, the Jul 2026 topology for a 20-person scope, how journey teams map to testing, the named pattern, and three habits before your next reorg. Part of the [Field Notes: agentic delivery](https://contextfirst.blog/field-notes-agentic-delivery/) series. --- ## 1\. The leadership problem A "web platform team" becomes a bottleneck without clear outcomes. Feature teams ship; seams fail in TEST. Chronic regression clusters on one boundary while three managers argue whose backlog owns the fix. **Wrong:** "We reorganized for agility." **Right:** "Four journey teams + Platform Council - what each owns, how testing maps, one PO per outcome." The anti-pattern is the **feature factory org** \- every team ships; nobody owns the seam. --- ## 2\. What the program docs show Jul 2026 topology in `docs/team-topology/website-team-ownership.md` (also referenced from the 2026-07-28 metrics draft). Scope: **20 people** (16 developers + 4 QA), **4 delivery teams**, **4 POs**, Platform Council as a **practice** (not a fifth delivery team). External partners (CMS, identity provider, transaction platform) stay outside the 20 - called out explicitly so they are not "someone else's API" by accident. flowchart TB subgraph inScope \[In scope - 20 engineers\] SE\[Site and Experience\] AO\[Account and Ownership\] RS\[Registration Service\] QP\[Quality Platform\] PC\[Platform Council - 5 leads\] end subgraph external \[External partners\] CMS\[CMS\] ID\[Identity\] TX\[Transaction platform\] end CMS --> SE ID --> AO TX --> SE RS --> AO SE --> PC AO --> PC RS --> PC QP --> SE QP --> AO QP --> RS --- ## 3\. What I built: four outcome teams | Team | Success looks like | Shape | | ------------------------------------------ | --------------------------------------------------------- | --------------------------------- | | **Site & Experience** | Users discover, complete the primary action, track status | Two pods, one PO, one embedded QA | | **Account & Ownership** | Logged-in users manage identity, owned items, history | One PO, embedded QA | | **Registration Service** | Registration and entitlement data correct and integrated | One PO, embedded QA | | **Quality Platform & Release Engineering** | Releases backed by trustworthy test evidence | One PO, embedded QA | | **Platform Council** *(practice)* | Shared architecture stays consistent | Five part-time leads · no PO | Registration split that prevents double ownership: Account & Ownership owns the website journey (forms, BFF); Registration Service owns API and data; identity provider owns tokens - Account owns how login *feels* on the path. ```clojure (def outcome-teams {:site-experience {:owns [:discover :complete :track]} :account-ownership {:owns [:identity :owned-items :history]} :registration {:owns [:entitle :warranty-data]} :quality-platform {:owns [:evidence :release-gates]}}) (defn seam-owner [from to] ;; Prefer the team that owns the destination node on the master flow (first (for [[t {:keys [owns]}] outcome-teams :when (some #{to} owns)] t))) ``` Testing maps to the same seams: Phase 2 shared workflows in the [63-workflow SIT catalog](https://contextfirst.blog/sit-63-workflows-team-seam-journey/) fail where topology is wrong. Wrong topology → untestable handoffs. --- ## 4\. Named pattern: outcome-aligned teams > **Outcome-aligned teams** \- organize around end-to-end journeys, not repo folders; journey teams deliver; Platform Council governs shared standards without becoming a delivery bottleneck. | Artifact | Who uses it | Decision it supports | | -------------------- | ------------- | ------------------------------------ | | Team charters | EM, POs | "Who owns this seam?" | | Pod split (Site) | Leads | Discover vs complete without two POs | | Cross-team seam list | Integration | What SIT Phase 2 must prove | | When-to-change rules | Staff meeting | Revisit when chronics cluster | **What broke:** Platform Council that starts taking tickets becomes a shadow team. Split POs on one outcome recreate parallel truths from [article 01](https://contextfirst.blog/mapping-dtc-launch-mvp-flow/). Revisit topology when [chronic regression](https://contextfirst.blog/chronic-regression-3403-tickets/) clusters on one seam. --- ## 5\. What I'd do as a lead Three habits - steal one this month: 1. **Draw team boundaries at journey seams, not repo folders.** If the master flow node has no owner, the org chart is incomplete. 2. **One PO per outcome team.** Avoid split accountability on the same user path. 3. **Revisit topology when chronics concentrate.** Source-area heat from the recurrence pipeline is an org signal, not only a bug signal. --- ### Further reading - [Field notes: agentic delivery](https://contextfirst.blog/field-notes-agentic-delivery/) \- series intro - Prior: [Chronic regression](https://contextfirst.blog/chronic-regression-3403-tickets/) - Related: [Team → seam → journey](https://contextfirst.blog/sit-63-workflows-team-seam-journey/) · [Fifty pages, one map](https://contextfirst.blog/mapping-dtc-launch-mvp-flow/) - Next: [Engineering delivery dashboard](https://contextfirst.blog/engineering-delivery-dashboard/) - Planning anchor: team topology docs · Jul 2026 --- ![Iheatu Chris Wogu](https://avatars.githubusercontent.com/u/3457705?s=176&v=4) ## About the author **Iheatu Chris Wogu** is an engineering manager focused on launch programs, honest engineering metrics, and **engineering-led, agent-accelerated** delivery - researching where work queues up when agents widen dev output, then building proof, gates, and measurement that scale. Field notes live on [First Context](https://contextfirst.blog/). Values treatise: [engineering manager values](https://contextfirst.blog/engineering-manager-values/). **LinkedIn:** [linkedin.com/in/iheatu-chris-wogu](https://www.linkedin.com/in/iheatu-chris-wogu/?ref=contextfirst.blog)