Facilitator Guide · Module 2.2 of 2.6 · Shared Foundations
Prepare the Shared Work That Keeps Local Roadmaps Coherent
Identify the cross-ART standards, capabilities, platforms, evidence systems, and organizational changes that need a common owner and roadmap. Bring their decision gaps into the conference—not a parade of community updates.
Fast exercise
5 minutes
Full exercise
15–25 minutes
Input
Value Stream Initiatives
Output
Owners + foundation roadmaps
Next module
Tactical Contributions
Understanding Shared Contributions
Shared foundations need a decision-capable owner, not necessarily a new committee
Architecture, platform, DevOps, security, compliance, data, quality, release, and transformation work often cut across delivery units. The conference needs a trusted representation of that shared work and a clear path for changing it.
ScopeWhat is genuinely shared?
Name the standards, services, capabilities, evidence, or changes that several units must use or evolve together.
OwnershipWho maintains coherence?
Identify the person or network that can curate the roadmap, convene expertise, and carry decisions forward.
RoadmapWhat must change over time?
Show target condition, milestones, adoption, capacity, dependencies, risks, and open decisions.
Decision capability testCan the conference change a shared foundation without creating contradictions across architecture, platform, DevOps, security, compliance, data, quality, and transformation work?
Community, Forum, or Named Owner
Choose the lightest ownership pattern that can maintain a roadmap
Community of PracticeDistributed expertise and learning
Useful when practitioners across units must evolve shared knowledge, standards, and practice.
Named owner + representativesClear accountability with a small network
Useful when a roadmap needs one steward and periodic input from affected units.
Platform / service ownerProduct-like ownership
Useful when a shared capability has users, service levels, investment choices, and adoption work.
Useful only when the forum can make timely decisions and update the relevant artifacts.
Running the Exercise
Four moves from initiative inventory to decision-ready foundation roadmap
1
Approximately 2–4 minutes
Select the Shared Decisions
Use the initiatives identified in Stage 1.3 and the top Flow problems. Ask which shared foundation must change, which decision blocks that change, and which units would be affected.
ArchitectureRunway and interfaces
Target state, standards, APIs, integration decisions, and technical debt.
PlatformShared capability and adoption
Service roadmap, API strategy, operating model, demand, and constraints.
DevOps / InfrastructureDelivery system
Pipelines, environments, observability, automation, and deployment constraints.
Security / ComplianceGuardrails and evidence
Threat model, controls, safety, regulatory obligations, and evidence chain.
Toolchain / AI / DataShared information system
ALM, telemetry, data platform, AI governance, model risk, and enablement.
Quality / Release / ChangeReadiness and evolution
Validation, release, operations, transformation, skills, and organizational design.
Shared decision promptWhat must several parts of the value stream follow, build, evolve, or understand together—and what choice is currently preventing that?
Speaker Notes
Facilitator intent
Select the shared foundation decisions that must enter the conference because several units need coherent standards, capabilities, evidence, platforms, or change roadmaps.
How to facilitate
Start from Stage 1.3 initiatives and the top Flow problems, then ask which shared foundation must change to reduce the problem.
Force a decision sentence: what shared thing must be chosen, sequenced, funded, standardized, adopted, or escalated?
Name affected units explicitly so the topic does not stay at the level of Architecture, DevOps, Compliance, Platform, or Transformation as abstract nouns.
Listen and watch for
A domain label being treated as a decision, for example Architecture or Cybersecurity without the specific choice.
Shared initiatives selected because they have a community, not because their roadmap changes conference decisions.
A topic that is actually local to one ART or one department but sounds important enough to become a value-stream issue.
Avoid
Creating a committee for every shared noun. Only select topics whose cross-unit coherence matters to the roadmap.
Solving foundation problems immediately. This module prepares owners, artifacts, and decision gaps for the conference.
Ignoring adoption impact. A standard that nobody must adopt is not a conference decision.
2
Approximately 3–5 minutes
Name the Ownership Pattern
Separate expert participation from roadmap accountability. A community can contribute knowledge; one identifiable owner or explicit joint rule must still maintain the decision and roadmap flow.
Minimum ownership contract[Owner / network] maintains [shared roadmap or artifact] for [affected scope], convenes [contributors], can decide [delegated choices], and escalates [non-delegated choices] to [authority] within [response time].
Roadmap ownerCurates the shared view
Maintains milestones, adoption, decisions, dependencies, and status.
Decision authorityChanges direction or guardrails
Approves material standards, investment, risk, or cross-unit trade-offs.
Domain expertsProvide viable options
Bring specialist judgment, evidence, consequences, and dissent.
Adopting unitsExpose feasibility and impact
Bring migration cost, timing, local constraints, and feedback.
Artifact stewardRecords the usable result
Updates the standard, ADR, roadmap, service agreement, or evidence plan.
Speaker Notes
Facilitator intent
Choose the lightest ownership pattern that can maintain a shared roadmap, convene expertise, make delegated decisions, and escalate non-delegated choices quickly enough.
How to facilitate
Use the minimum ownership contract on the slide and fill every clause: owner/network, artifact, scope, contributors, delegated choices, escalation authority, and response time.
Separate expert participation from accountability. A community can advise, but someone must steward the artifact and decision flow.
Choose between CoP, named owner plus representatives, platform owner, time-boxed initiative team, or existing governance forum based on the work's real coordination need.
Listen and watch for
A CoP proposed before anyone knows the decision rights, roadmap owner, or artifact to update.
A shared roadmap owned by everyone; this usually means no one curates the sequence, assumptions, or decision log.
An existing forum that meets often but cannot decide, update the artifact, or escalate in time.
Avoid
Over-formalizing too early. A named steward and representatives may be enough for the next conference.
Treating ownership as organizational design. It is a preparation hypothesis unless leadership explicitly changes the operating model.
Letting the most senior expert become the owner when the required work is artifact stewardship and decision flow.
3
Approximately 4–7 minutes
Prepare the Shared Foundation Roadmaps
A roadmap should expose the decisions and trade-offs the conference must integrate. Replace generic status with the minimum layers needed to compare shared work with business objectives and tactical capacity.
Current condition
Installed base, adoption, bottleneck, debt, service level, or evidence status.
Target condition
The coherent capability, standard, service, or operating behavior being pursued.
Milestones
Learning, enablement, migration, integration, evidence, and adoption points.
Dependencies
ARTs, suppliers, central functions, interfaces, environments, and scarce expertise.
Capacity
Owner capacity, contributor demand, implementation capacity, and credible flex.
Decisions
Open choices, decision date, authority, options, and consequences.
Evidence
Measures, feedback, confidence, validation gap, and review trigger.
Adoption
Which units change, in what sequence, with which support and exit criteria.
Roadmap rule: If the artifact cannot show what changes after a conference decision, it is probably an update deck rather than a working roadmap.
Speaker Notes
Facilitator intent
Turn shared-foundation status into roadmap material that can participate in trade-offs: current and target condition, milestones, dependencies, capacity, decisions, evidence, and adoption.
How to facilitate
Ask each owner to bring the smallest roadmap that can show what changes after a conference decision.
Make dependency and adoption visible: which ARTs, suppliers, central functions, environments, or skills are affected and in what sequence?
Mark open decisions, options, consequences, confidence, and artifact owner directly on the roadmap or its companion decision log.
Listen and watch for
Roadmaps that are really status lists: done, doing, next, with no trade-off or adoption sequence.
Foundation roadmaps that ignore tactical capacity; adopting a standard also consumes capacity somewhere.
Evidence chains that are missing for compliance, safety, cybersecurity, quality, or release readiness.
Avoid
Asking for a perfect roadmap before the first conference. Decision-ready is enough; refinement continues later.
Letting shared foundations bring generic updates instead of options, constraints, and decisions.
Hiding contradictions between foundation roadmaps; contradictions are Decision Contract material.
4
Approximately 3–6 minutes
Close the Decision Gaps
For each selected initiative, choose who represents it, how they participate, what they bring, and which unresolved decision must be ready. Keep missing ownership visible as preparation work.
Shared Initiative / Community Preparation Board
Initiative / community
Roadmap / artifact
Owner
Affected scope
Participation
Key decision gap
Update owner
Architecture
runway + ADR log
Chief Architect
3 ARTs
Core
API standard
Architecture owner
Platform
service roadmap
Platform PM
all ARTs
Window
adoption sequence
Platform PM
Compliance evidence
evidence chain
Safety lead
2 ARTs + supplier
Standby
acceptance gate
Compliance lead
Shared-contribution gateREADY
owner, scope, roadmap, decision gap, participation mode, and artifact update are explicit
PREP
the owner can close a known evidence or option gap before the conference
ROUTE
the topic is local, already governed elsewhere, or lacks enough cross-unit leverage for this conference
Speaker Notes
Facilitator intent
Classify each selected shared contribution as ready, preparation-needed, or routed elsewhere, with owner, scope, roadmap, decision gap, participation mode, and artifact update made explicit.
How to facilitate
Use the preparation board row by row: initiative, roadmap/artifact, owner, affected scope, participation, key decision gap, and update owner.
Apply the READY / PREP / ROUTE gate visibly. The gate prevents weak community updates from occupying scarce conference time.
Turn missing ownership or low-confidence evidence into readiness-backlog items rather than pretending the topic is ready.
Listen and watch for
A shared topic with no named artifact update. If nothing changes, the conference will hear a presentation, not make progress.
Too many core invitees from expert groups; use preparation-only and standby paths for narrow questions.
Local work sneaking back in because people want visibility for their initiative.
Avoid
Routing a topic out as unimportant when it is actually unowned or underprepared. Mark the real reason.
Treating PREP as a polite green. PREP needs owner, date, and minimum quality.
Moving to tactical contributions without knowing which shared foundations will consume tactical capacity.
Facilitation
Make shared foundations concrete without creating a committee for every noun
IF THE LIST BECOMES DEPARTMENTS
Ask what several units must build, follow, evolve, or understand together. A department name is not an initiative.
IF “WE NEED A COP” IS THE FIRST ANSWER
Clarify the ownership and decision need first. Choose the lightest structure that can maintain the roadmap.
IF THE COMMUNITY HAS NO AUTHORITY
Name what it can recommend, what it can decide, and the escalation route for wider trade-offs.
IF THE ROADMAP IS A STATUS LIST
Add target condition, milestones, capacity, dependencies, decisions, adoption, and evidence.
IF EVERY EXPERT WANTS A CORE SEAT
Use preparation-only and standby paths. Keep core attendance for recurring context and decision ownership.
IF OWNERSHIP IS UNKNOWN
Do not hide the gap. Put owner selection and interim stewardship into the readiness backlog.
Ready to Move On?
Shared contributions are ready when their roadmaps can participate in a trade-off
Selected initiatives represent shared work rather than organizational labels.
Each initiative connects to a Flow problem, objective, or cross-unit decision.
A roadmap owner or explicit ownership network is named.
The delegated and non-delegated decision boundaries are visible.
The ownership pattern is no heavier than the work requires.
Foundation roadmaps show current and target conditions, milestones, dependencies, capacity, and adoption.
Open decisions have owners, dates, options, and consequences.
Core, window, standby, and preparation-only participation are intentional.
Every conference decision names the foundation artifact to update.
Missing owners or evidence are tracked in the readiness backlog.
Source Foundation
This page distills slides 32–34 of 2026-07-13_Value_Stream_Conference.pptx. The ownership-pattern and decision-record extensions help communities bring decision material instead of generic updates.