Same sessions, same objectives, same live time. What changes per track is scenario complexity, the analogies used, and the starting assumptions the facilitator makes about prior knowledge.
Track A
Data-experienced
Data Scientists, Analysts, BI Developers. Comfortable with data tools. Gap is governance framing, not data literacy.
Track B
Business-experienced
Sales, Operations, Project Management. Strong domain knowledge. Gap is both governance framing and data confidence.
What changes per track — select a session
Pre-programme · diagnostic
Questions focus
Emphasis on governance accountability and role boundaries — tests what they assume about ownership
Skips basic data literacy questions — assumes competence
Includes basic data confidence questions — do they open Power BI, read reports, work with data definitions
Identifies specific tool anxiety so facilitator can calibrate session 2 language
Segmentation trigger
Scores high on data familiarity → Track A confirmed
Scores low on data familiarity OR flags discomfort with data tools → Track B confirmed
Same 10 questions for everyone. Track is determined by responses, not job title. A Data Analyst who hasn't worked with governance tools lands in Track B. A Sales Manager who runs their own reporting lands in Track A.
Session 1 · 90 min live · what you are now accountable for
Scenario complexity
Edge cases with ambiguous overlap — e.g. a quality issue that could belong to Steward or IT depending on root cause
Assumes familiarity with data systems and pipeline concepts
Grounded in business processes — e.g. a reporting inconsistency caused by two teams using different definitions of the same term
Roles described by what they decide, not what tool they use
Facilitator framing
"You already understand the data — this role is about governance authority, not technical skill"
"Your business knowledge is the asset here. This role doesn't require you to become a data expert — it requires you to make decisions about data in your domain"
Common error to surface
Assuming technical ability equals governance authority — Track A often assigns ownership to the most technically capable person, not the most accountable one
Deferring everything to IT — Track B often assigns all three columns to IT, assuming data problems require technical solutions
Same 12-scenario sort for both tracks. Same 90-minute live session. Different scenario bank — Track A scenarios involve system-level ambiguity, Track B scenarios involve business process ambiguity. Both produce genuine disagreement.
Session 2 · 90 min live · making real decisions with consequences
Scenario framing
Access request: a data engineer wants to connect a new analytics tool to production data — weigh technical benefit against compliance risk
Language assumes familiarity with data lineage, access control, API connections
Access request: a sales team wants to share customer data with a marketing agency — weigh business opportunity against data protection obligations
Business process framing — no system or technical terminology assumed
Failure state emphasis
A governance breach discovered in an audit 3 months later — resonates with data professionals who understand audit trails
A client complaint and regulatory fine 3 months later — resonates with business managers who understand operational and reputational risk
Pre-work framing
Scenario summaries use technical shorthand — participants expected to interpret without a glossary
Scenario summaries include a plain-language definition of any governance term used
Same three decision types — access request, quality escalation, policy conflict. Same 90-minute live session. Same failure state mechanic. Different scenarios, different language, different consequence framing. The learning outcome is identical.
Session 3 · 75 min live · governance conversations that actually work
Role-play scenario
Data Steward escalates a data pipeline issue producing incorrect figures in a BI report — Data Owner must decide: system fix or definition fix
Data Steward escalates that two teams are reporting different figures for the same metric in the monthly review — Data Owner must facilitate a cross-department resolution
Guest framing
Guest asked specifically about navigating the boundary between technical authority and governance authority — a tension Track A feels acutely
Guest asked about building confidence to make data decisions without deferring to IT — the core anxiety for Track B
Same session structure, same 75 minutes, same communication template. The guest is the same person for both tracks — they prepare two sets of talking points. The skill being practised is identical: handling an escalation and communicating a decision clearly.
Session 4 · half day · cross-role simulation — all tracks together
What each track brings
Technical fluency — tend to focus on system-level solutions, may underweight business impact of decisions
Business fluency — tend to focus on client and operational impact, may underweight technical feasibility
Why mixing is intentional
A Track A Data Steward and a Track B Data Owner will approach the definition conflict differently. That difference is the learning.
By session 4 both tracks share enough language to collaborate. The simulation works better with mixed tracks — real organisations are always mixed.
Facilitator calibration
If Track A dominates: ask business-experienced participants directly — "From a client perspective, what matters most here?"
If Track B dominates: ask data-experienced participants directly — "What would need to be true technically for this to work?"
Session 4 is the only session where tracks deliberately mix. The same scenario brief is used for all participants regardless of track. The facilitator guide includes prompts for rebalancing if one perspective is dominating.