teamsuccess.io

Team Plays

These are plays I've run or been part of. Some work better than others. The point isn't the artefact you produce, it's the conversation the play forces.

Includes plays adapted from the Atlassian Team Playbook, Google re:Work, and Miro, along with established agile and management frameworks.

Manage risk

Risk Register Document, assess, and track risks before they become blockers.
60 min
  1. Brainstorm risksEach person silently lists every risk they can think of for the project.
  2. Group and deduplicateCluster similar risks together and remove duplicates.
  3. Score likelihood and impactRate each risk on a 1–3 scale for both dimensions.
  4. PrioritiseFocus on high-likelihood, high-impact risks first.
  5. Assign ownersEvery risk on the register has one person responsible for monitoring it.
  6. Define mitigation actionsFor each priority risk, agree on the steps that reduce likelihood or impact.
  7. Review regularlyCheck the register at every sprint review or project milestone.
Dependency Mapping Make cross-team and cross-system dependencies visible before they delay delivery.
60–90 min
  1. List work itemsCapture everything the team needs to deliver in the planning horizon.
  2. Identify dependenciesFor each item, ask: what do we need from another team or system before we can start?
  3. Map the connectionsDraw links between dependent items on a shared board.
  4. Estimate duration for each itemAdd a rough time estimate to every item. Without durations you cannot find a critical path, only a longest chain.
  5. Find the critical pathIdentify the path with the longest total duration across the network. This determines your earliest possible finish date. It is not the same as the chain with the most dependencies.
  6. Flag risksHighlight dependencies with unclear owners, missing agreements, or tight timing.
  7. Negotiate handoffsSync with dependent teams to confirm timing and agree on interfaces.
  8. Track throughout deliveryReview the dependency map at each planning cycle and update it as things change.
Pre-mortem Imagine the project has already failed. Prevent it.
60 min
  1. PrepCreate a board with columns for threats and strengths.
  2. Frame the promptAsk the team to imagine the project has gone wrong, or gone well.
  3. Brainstorm10 minutes of silent individual sticky note writing.
  4. GroupCluster similar ideas together.
  5. Vote on threatsThree votes each to prioritise the biggest risks.
  6. Vote on strengthsThree votes each to prioritise the most important success factors.
  7. Discuss10 minutes on each top item: develop mitigation strategies.
  8. Assign actionsEvery action item gets an owner and a deadline.
Incident Post-mortem Learn from what went wrong without assigning blame. Then fix the system.
60–90 min
  1. Prep the timelineBefore the session, reconstruct a factual timeline of the incident from logs and notes.
  2. Set the blameless normOpen with a reminder: the goal is to understand the system failure, not who failed.
  3. Walk the timelineReview the sequence of events together and fill in any gaps.
  4. Identify contributing factorsUse Five Whys to find underlying and contributing causes: technical, process, and communication failures. Complex incidents rarely have a single root.
  5. Celebrate what workedNote every decision that contained or shortened the incident.
  6. Define action itemsFor each contributing cause, agree on a concrete fix with an owner and a deadline.
  7. Share the reportShare internally with appropriate access. Redact personal, customer, security, and confidential information before circulating more widely.
Escalation Policy Define how and when issues get escalated so decisions don't stall.
45 min
  1. List decision typesIdentify the categories of decisions the team regularly encounters.
  2. Define thresholdsFor each type, agree on what conditions trigger escalation.
  3. Map escalation pathsDocument who to contact at each level: team lead, manager, exec.
  4. Set response time expectationsAgree on how quickly each level should respond.
  5. Document and shareWrite it up, put it somewhere accessible, and walk new team members through it.
  6. Test itRun a dry run with a hypothetical scenario to confirm everyone knows the process.
Incident Response Tabletop Rehearse a breach or major incident response before you need one.
90–120 min
  1. Choose the scenarioRealistic and relevant: ransomware, data exfiltration, insider misuse, a critical vendor breach, a lost laptop with production access. One scenario per session.
  2. Assemble the response teamSecurity lead, engineering on-call, legal, communications, data protection officer, executive sponsor. The people who would actually be on the bridge.
  3. Set the ground rulesThis is a rehearsal, not a test. Blameless, learning-focused. What people say stays in the room. Written notes for actions only.
  4. Walk the scenario in phasesDetection, containment, eradication, recovery, post-incident. At each phase, facilitator injects new information and asks: what do we do, who owns it, how long does it take?
  5. Test the decision pointsWhen do we notify customers? If the incident is a notifiable personal data breach under GDPR Article 33, when do we notify the supervisory authority (the 72-hour clock starts when the organisation becomes aware of the breach, and not every security incident qualifies)? When do we engage law enforcement? Who has authority to make each call?
  6. Stress-test communicationsWho drafts the customer notice, who approves it, who sends it. What goes on the status page. What sales tells prospects. Practice under time pressure.
  7. Capture gaps and actionsMissing runbooks, unclear ownership, tooling that failed, decisions that stalled. Each gap has an owner and a fix date.
  8. Schedule the next oneAnnually at minimum, quarterly for higher-risk businesses. Different scenario each time.

Align work to goals

OKRs Define what you want to achieve and how you'll know you got there.
60–120 min
  1. PrepShare the OKR framework and gather existing goals, roadmaps, and metrics beforehand.
  2. Define objectivesBrainstorm what the team wants to achieve this period: outcomes, not outputs.
  3. Set key resultsEstablish 3–5 measurable outcomes per objective.
  4. Create a scoring rubricDefine monthly milestones so 'on track' is unambiguous.
  5. Assign ownersDesignate someone responsible for tracking each key result.
  6. Review monthlyScore progress, document what moved, and explain why.
Vision Creation Create a shared picture of where the team wants to go.
90 min
  1. PrepShare relevant context, strategy documents, and customer insights beforehand.
  2. Brainstorm individuallyEach person writes their version of the future state.
  3. ShareEach person presents their vision in 2 minutes.
  4. Find common themesIdentify what appears across multiple visions.
  5. Draft togetherCo-write a single vision statement the team can commit to.
  6. Stress-testCheck it against your team's current work and customer needs.
  7. CommitDocument the vision and use it to evaluate future decisions.
Goals, Signals & Measures Get from vague ambitions to specific, measurable success criteria.
60–90 min
  1. Connect to the missionConnect the project to the team's broader mission.
  2. Brainstorm goalsIndividually generate possible goals on sticky notes, focusing on outcomes.
  3. PrioritizeSort goals into No / Maybe / Yes and pick the top three.
  4. Define signalsIdentify meaningful leading indicators of progress for each goal.
  5. Set measuresDefine specific, quantifiable success criteria for the planning horizon.
  6. Wrap upConfirm alignment and establish how you'll track and report progress.
DACI Get clear on who drives, approves, contributes, and is informed.
30–60 min
  1. Prep the documentSet up a DACI template in a shared tool.
  2. Assign a DriverOne person owns gathering input and running the decision meeting.
  3. Assign Approver and ContributorsIdentify who has final say and who advises.
  4. Add Informed partiesList everyone affected who should know the outcome but not decide.
  5. Document optionsFill in background, data, and all alternatives being considered.
  6. Gather input and decideShare with the team, explore all options, then make the call.
  7. Assign follow-upGive every next step an owner.
  8. Share the outcomeShare the decision and reasoning openly with everyone the decision affects.
Roles and Responsibilities Surface mismatches in who owns what before they cause problems.
60–90 min
  1. PrepShare the play with the team in advance so everyone arrives ready.
  2. List rolesEach person writes their role(s) in the shared document.
  3. Own responsibilitiesEach person lists their top 3–5 responsibilities.
  4. Guess teammates' responsibilitiesWrite your understanding of what each colleague owns.
  5. ClarifyReview feedback on your own role and accept or push back on what others listed.
  6. Fill gapsIdentify responsibilities that fall between or outside existing roles.
  7. Align and documentUpdate the shared document with agreed assignments.
Trade-off Sliders Make quality constraints explicit so scope decisions stop being arguments.
45–60 min
  1. List constraintsIdentify the key quality attributes for this project: scope, time, quality, cost, etc.
  2. Position privatelyEach person places sliders before anyone reveals their choices.
  3. Reveal and compareDisplay everyone's positions and discuss where they differ.
  4. NegotiateWork toward team consensus on where each slider sits.
  5. DocumentRecord the agreed positions and use them as a reference for future scope decisions.
Stakeholder Communications Plan Prevent surprises by designing your communication strategy upfront.
30–60 min
  1. PrepCreate a table documenting the project name, goals, and communication strategy.
  2. List stakeholdersIdentify contributors (active in the work) and beneficiaries (affected by the outcome).
  3. Fill the tableSpecify each stakeholder's information needs, preferred channel, and update frequency.
  4. Set up channelsAdd contacts to your project management tool and create a dedicated communication channel.
  5. Open the channelAnnounce the initiative and clarify how stakeholders should engage.
Network of Teams Map how teams depend on each other and surface gaps before they become blockers.
60–90 min
  1. Map your teamIdentify your team's goals, work outputs, and key interfaces.
  2. Identify connectionsList every team that gives you inputs or receives your outputs.
  3. Build the networkVisualise who depends on whom, using a shared whiteboard.
  4. Spot gaps and tensionsFind unclear handoffs, missing connections, and duplicated effort.
  5. Agree on normsEstablish how cross-team collaboration will work at each connection point.
  6. Follow upSchedule regular touchpoints with key partner teams.
Priority Mapping Get team consensus on what to work on first.
45–60 min
  1. List everythingCapture all tasks, features, or initiatives on separate cards.
  2. Set up the gridDraw a 2×2 matrix, commonly Impact vs. Effort.
  3. Map collaborativelyPlace each card on the grid together and discuss where people disagree.
  4. FocusStart with high-impact, low-effort items.
  5. Document togetherSave the map where everyone can reference it, and agree how you will revisit priorities as work changes.

Plan & track work

Project Kickoff Align everyone on why this project exists before the work starts.
60–90 min
  1. Identify rolesConfirm who is the sponsor, lead, core team, and stakeholders.
  2. Draft vision and missionWrite a destination statement the team can commit to.
  3. Sponsor welcomeHave the sponsor open the meeting with context and why this matters.
  4. Set ground rulesAgree on how to collaborate and make decisions together.
  5. Quick introsA round of introductions relevant to the project.
  6. Refine statementsBreak into groups to sharpen the vision, then reconvene and vote.
  7. Recap next stepsAssign someone to maintain the project poster and summarise commitments.
Project Poster One page that captures what you're building, why, and how you'll know it's done.
30–60 min
  1. Define the goalWrite one clear statement of what success looks like.
  2. List stakeholdersIdentify who is affected and who has decision authority.
  3. Document backgroundCapture what led to this project and why it matters now.
  4. Describe the approachOutline how the team will work and what constraints apply.
  5. Set measuresAgree on how you'll know it's done: use specific, checkable criteria.
  6. Commit to milestonesEstablish key checkpoints and review dates.
  7. Review togetherShare the draft with all stakeholders and get written alignment.
Working Agreements Make implicit norms explicit so the team can actually follow them.
90–120 min
  1. Facilitator prepCreate a template and share it before the session.
  2. Team prepEach person contributes preferences on hours, channels, feedback style, and personal context.
  3. Leader prepDraft the communication channels and escalation process sections beforehand.
  4. Open the sessionState the purpose, ground rules, and run a round of introductions.
  5. Edit communication channelsAlign the team on how and where to communicate.
  6. Define meeting normsAgree on when to meet synchronously vs. async.
  7. Refine escalationReview the leadership draft together and adjust until the team agrees.
  8. Plan for updatesAgree when and how to revisit these agreements.
Team Poster A one-page snapshot of who the team is and what they're working toward.
60 min
  1. Gather inputsCollect team goals, values, and roster beforehand.
  2. Write the missionDraft one sentence on why this team exists.
  3. List the teamAdd names, roles, and how to reach each person.
  4. State your goalsDocument three to five outcomes for the current period.
  5. Share itPost the poster where it's visible to the team and stakeholders.
  6. Revisit quarterlyUpdate it when goals, people, or priorities change.
Stand-ups Keep everyone aligned without burning time on a status meeting.
15 min daily
  1. Same time, same place15 minutes maximum, every working day.
  2. YesterdayEach person shares one thing they completed.
  3. TodayEach person shares one thing they'll work on.
  4. BlockersEach person flags anything stopping their progress.
  5. Park itMove any detailed discussions to a separate call. Protect the time box.
Weekly Team Updates Keep everyone informed with async updates instead of a status meeting.
15–30 min to write
  1. Choose a formatPick a simple template: what happened, what's next, blockers.
  2. Schedule itPick a consistent day and time so the team knows when to expect it.
  3. One author per updateRotate or assign a single person to write each week.
  4. Keep it briefOne short paragraph per area. Resist the urge to over-report.
  5. Make it asyncPost to a shared channel; don't read it aloud in a meeting.
  6. Act on blockersThe update's purpose is to surface issues, not just report status.
Page-Led Meetings Replace slide decks with a written page that everyone reads first.
45–60 min
  1. Write the pageDocument the context, decision, or discussion topic before the meeting.
  2. Distribute in advanceSend to all attendees at least 24 hours ahead.
  3. Start with silent readingBegin the meeting with 5–10 minutes of quiet reading.
  4. Discuss, don't presentSkip the slides and go straight to questions and decisions.
  5. Document outcomesUpdate the page with decisions and action items in real time.
  6. Close with next stepsEnd with clear owners and due dates.
Capacity Planning Make sure the work actually fits in the time available.
60 min
  1. List all upcoming workCapture every task and project for the planning period.
  2. Estimate effortAssign rough time estimates to each item.
  3. Map availabilityDocument each person's available hours for the period.
  4. AllocateAssign work items to people based on available capacity.
  5. Spot gapsIdentify overloaded people and unassigned work.
  6. RebalanceAdjust scope or assignments to fit realistic capacity.
IT Project Poster A lightweight brief that aligns business and technical stakeholders on IT initiatives.
30–60 min
  1. State the problemOne clear sentence on what's broken or missing.
  2. List stakeholdersIdentify business owners, technical leads, and affected users.
  3. Document constraintsCapture budget, timeline, compliance requirements, and dependencies.
  4. Define successMeasurable criteria for a successful delivery.
  5. Outline the approachHigh-level plan and key technical decisions.
  6. Track progressSchedule regular reviews against the poster throughout delivery.
End-to-End Demo Show the whole experience, not just the feature you built this sprint.
60 min
  1. Define scopeDecide what workflow the demo covers and who needs to see it.
  2. Write a user scenarioCreate a realistic story that exercises the full end-to-end flow.
  3. RehearseRun through it once internally to catch gaps and rough edges.
  4. PresentWalk stakeholders through the complete experience live.
  5. Capture feedbackNote questions and reactions during the session.
  6. Assign follow-upsGive every open item an owner and a due date.
Complex Software Projects Navigate large, multi-team software efforts with high uncertainty and many dependencies.
Ongoing
  1. Map the complexityIdentify all teams, systems, and dependencies involved. Make it visible.
  2. Decompose ruthlesslyBreak the project into independently releasable slices.
  3. Assign clear ownershipEach slice has one team and one decision-maker.
  4. Define integration pointsDocument every API, handoff, and shared assumption upfront.
  5. Set a short feedback cycleRelease something real every two weeks, no matter what.
  6. Run weekly cross-team syncs30 minutes maximum, focused on blockers only.
  7. Review and adaptHold a lightweight retrospective at every major milestone.
Steering Committee Design Set up the governance forum that keeps a program on track.
60 min
  1. Define the purposeSteering committees exist to make decisions the team cannot, unblock resources, and hold sponsors accountable. Write the purpose in one sentence.
  2. Choose the membersInclude the executive sponsor, functional leads whose work is in scope, and one program manager. Keep it small enough to actually decide.
  3. Set the cadenceMonthly for most programs, weekly for high-risk or launch phases. Long enough for real updates, short enough to stay relevant.
  4. Design the agenda templateStandard sections: program health (RAG), decisions needed, risks and blockers, upcoming milestones. No open discussion without a purpose.
  5. Define decision rightsWhat the committee decides on the spot, what it escalates, what it delegates back. Written down.
  6. Document and share outcomesEvery meeting has minutes with decisions, owners, and deadlines. Circulated within 24 hours.
Executive Status Report (RAG) One page that tells leadership what they need to know: is the program on track?
30 min to write
  1. Choose a consistent formatOne page. Same sections every time. Red / amber / green status for scope, schedule, budget, risk.
  2. Lead with the headlineOne sentence at the top: overall status and what changed since the last report.
  3. Explain any change from greenAmber and red statuses require an explanation, a proposed action, and a named owner. Not just a colour.
  4. List active risks and blockersTop three only. Include the mitigation plan and who is executing it.
  5. Upcoming milestones and asksWhat is coming up in the next 30 days and what you need from the executive audience.
  6. Send on a predictable cadenceWeekly or bi-weekly, same day and time. Executives learn to expect it and read it.
Change Management Plan Plan how the people affected by a change will move through it, not just the systems.
90 min
  1. Identify the changeBe specific about what is changing: a system, a process, a role, a policy. Vague changes fail.
  2. Map the affected audiencesFor each audience: what will change for them, what they will lose, and what they will gain.
  3. Build awarenessCommunicate the why before the what. People need to understand why the change is happening before they will engage.
  4. Create desireIdentify the personal wins for each audience. Change happens when people want it to, not when they are told to accept it.
  5. Provide knowledge and abilityTraining, documentation, coaching, and time to build competence in the new way of working.
  6. Reinforce the changeRecognise adoption, measure it, and address regression. Change is not complete at launch.
  7. Assign a change ownerOne named person owns the change plan and reports on adoption to the steering committee.

Solve problems

Retrospective Reflect on what happened and agree on what to improve next.
90 min
  1. Open blamelesslyRemind the team this is about improvement, not blame.
  2. Gather feedbackCollect what went well and what didn't, using 4Ls, Sad/Mad/Glad, or open discussion.
  3. Find patternsLook for recurring themes across the feedback.
  4. Create action itemsConvert insights into concrete changes with owners and deadlines.
  5. CloseRecap commitments and end on time.
Health Monitor Get an honest read on how the team is doing across eight dimensions.
90 min
  1. PrepShare the eight team health attributes with the team before the session.
  2. Rate privatelyEach person rates each attribute: Green / Amber / Red.
  3. RevealDisplay all ratings simultaneously and discuss where ratings diverge most.
  4. Note the greensConfirm what's working before diving into issues.
  5. Focus on reds and ambersChoose 1–2 attributes to actively improve this sprint.
  6. Agree on actionsAssign concrete steps with owners and a review date.
Problem Framing Define the real problem before jumping to solutions.
45–60 min
  1. PrepSet up a four-quadrant board (who, what, why, where) and share relevant data.
  2. Frame the goalClarify that the goal is to understand the problem, not solve it.
  3. Brainstorm10 min to add ideas across all four quadrants.
  4. Write the problem statementCraft one concise statement covering who is affected, what the problem is, why it matters, and where it occurs.
Five Whys Keep asking why to surface underlying and contributing causes.
30–45 min
  1. Define the problemWrite one clear problem statement the whole team agrees on.
  2. Ask whyIdentify the immediate cause of the problem.
  3. Ask why againDig one level deeper into that cause.
  4. Keep goingRepeat until you surface underlying causes, typically around five levels deep. Expect more than one causal chain in complex incidents.
  5. Address the underlying causesDesign fixes that target the underlying and contributing causes, not the symptoms.
  6. DocumentRecord the chains of whys and assign an owner to each fix.
Mind Mapping Explore a topic visually and surface connections you didn't expect.
45 min
  1. Central topicWrite the main subject in the centre of a blank canvas.
  2. First branchesAdd main themes radiating outward from the centre.
  3. ExpandBranch each theme into sub-ideas and connections.
  4. Free-associateKeep adding without filtering. Quantity first.
  5. ReviewStep back and look for unexpected patterns and connections.
  6. PrioritiseIdentify the strongest branches for follow-up action.
Learning Matrix A structured retrospective that focuses on what to carry forward.
60 min
  1. Set up the gridFour quadrants: Did Well / Learned / Ideas / Action Items.
  2. Silent brainstorm10 minutes for everyone to add sticky notes to each quadrant.
  3. GroupCluster similar items together as a team.
  4. VotePrioritise the most important items in each quadrant.
  5. ActionAssign owners and deadlines to the top action items.

Make AI part of the team

When using AI tools in these plays: use only tools approved by your organisation, do not input confidential or personal data, and review all AI-generated outputs before acting on them.

AI Solo Brainstorming Use AI to get unstuck and organise your own thinking, before involving the team.
75 min
  1. Use an approved tool and check what you can shareUse only an AI tool your organisation has approved. Do not input confidential, personal, or regulated data unless the tool and use are authorised for it. When in doubt, ask.
  2. Create your working pageSet up a document for the problem or project you're stuck on.
  3. Record your thoughts aloudTalk through the problem for 10–15 minutes using a video or audio tool.
  4. Ask AI to organisePrompt the AI tool to structure and summarise what you said.
  5. Verify the outputAI outputs can be wrong, biased, or fabricated. Check facts, names, numbers, and citations before relying on anything.
  6. Edit with your own judgmentRefine the AI output: remove the generic parts and add your context.
  7. Decide what the draft drivesDetermine what you'll do with the polished page next.
  8. Make it a ritualIdentify when this workflow will help you gain clarity again.
AI Team Kickoff Set shared norms for how AI fits into the team's actual way of working.
60 min
  1. Confirm AI literacyArticle 4 of the EU AI Act has required AI literacy for staff working with AI since 2 February 2025. Confirm everyone in scope has a shared baseline understanding of the tools, their limits, and the risks.
  2. Share contextBrief the team on the AI tools available and what they can do.
  3. Set data rulesAgree what data can and cannot be input into which tools: confidential, personal, customer, regulated, or source code. Reference the organisation's data classification policy.
  4. Name prohibited use casesCover Article 5 prohibitions and any organisation-specific red lines: no manipulation, no social scoring, no emotion recognition in the workplace, no using AI as sole basis for decisions that materially affect people.
  5. Agree on human review and responsibilityFor each use case, agree what human review looks like and who owns the decision. The human, not the AI, is accountable for the outcome.
  6. Map opportunitiesIdentify where AI could assist current workflows and reduce friction.
  7. Agree on normsEstablish when and how AI will be used, and when it won't.
  8. Choose a pilotPick one low-risk use case to try together first.
  9. Set a review dateSchedule a follow-up to evaluate what's working and adjust the norms.

Navigate the EU AI Act

The EU AI Act is being phased in through 2028. Prohibited practices apply since February 2025, GPAI model obligations since August 2025, Article 50 transparency from 2 August 2026, and high-risk obligations from 2 December 2027 (Annex III) and 2 August 2028 (Annex I product-integrated). Not a substitute for legal counsel.

AI System Risk Classification Determine your EU AI Act risk tier before building or deploying anything.
  1. List every AI systemGather all AI systems your organisation develops, deploys, or integrates, including internal tools and customer-facing products.
  2. Check for prohibited practicesReview each system against Article 5 prohibitions, in force since 2 February 2025: subliminal or deceptive manipulation causing harm, exploiting vulnerabilities, harmful social scoring, predicting crime from profiling alone, real-time biometric ID in public spaces by law enforcement, emotion recognition in workplaces and schools, biometric sorting by sensitive traits, and untargeted facial image scraping.
  3. Check the high-risk listsCompare each system against Annex I (AI in regulated products such as medical devices and machinery) and Annex III (high-risk sectors: recruitment, credit scoring, law enforcement, education, essential services, migration, justice).
  4. Flag GPAI involvementIdentify any system built on a general-purpose AI model such as Claude, GPT, Gemini, or Llama. GPAI model obligations apply since 2 August 2025.
  5. Determine your actor roleFor each system: are you a provider (you develop it and place it on the market), a deployer (you use it in your own operations), or both? Obligations differ significantly by role.
  6. Document the classificationRecord the risk tier and actor role for each system with the rationale. This becomes part of your compliance evidence.
  7. Assign a compliance ownerOne named person is responsible for each classified system and for keeping the classification current as the system evolves.
Prohibited Use Case Audit Check every AI use case against the practices banned since 2 February 2025.
  1. List all current and planned AI use casesInclude both internal tools and customer-facing products. Don't limit the list to what you think might be a problem.
  2. Check against each Article 5 prohibitionAI that uses subliminal or deceptive techniques to distort someone's decisions in a way that causes significant harm. Exploiting a person's age, disability, or socioeconomic situation to steer their behaviour. Social scoring that leads to unfavourable treatment based on someone's behaviour or personal traits. Predicting whether a specific person will commit a crime, based only on profiling or personality traits. Real-time facial or biometric identification in public spaces by law enforcement (narrow exceptions apply). Emotion recognition in workplaces and educational settings. Using biometrics to sort people by race, political views, religion, or sexual orientation. Untargeted scraping of facial images to build recognition databases.
  3. Flag close callsNote any use cases that approach but may not clearly cross a prohibition. These require legal review, not a team decision.
  4. Escalate close calls to legal counselDo not self-certify ambiguous cases. The fines for prohibited practice violations reach €35 million or 7% of global turnover.
  5. Document the outcome for each use caseMark each as: compliant, prohibited, or referred to legal. Keep the evidence.
  6. Schedule annual re-reviewUse cases change and regulatory guidance evolves. Put a review in the calendar now.
Article 50 Transparency Audit Check every AI touchpoint against the Article 50 transparency obligations applying from 2 August 2026.
  1. List all AI-powered user interactionsChatbots, virtual assistants, automated phone systems, AI-generated text, images, audio, and video in any customer or user-facing product.
  2. Chatbot and AI interface checkFor each system that interacts directly with users: confirm that users are told clearly, at the start of the first interaction, that they are talking to an AI, and that the disclosure is accessible. Exception: disclosure is not required when it is obvious to a reasonable person.
  3. Synthetic content checkFor systems generating synthetic text, images, audio, or video: confirm outputs are marked in a machine-readable format detectable as AI-generated. Article 50(2) exceptions include AI performing standard editing or non-substantial modifications, source code generation, and certain closed-loop or industrial contexts. Consult the guidelines before excluding a system. Systems already placed on the market before 2 August 2026 have until 2 December 2026 to comply with the marking obligation; systems placed on the market on or after 2 August 2026 must be compliant from day one.
  4. Review the EC guidelinesThe European Commission published final guidelines on Article 50 on 20 July 2026. Review them for your specific system type before finalising your approach.
  5. Document what is compliant and what needs a fixAssign an owner and a deadline to each gap. Penalties for Article 50 non-compliance reach €15 million or 3% of worldwide turnover.
  6. Set a review triggerAny new AI-powered feature that interacts with users should go through this checklist before launch.
GPAI Supply Chain Review Understand your obligations when your product is built on a general-purpose AI model.
  1. Identify every GPAI model in useList every general-purpose AI model your organisation uses, integrates, or fine-tunes: Claude, GPT-4, Gemini, Llama, Mistral, and others. GPAI model obligations have applied since 2 August 2025.
  2. Determine your role for eachThree roles are possible and the difference matters. GPAI model provider: you build the model itself, or change it significantly, and put it on the EU market. Downstream AI-system provider: you build a product on top of a GPAI model (including via API) and ship it under your own name. Deployer: you use an AI system in your own work. Calling an API and shipping the result to customers usually makes you a downstream provider, not a deployer. Provider obligations are heavier, so check carefully.
  3. Assess whether fine-tuning creates a new modelThe Commission's GPAI guidelines treat fine-tuning that uses more than about one-third of the original model's training compute as a signal that you have created a new model and become its provider. This is a Commission rule of thumb, not a hard line in the Act itself. What actually matters is how much the model changed, what it can now do, and how you release it. Treat serious fine-tuning as a legal question, not a compute calculation.
  4. Understand what Article 53 actually requiresGPAI providers must: (a) prepare technical documentation for the AI Office and national authorities; (b) make information and technical documentation available to downstream providers integrating the model; (c) put in place a policy to comply with EU copyright law; (d) publish a sufficiently detailed summary of the data used to train the model. Only (b) flows directly to you as a downstream integrator; the training summary is public, and the copyright policy is a provider obligation, not a deliverable.
  5. Check the systemic risk thresholdModels trained with more than 10^25 FLOPs are presumed to present systemic risk and face additional obligations under Article 55: adversarial testing, incident reporting, cybersecurity measures.
  6. Document your GPAI supply chainRecord each model, your role, what documentation you hold from the provider, and any gaps. This feeds into your overall compliance evidence.
High-Risk AI Requirements Workshop Walk the team through every obligation before building a high-risk AI system.
  1. Confirm high-risk classificationVerify that the system meets Annex I or Annex III criteria. Do not proceed with this play until classification is documented and agreed.
  2. Art. 9: Risk management systemAssign the owner and agree on how the continuous risk management process will run throughout the system lifecycle.
  3. Art. 10: Data governanceDefine how training, validation, and test data will be documented, monitored for bias, and managed for quality.
  4. Art. 11: Technical documentationAssign the Annex IV documentation owner and set a completion deadline. See the Technical Documentation Sprint play.
  5. Art. 12: LoggingConfirm the system automatically logs events so what happened can be traced later. Retention obligations sit in Articles 19 (providers) and 26 (deployers): at least 6 months unless other applicable law requires longer.
  6. Art. 13: Transparency to deployersAgree on what information will be included in the instructions for use so deployers can operate the system appropriately.
  7. Art. 14: Human oversightDesign the oversight mechanism. See the Human Oversight Design play.
  8. Art. 15: Accuracy and robustnessDefine accuracy metrics, robustness requirements, and resilience against adversarial inputs. Assign engineering owners.
  9. Assign owners and deadlinesEvery requirement has a named owner before the session ends.
Human Oversight Design Design meaningful human control over your AI system, not a checkbox.
  1. Define what the system decides vs. recommendsA recommendation is not the same as a decision. Clarify the boundary for your system.
  2. Map Article 14 requirements to your systemHigh-risk AI systems must enable human oversight to prevent or minimise risks. The system must be stoppable, interpretable, and overridable.
  3. Identify the human overseer for each decision typeWho is the human, what is their role, and what is the escalation path if they are unavailable?
  4. Design the interface and workflowWhat does the human actually see? What information do they need to make a real judgment? What action can they take?
  5. Define how to override or stop the systemEvery high-risk AI system must have a documented stop mechanism. Test it.
  6. Stress-test the oversightIs the human genuinely reviewing the output, or approving it reflexively? Design against rubber-stamping.
  7. Document the oversight mechanismThis goes into your technical documentation (Annex IV) and instructions for use (Art. 13).
Technical Documentation Sprint Build the Annex IV documentation your high-risk AI system legally requires.
  1. Pull the Annex IV checklistNine sections are required by Article 11 and Annex IV. Assign a section owner for each before the sprint starts.
  2. General descriptionIntended purpose, the version covered, how it interacts with other systems, and instructions for use.
  3. Development processDesign choices, training methodology, system architecture, and the training, validation, and test data used.
  4. Risk management documentationLink to the Article 9 risk register and evidence that risks have been identified, evaluated, and mitigated.
  5. Data and data governanceSources, preprocessing steps, data quality measures, and any known limitations of the dataset.
  6. Accuracy metrics and test resultsPerformance metrics and the conditions under which they were measured. Include results for relevant subgroups.
  7. Cybersecurity measuresHow the system is protected against adversarial attacks and unauthorised modification.
  8. Legal reviewConfirm the completed documentation meets Annex IV requirements before proceeding to conformity assessment.
Post-Market Monitoring Setup Establish the monitoring and incident reporting your AI system requires after deployment.
  1. Define what you will monitorPerformance drift, accuracy degradation, bias indicators, and any dimension that could affect the system's safety or fundamental rights impact.
  2. Confirm automatic logging is in placeArticle 12 requires the system to log events automatically so anyone can trace what happened. Retention is governed by Articles 19 and 26: at least 6 months unless other applicable law requires longer. Verify the capability is operational and retention is agreed.
  3. Define what counts as a serious incidentUnder Article 3(49) and Article 73, a serious incident is an event where the AI, working or malfunctioning, directly or indirectly causes: death or serious health harm; a serious and irreversible disruption of critical infrastructure; a breach of EU laws that protect fundamental rights; or serious harm to property or the environment. Document your threshold with examples specific to your system.
  4. Document the escalation and reporting pathWho gets notified internally, how quickly, and who is responsible for reporting to the national market surveillance authority.
  5. Check EU database registrationArticle 49 requires registering high-risk AI systems from Annex III in the EU database, but not every high-risk system, and not always in the public part. Systems in Annex III points 1 (biometrics), 6 (law enforcement), and 7 (migration, asylum, border control) go in a non-public section that only the Commission and designated national authorities can see. Public bodies using an Annex III system also have their own registration duty. Before you launch: check whether registration applies, which section it goes in, and who files it.
  6. Assign the monitoring ownerOne named person is responsible for ongoing regulatory monitoring and for triggering the escalation path when needed.
  7. Schedule the first post-market reviewSet a date before the session ends. Don't leave it as an open commitment.
Disclaimer & attribution

These plays are team facilitation guides for product, engineering, and program teams. They are not legal, financial, or professional advice.

The EU AI Act plays reference the current text of Regulation (EU) 2024/1689 and European Commission guidance available at the time of writing. Regulatory guidance evolves, and interpretation of specific obligations depends on your organisation's context. Consult qualified legal counsel before making compliance decisions.

Individual plays are adapted from the Atlassian Team Playbook, Google re:Work, Miro, and established agile and management frameworks. Original methodologies were developed by their respective creators, including Andy Grove (OKRs), Intuit (DACI), Jeff Sutherland and Ken Schwaber (Scrum), Tony Buzan (mind mapping), and Gary Klein (pre-mortem), among others.

No warranty is made regarding accuracy, completeness, or fitness for a particular purpose. Use at your own discretion.

← Back to portfolio