Back to lesson

Communicating Outcomes

Slide 1: Communicating Outcomes

On-screen

Communicating Outcomes

Tracking action items for accountability

Narration

Anna: This section sets up Communicating Outcomes. Treat it as the frame for the decisions, handoffs, and evidence that appear in the next slides.
Greg: The practical question is simple: by the end, what should a junior IT professional be able to explain, check, or document in a real workplace?

Slide 2: Why share outcomes?

On-screen

Why share outcomes?

  • Build trust by showing incidents are taken seriously and systematically addressed
  • Prevent repeats across teams by openly sharing root causes and fixes
  • Demonstrate accountability with owners and deadlines for each action item
  • Create an organizational memory of lessons learned for future reference
  • Meet compliance requirements such as ISO 27001 follow-up evidence
  • Example: After a database outage affecting 10k users, a summary email helped other teams spot similar risks in their own systems
  • Make the business impact clear so leaders can prioritise investments
  • Candid details build credibility even if everything isn't perfect

Narration

Anna: Once the dust finally settles—hopefully not literally falling from the ceiling onto your keyboard—it's tempting to simply move on.
Greg: We all want to forget the chaos, but if we don't discuss what happened, those same mistakes sneak back up on us.
Anna: This segment walks through why sharing the post-mortem results matters, how to keep different teams in the loop, and a few ways to make updates stick.
Greg: Think of it as sweeping up the debris, labeling the bags, and setting them out so everyone can recycle the lessons. Plus, a little openness keeps future dust from piling up again.

Slide 3: Communication timing and audiences

On-screen

Communication timing and audiences

  • Send an initial summary within 24 hours to leadership and directly impacted teams
  • Follow up weekly until all high-priority actions are closed
  • Tailor messaging: leadership wants business impact and timelines, technical staff need root cause details, customers need reassurance and next steps
  • Use dashboards or status pages for company-wide updates
  • Keep a single thread in Slack or Teams for ongoing questions
  • Reserve sensitive technical notes for internal docs and keep public messages short
  • Set expectations early by outlining major milestones and when each update will arrive
  • Invite questions so you can address them in subsequent follow-ups

Narration

Anna: The first message after a major incident should be short and clear. Think "Our database server went down at 1 pm, we restored service by 2 pm, here's what happened."
Greg: Attach or link to the post-mortem document so anyone who needs the gritty details can read them later.
Anna: Send a similar summary to leadership, but highlight the business impact, such as how many users were affected, and outline next steps.
Greg: For customers or non-technical audiences, focus on reassurance—we're monitoring closely and will share updates each week until all fixes are deployed.
Anna: Sharing in different channels—email, Slack, or a status page—keeps everyone aligned and sets expectations for follow-ups.

Slide 4: Track each action item

On-screen

Track each action item

  • Assign one owner and a clear due date so nothing gets lost
  • Capture items in a ticketing system like ServiceNow or GitHub
  • Example ticket: [OUT-123] Update database configuration – Owner: Lee, Due: 2025‑08‑01
  • Review progress in stand-ups and team meetings
  • Escalate to management when an item misses its deadline or stalls for a week
  • Write specific descriptions like "upgrade library X to version Y" rather than vague phrases
  • Link to relevant documentation or runbooks for more context
  • Check off each action when complete so progress stays visible
  • When new tasks emerge during remediation, create follow-up tickets right away

Narration

Anna: Once a post-mortem wraps, every action item needs a single owner and a real deadline.
Greg: Stick it in ServiceNow or a GitHub issue—somewhere visible—so it can't quietly tumble down a crack in the floor.
Anna: A good ticket includes the action description, an assignee and the target date, like [OUT-123] Update database config – Owner: Lee, Due: 2025-08-01.
Greg: Bring these items to daily stand-ups or weekly meetings. If progress stalls for a week, escalate early.
Anna: Cross each item off as it's completed, then pat yourself on the back before the next one tries to slip away. It's amazing how slippery those tasks can be.

Slide 5: Template examples

On-screen

Template examples

  • Email: "Team, our post‑mortem identified three fixes. See the attached doc for details. Jane owns the first, due Friday."
  • Slack: "Heads up: database patch rolling out tonight. Track progress in #incident‑123."
  • Dashboard update: Add a section summarizing closed and open items from recent incidents
  • Short, consistent templates make it easy for anyone to share updates without reinventing the wheel
  • A one-page summary template captures the incident, root cause, owners and due dates
  • Use a Slack snippet like /incident update to auto-fill your status channel
  • Maintain a wiki page with a table of updates for longer-running work
  • A simple table of item, owner, due date and status makes progress clear at a glance
  • Using the same structure across teams reduces confusion and speeds up handoffs

Narration

Anna: Template examples focuses attention on a concrete part of the work. Email: "Team, our post‑mortem identified three fixes. See the attached doc for details. Jane owns the first, due Friday.", Slack: "Heads up: database patch rolling out tonight. Track progress in #incident‑123.", and Dashboard update: Add a section summarizing closed and open items from recent incidents.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Slack: "Heads up: database patch rolling out tonight. Track progress in #incident‑123."; Dashboard update: Add a section summarizing closed and open items from recent incidents; Short, consistent templates make it easy for anyone to share updates without reinventing the wheel.

Slide 6: Close the loop

On-screen

Close the loop

  • Post updates in the original ticket or chat thread so everyone sees progress
  • Example update: "Patch deployed to production at 22:00 UTC. Monitoring shows no errors."
  • Note completed actions directly in the tracking system to keep records tidy
  • Revisit outstanding items at the next post-mortem and highlight improvements using metrics
  • When tasks drag on, call out the delay and reassign resources if needed
  • Celebrate completions with a quick thank-you to keep momentum going
  • Final message example: "Thanks for everyone's help—OUT-123 and OUT-124 are now closed."
  • Schedule a quick check-in a month later to confirm the fixes are holding
  • If open items stall, remind the team why they matter and escalate to leadership

Narration

Anna: Communication doesn't end once the meeting wraps up.
Greg: Keep posting updates in the same ticket or chat thread so there's a single place to see progress.
Anna: When a fix is deployed, share a quick note such as: "Patch deployed to production at 22:00 UTC. Monitoring looks good."
Greg: At the next post-mortem or weekly review, run through any unfinished items and highlight improvements backed by metrics.
Anna: If tasks stall, escalate or reassign them so they don't linger forever. Closing the loop shows you're serious about follow-through and prevents lingering action items from becoming new incidents. A quick thank-you also goes a long way in keeping momentum high.

Slide 7: Metrics and success measures

On-screen

Metrics and success measures

  • Track completion rate of action items over time to show improvement
  • Monitor recurrence of similar incidents to gauge effectiveness of fixes
  • Report average time from incident to final follow‑up
  • Display these stats on team dashboards or monthly review meetings
  • Measuring progress keeps everyone honest and celebrates wins when numbers trend in the right direction
  • Compare current metrics with past baselines to prove communication efforts are paying off
  • Include graphs of MTTR trends to highlight faster recovery
  • Track how many updates were sent for each incident to gauge responsiveness
  • Share success stories when metrics improve to motivate the team

Narration

Anna: When everyone knows the outcome and who's responsible for each fix, those improvements actually stick.
Greg: Documenting the steps in a shared place and checking back on them shows professionalism and builds confidence in the process.
Anna: It also prevents the dreaded "So whatever happened with that outage?" question from upper management.
Greg: Remind owners about upcoming deadlines and escalate only when absolutely necessary—a friendly nudge usually does the trick.
Anna: Open communication turns an unpleasant incident into an opportunity to improve and keeps you from repeating history.
Greg: Soon you'll have a track record of completing action items, which is the best proof that the post-mortem process works. So keep sharing updates, celebrate completed tasks and watch the trust in your team grow.

Slide 8: Key takeaway

On-screen

Key takeaway

Clear, timely communication and thorough follow‑up turn insights into real progress and demonstrate professionalism.

Narration

Anna: The key takeaway is this: Clear, timely communication and thorough follow‑up turn insights into real progress and demonstrate professionalism.
Greg: Use that takeaway to name the owner, evidence, and next action that should be visible after the work is done.