Ten modules, a hundred days, one page at a time. Each day gives you the
idea, a worked case file, the trap that catches people out, and the one
line to remember. Work it in order, or jump straight to what you need.
Day 01 / 100 · Why it matters · What cognitive health means at work
Healthy teams think well.
Cognitive health at work is a team's capacity to focus, reason, learn and recover, plus the conditions that protect it. It's a design problem, not a wellness perk.
Focus
Can We Hold Attention?
Time for deep work actually exists
Interruptions are the exception
Judgement
Do We Reason Well?
Claims get checked, not just accepted
Decisions have a visible "why"
Learning
Do We Get Better?
Skills grow, even with AI in the loop
Mistakes turn into shared lessons
Recovery
Do We Bounce Back?
Peaks are followed by recovery
Pace is one the team can sustain
Protect how the team thinks, not just what it ships.
Day 02 / 100 · Why it matters · Attention as a resource
Attention is the budget.
Every team has a limited daily supply of focused attention. Meetings, pings and task switching all spend it, usually without anyone approving the spend.
Invest
Deep Work
“This moves the outcome.”
Design, coding, analysis, writing
Needs long, unbroken blocks
Where the real value is made
Spend
Collaboration
“This keeps us aligned.”
Reviews, planning, 1:1s
Necessary, but never free
Worth it when it has a purpose
Leak
Fragmentation
“Quick question…”
Pings, switching, status chasing
Small drips, big daily total
Nobody ever budgets for it
Budget attention like money.
Day 03 / 100 · Why it matters · Types of cognitive load
Not all load is bad load.
Cognitive load theory splits mental effort into three kinds. Healthy teams manage the first, remove the second and protect the third.
Intrinsic
The Problem Is Hard
Manage it.
Built into the work itself
Chunk it, pair on it, sequence it
You can shape it, not delete it
Extraneous
The Friction Around It
Remove it.
Vague tickets, flaky builds
Too many tools and handoffs
Pure cost, zero value
Germane
The Effort Of Learning
Protect it.
Building mental models
Understanding the system deeply
First to go when time is tight
Cut the friction. Keep the challenge.
Day 04 / 100 · Why it matters · AI-era pressure
Faster tools. Heavier heads.
AI speeds up output, but it moves the load rather than removing it. Four shifts are landing on teams right now.
Writing → reviewing
More To Check
Drafts arrive in seconds
Judging them still takes time
Finding → verifying
More To Trust Or Not
Answers are instant and confident
Checking them is on you
Effort → expectation
More Pressure
“Surely AI makes this quick?”
Estimates shrink, the risk doesn't
Scarcity → overload
More To Filter
Summaries of summaries
Signal gets lost in the volume
AI moves the work. It doesn't remove it.
Day 05 / 100 · Why it matters · Knowledge-work fatigue
Tired brains still show up.
Knowledge-work fatigue builds quietly. It shows up in the work, through slower calls and more rework, before anyone says they're tired.
Decision load
Too Many Small Calls
Shows up as…
Defaulting to “whatever”
Deferring decisions
Rubber-stamp reviews
Switching load
Too Many Contexts
Shows up as…
Half-finished work piling up
Missed details
“Where was I?”
Always-on load
No Clean Stop
Shows up as…
Late-night replies
Weekend “quick checks”
Flat energy on Mondays
Design for the tired version of your team.
Day 06 / 100 · Why it matters · Signs of an overloaded team
Overload leaves tracks.
Teams rarely announce they're overloaded. The signs show up first in the work, the conversations and the calendar.
In the work
What You Can See
Rework and escaped bugs rising
WIP growing, little finishing
Estimates quietly slipping
In the room
What You Can Hear
Retros go quiet
More “it's fine”
Less challenge, more nodding
In the clock
What The Timestamps Say
Messages late at night
1:1s and learning time cancelled
Leave not being taken
Watch the work, not just the words.
Day 07 / 100 · Why it matters · Team vs individual responsibility
The team owns the system.
Individuals can build good habits, but they can't fix a broken system on their own. Be clear about who owns what.
Leaders own
The Conditions
Priorities and workload
Staffing and on-call design
What gets rewarded
The team owns
The Norms
Meeting and chat habits
How work gets handed off
Calling out overload early
You own
Your Practices
Your boundaries and focus
Speaking up and asking for help
Using the norms the team agreed
Fix the system before coaching the person.
Day 08 / 100 · Why it matters · Not clinical: when to refer
Know where your role ends.
This playbook covers team practices. Some situations need a professional. Good managers know the difference, and act on it.
Team issue
You Can Fix This
Workload, clarity, process
Meeting load, focus time
Use the playbook
Grey zone
Talk Privately
Persistent change in someone
Withdrawal, distress, struggling
Listen, ask, don't diagnose
Refer
Get Professional Help
Point to an EAP, HR, or a GP or therapist
In a crisis or danger: emergency services
Keep supporting at work
Notice. Ask. Refer. Don't diagnose.
Day 09 / 100 · Why it matters · Leaders set the weather
Leaders set the weather.
Teams copy what leaders do, not what they say. Your habits quietly become the team's norms.
What you model
They Watch
“When does the boss log off?”
Your hours and response times
Whether you take leave
How you handle pressure
What you reward
They Learn
“What gets praised here?”
Heroics or prevention?
Speed or sustainable pace?
Answers or good questions?
What you react to
They Remember
“Is it safe to bring bad news?”
Your face when things go wrong
Blame or curiosity?
Who gets interrupted
Your habits become the team's norms.
Day 10 / 100 · Why it matters · Team cognitive health check
Take the team's pulse.
Four statements, scored 1 to 5, anonymously, once a month. It's cheap, quick, and a conversation starter rather than a verdict.
Focus
Statement 1
“I had enough uninterrupted time for my hardest work.”
Low score? See Module 4
Judgement
Statement 2
“I felt able to question decisions, and AI output.”
Low score? See Modules 2 and 6
Learning
Statement 3
“I got better at something this month.”
Low score? See Module 7
Recovery
Statement 4
“My workload felt sustainable.”
Low score? See Module 5
Measure. Discuss. Change one thing.
Module 2Critical thinkingDays 11–20
Day 11 / 100 · Critical thinking · Thinking in the AI era
Instant answers. Slow thinking.
When answers cost nothing, the scarce skill is judging them. AI sounds equally confident whether it's right or wrong.
Let AI…
Speed Work
Draft, summarise, reformat
Generate options to react to
Explain unfamiliar code
Check…
Trust Work
Facts, figures and sources
Edge cases and security
Anything customer-facing
Keep human…
Judgement Work
Trade-offs and priorities
Context AI can't see
Accountability for the call
Use AI for speed. Keep judgement for you.
Day 12 / 100 · Critical thinking · Claims and evidence
Every claim needs a receipt.
Opinions, stories and data all have a place, but they aren't equal. Name which one you're holding before you act on it.
Opinion
“I Think…”
A starting point, not a conclusion
Ask: what would change your mind?
Anecdote
“A Customer Said…”
Real but narrow; great for questions
Ask: how often does this happen?
Data
“The Logs Show…”
Broader, but check how it was collected
Ask: what is this not measuring?
Test
“We Tried It And…”
Strongest when it was set up fairly
Ask: what else could explain this?
Ask: how do we know?
Day 13 / 100 · Critical thinking · Cognitive biases at work
Your brain takes shortcuts.
Biases aren't character flaws. They're mental shortcuts that misfire. Four of them show up in almost every team.
Good thinking doesn't survive on good intentions. Attach it to meetings the team already has.
Stand-up
Daily · 1 Min
“Which assumption are we testing today?”
Links from Day 14
Planning
Per Sprint · 10 Min
A pre-mortem on the biggest item.
Links from Day 17
Review
Every Pr / Doc
“How do we know?” on every claim.
Links from Days 12 and 19
Retro
Monthly · 15 Min
Revisit one decision journal entry.
Links from Day 18
One ritual, done every time.
Module 3Cognitive offloadingDays 21–30
Day 21 / 100 · Cognitive offloading · What cognitive offloading is
We've always outsourced thinking.
Cognitive offloading means using tools or the world around you to reduce mental effort. Lists, calculators and search all count. AI just widens what we can hand off.
Memory
Remembering For Us
Notes, calendars, runbooks
Frees working memory
Low risk if well kept
Calculation
Computing For Us
Calculators, scripts, queries
Faster and more accurate
Still need to sanity-check
Reasoning
Thinking For Us
AI drafts, summaries, code
New, and powerful
The hardest to verify
Offload the load, not the understanding.
Day 22 / 100 · Cognitive offloading · Good vs risky offloading
Hand off the chore, not the core.
Some work is safe to offload completely. Some needs a check. Some should stay in human heads. Decide by risk, not convenience.
Offload freely
Low Stakes · Easy To Check
Boilerplate and formatting
Test data and scaffolding
Summaries of things you know
Offload + check
Medium Stakes
SQL and migrations
Config and infrastructure changes
Customer-facing drafts
Keep human
High Stakes · Hard To Verify
Architecture and trade-offs
Security and PII decisions
Commitments to people
Offload by risk, not by convenience.
Day 23 / 100 · Cognitive offloading · Skill atrophy
Use it or lose it.
Skills you don't practise fade. Aviation learned this early: heavy reliance on autopilot can erode manual flying skills. Software teams are next.
Convenience
Stage 1
“It's faster with the tool.”
You could do it yourself
You choose not to
Reliance
Stage 2
“It's easier than remembering.”
Doing it yourself feels slow
Confidence starts slipping
Dependence
Stage 3
“I can't do it without it.”
The skill is gone
You find out at the worst time
Know which skills you can't afford to lose.
Day 24 / 100 · Cognitive offloading · Automation bias
The tool said so. So it's right?
Automation bias is the tendency to over-trust automated output, even when other evidence says otherwise. It comes in two forms.
Commission
Doing What It Says
“The assistant suggested it.”
Following wrong advice
Overriding your own judgement
Omission
Missing What It Didn'T Flag
“Nothing came up, so it's fine.”
Silence treated as all-clear
Checks quietly stop happening
Why it happens
The Root Causes
“It's usually right…”
Trust builds from past accuracy
Checking feels like wasted effort
The tool is a second opinion, not the final word.
Day 25 / 100 · Cognitive offloading · Verify before you trust
Verify, then trust.
Checking everything the same way burns people out. Checking nothing is how mistakes ship. Scale the check to the stakes.
Every team has a handful of skills it can't afford to lose, tools or no tools. Name them, practise them, and spread them.
Name them
Step 1
List 5–8 skills the team must own
e.g. debugging, SQL, reading code
Practise them
Step 2
Regular reps, not occasional heroics
See Day 27: AI-free reps
Spread them
Step 3
No skill held by one person
Pair across experience levels
Check them
Step 4
Self-rate confidence each quarter
Watch for skills trending down
Name the skills you must keep. Then practise them.
Day 27 / 100 · Cognitive offloading · AI-free reps
Practise without the net.
Athletes train without the aids they compete with. Short, deliberate reps without AI keep the underlying skill alive.
What
Small &Amp; Deliberate
A bug, a query, a design sketch
Real work, sized to 30–45 min
Targets a core skill (Day 26)
When
Low Stakes
Never on a deadline
Regular, like a fortnightly slot
Opt-in, not enforced
How
Try First, Then Compare
Solve it yourself first
Then ask the AI
Compare: what did it see that you missed?
Try first. Then compare.
Day 28 / 100 · Cognitive offloading · Juniors learning alongside AI
Learn the why, not just the what.
AI can make juniors productive on day one, and stop them from ever building the understanding that makes them senior.
The risk
Skipping The Struggle
The struggle is where learning happens
Output without a mental model
Stuck when AI is wrong
The guardrails
Explain It Back
Explain every line before merging
Ask AI to teach, not just produce
Try first on learning tasks
The mentor
Review The Reasoning
Pair regularly
Ask “why this way?” in review
Share how you think, not just fix
Speed is not the same as skill.
Day 29 / 100 · Cognitive offloading · Team norms for AI use
Agree the rules together.
Without shared norms, every person makes up their own, and the gaps are where the risk lives. Four questions cover most of it.
Where it's welcome
Go Ahead
Drafts, tests, refactoring, research
Which tools are approved
Where it needs a check
Use, Then Verify
Production code, config, customer copy
Who checks, and how (Day 25)
Where it's off-limits
Don'T
Customer PII in public tools (POPIA)
Final calls on people or security
How we disclose
Be Open
“AI-assisted” noted in PRs and docs
No shame, just context for reviewers
Agree it together. Write it down.
Day 30 / 100 · Cognitive offloading · An offloading audit
Know what you've handed off.
Offloading creeps up quietly. Once a quarter, take stock of what the team has handed to tools, and what that's costing.
What?
Question 1
What are we offloading now?
List every AI-assisted task
Could we?
Question 2
Can we still do it without the tool?
Yes · Slowly · No
What if?
Question 3
What breaks if the output is wrong?
Low · Medium · High (Day 22)
So?
Question 4
Keep, add a check, or add reps?
One action per risky item
Know what you've handed off.
Module 4Focus & deep workDays 31–40
Day 31 / 100 · Focus & deep work · The cost of context switching
Every switch has a toll.
Switching between tasks costs time to reorient, and more so as the tasks get more complex. Part of your mind also stays behind on the last one.
Switch cost
Time To Reorient
“Right, where was I?”
Reloading goals and rules
Grows with task complexity
Rubinstein, Meyer & Evans, 2001
Attention residue
Part Of You Stays Behind
“Still thinking about that call…”
The last task lingers
Worse when it's unfinished
Sophie Leroy, 2009
Open loops
Half-Done Piles Up
“I'll finish it later.”
Many things started
Few things finished
Each one takes mental space
Fewer switches. More finished.
Day 32 / 100 · Focus & deep work · Maker vs manager schedules
Respect the half-day.
Paul Graham's 2009 essay named it: managers work in one-hour slots, makers in half-days. A single meeting costs them very different amounts.
Manager schedule
The Hour Is The Unit
“Just another slot.”
Meetings are the work
Switching is normal
30 min costs 30 min
Maker schedule
The Half-Day Is The Unit
“That meeting ruined my afternoon.”
Building needs long runs
Start-up time is high
30 min can cost 3 hours
Bridging
Design For Both
“Meet at the edges.”
Meetings next to lunch or end of day
Manager office hours
Batched meeting days
Respect the half-day.
Day 33 / 100 · Focus & deep work · Focus blocks
Same time. Whole team. Defended.
Individual focus blocks get booked over. Team-wide focus blocks, at the same time for everyone, survive because nobody is left to interrupt.
Size it
Long Enough To Matter
Two hours or more
Mornings, for most teams
Two or three a week to start
Shield it
Visible &Amp; Blocked
Calendar-blocked for all
Status on, notifications off
Meetings can't be booked in
Share it
Everyone At Once
No one left to ping you
Leaders join in too
Urgent path agreed (Day 40)
Same time. Whole team. Defended.
Day 34 / 100 · Focus & deep work · Notification hygiene
Make urgent rare and loud.
Tools make every ping feel urgent. Most aren't. Clean notifications make the truly urgent ones stand out.
Kill
Turn Off The Noise
Non-essential app alerts off
Mute busy channels by default
Batch
Check On Purpose
Email and chat at set times
Not a constant background drip
Route
Urgent Gets Its Own Path
Incidents go to pager or phone
Not the same channel as “FYI”
Signal
Show Your State
Focus status visible to all
People know when to wait
Make urgent rare and loud.
Day 35 / 100 · Focus & deep work · Async by default
Answer when you surface.
Asynchronous work, done in writing with time to respond, protects focus. Real-time is for the things that need it.
Default async
In Writing
Status updates
Questions that can wait hours
Reviews and feedback
Go sync when…
Real-Time Is Worth It
Conflict or strong feelings
Ambiguity after two rounds
It's genuinely urgent
Response windows
Agreed, Not Assumed
e.g. same day, not same minute
Urgent has its own path
Silence ≠ ignored
Write it down. Let people answer when they surface.
Day 36 / 100 · Focus & deep work · The meeting diet: how much time meetings get
Put meetings on a diet.
Today is about how much. Who speaks is Day 57, and how a meeting runs is Day 72. Meetings are easy to add and awkward to remove, so they pile up.
Audit
See The Total
List every recurring meeting
Owner, purpose, attendees
Hours per person per week
Cut
Default To Less
No owner or purpose? Delete
Shorter by default
Fewer attendees, notes shared
Cap
A Weekly Budget
A team limit on meeting hours
New meeting means one goes
Review it every quarter
Every meeting needs an owner and a reason.
Day 37 / 100 · Focus & deep work · Chat without constant pings
One message. The whole question.
Chat is useful until it becomes a stream of interruptions. A few habits keep it from eating everyone's attention.
Say it all at once
No “Hi” Then Wait
Question, context and deadline in one go
They can answer without replying “yes?”
Thread it
Contain The Conversation
Replies in threads, not the channel
Only followers get pinged
Mention with care
@ Is A Tap On The Shoulder
@channel for true emergencies only
Tag one person, not five “just in case”
Right channel
Topic, Not Firehose
Clear channel purposes
Urgent lives elsewhere (Day 34)
One message. Whole question. No ping unless it matters.
Day 38 / 100 · Focus & deep work · Single-tasking
One thing. Then the next.
For attention-demanding work, people don't really multitask. They switch quickly, and pay for every switch. Single-tasking is a skill teams can design for.
One now
A Personal Wip Limit
One active task
Everything else is queued
Visible on the board
Park the rest
Capture, Don'T Carry
A quick-capture list
Ideas out of your head
Review at natural breaks
Checkpoint
Leave A Note When You Switch
“Where I am”
“Next step is…”
Makes coming back cheap
One thing. Then the next.
Day 39 / 100 · Focus & deep work · Protecting flow
Design for flow. Don't just hope.
Flow, the absorbed state Mihaly Csikszentmihalyi described, isn't luck or personality. It depends on conditions, and teams can build those conditions.
Clear goals
Know What “Done” Is
Well-shaped tickets
Acceptance criteria up front
No mid-task guessing
Fast feedback
See Results Quickly
Quick builds and tests
Hot reload, local environments
Short review cycles
Right challenge
Stretch, Not Snap
Too easy leads to boredom
Too hard leads to anxiety
Match work to skill
Design for flow. Don't just hope.
Day 40 / 100 · Focus & deep work · Focus agreements
Agree when to focus, and how to break it.
A focus agreement is a one-page team pact. It pulls together the whole module, and it rolls into the team operating manual on Day 91.
Focus time
When
Shared focus blocks (Day 33)
Meeting-free zones (Day 36)
What's urgent
The Escape Hatch
What counts as urgent
How to reach someone mid-focus
Response windows
How Fast
Chat, email, reviews (Day 35)
Silence doesn't mean ignored
Chat & alerts
How
Mention and channel rules (Day 37)
Notification defaults (Day 34)
Agree when to focus, and how to break it.
Module 5Pace & sustainabilityDays 41–50
Day 41 / 100 · Pace & sustainability · AI-era pace
Faster isn't free.
AI speeds up some of the work. Expectations tend to rise faster than capacity does, and the gap lands on people.
Expectation creep
“Surely That'S Quick Now?”
Deadlines shrink on assumption
Estimates get second-guessed
The pressure is felt, not measured
Uneven speed-up
Some Steps, Not All
Drafting and coding speed up
Review, decisions and testing don't
Bottlenecks move downstream
Change load
New Tools Every Month
Constant learning curve
Workflows keep shifting
A hidden tax on attention
Plan on real capacity, not the demo.
Day 42 / 100 · Pace & sustainability · Sustainable pace
A pace you could keep forever.
The Agile Manifesto asks for a pace teams can “maintain indefinitely”. Here's the cognitive-load lens on that. The delivery angle lives in the Agile & Delivery pillar.
Steady
No Sprint-And-Crash
Similar load week to week
No hero weeks followed by slumps
Attention budget not overdrawn
Predictable
Plans That Hold
Commitments mostly met
Fewer surprise evenings
Less anxiety about the next ask
Recoverable
Peaks Have A Payback
Recovery after a push
Slack in the plan
Space to learn and tidy
A pace you could keep forever.
Day 43 / 100 · Pace & sustainability · The overtime myth
Hours in isn't value out.
Economist John Pencavel's 2014 study of historical munitions workers found output per hour falling steeply beyond about 50 hours a week. More hours bought little extra.
Short bursts
Can Work
A few days, for a real reason
Chosen, not expected
Followed by time back
Sustained overtime
Backfires
Output per hour falls
Tired minds make more mistakes
Rework eats the “gain”
Hidden costs
Not On The Timesheet
Errors and escaped bugs
Lost learning and slack
Attrition and quiet quitting
Hours in isn't value out.
Day 44 / 100 · Pace & sustainability · WIP and overload
Stop starting. Start finishing.
Too much work in progress slows delivery (Little's Law) and loads every head with open loops. Here's the cognitive-load view. Flow metrics live in the Agile & Delivery pillar.
Slower
More Wip, Longer Waits
Cycle time = WIP ÷ throughput
Everything takes longer
Feedback arrives late
Switchier
More Wip, More Juggling
Every item competes for focus
Constant context switching
See Day 31
Heavier
More Wip, More To Hold
Every open item is a thing to remember
A mental tax, even when idle
Anxiety about what's stuck
Stop starting. Start finishing.
Day 45 / 100 · Pace & sustainability · Recovery during the workday
Rest is part of the work.
Recovery isn't only for weekends. Research on micro-breaks links short pauses to less fatigue and more energy across the day.
Micro-breaks
Minutes, Often
Stand, stretch, look away
Between tasks, not mid-flow
Not a scroll through chat
A real lunch
Away From The Screen
Not at the desk
Not in a “working lunch”
Outside if you can
Hard stops
A Clean End
Write tomorrow's first step
Close the laptop
Notifications off after hours
Rest is part of the work.
Day 46 / 100 · Pace & sustainability · When overload persists: burnout signals and escalation
When overload persists.
The WHO defines burnout as an occupational phenomenon, caused by chronic workplace stress that hasn't been managed. It builds on Day 6's signals, and Day 8 still sets the limits of your role.
Exhaustion
Dimension 1
At team level, look for…
Energy flat for weeks
Leave piling up, or sick days rising
Cynicism
Dimension 2
At team level, look for…
“What's the point?”
Withdrawal from retros and chat
Reduced efficacy
Dimension 3
At team level, look for…
Quality slipping
Confidence and initiative dropping
Persistent signals need system changes.
Day 47 / 100 · Pace & sustainability · Workload conversations
Talk trade-offs, not toughness.
“Can you take this on?” invites a yes. Good workload conversations make all the work visible, and talk about what moves.
Make it visible
See All The Work
Projects, support, meetings, admin
On one board or one list
Invisible work counts too
Trade-offs
“If This, Then What?”
New work means something moves
Name it explicitly
The decision sits with the requester
Regular
Not Only In A Crisis
A standing 1:1 question
Monthly team capacity check
Early and boring beats late and dramatic
Ask what moves, not if they can cope.
Day 48 / 100 · Pace & sustainability · Saying no
Every yes is a no to something.
Teams that can't say no end up saying yes to everything and delivering everything late. There are kinder shapes of no than a flat refusal.
“No, because…”
The Priority No
“Not this quarter. It doesn't serve the goal we agreed.”
Anchored to shared priorities
“Yes, if…”
The Trade-Off No
“Yes, if we drop X. Your call.”
Hands the choice back
“Not now; when…”
The Timing No
“After the release: week of the 14th?”
Defers without dismissing
Every yes is a no to something.
Day 49 / 100 · Pace & sustainability · Seasonal peaks
Plan the peak. Protect the recovery.
Year-end, Black Friday, go-lives, audits. Every team has predictable peaks. What hurts is treating them as surprises, and skipping the recovery afterwards.
Before
Prepare
Known dates in the plan
Change freeze and pre-work
Leave planned around it
During
Focus
Clear roles and on-call
Meetings cut to essentials
Short daily check-ins
After
Recover
Lighter sprint scheduled
Time off honoured
Retro while it's fresh
Plan the peak. Protect the recovery.
Day 50 / 100 · Pace & sustainability · Pace check-ins
Check the pace like you check velocity.
Teams track delivery every sprint, but rarely track how sustainable it felt. Five minutes in retro changes that.
Score it
Question 1
“How sustainable did this sprint feel?”
Scored 1–5, anonymously
Name the push
Question 2
“What pushed us over?”
Scope, interrupts, peaks, meetings
Name the relief
Question 3
“What gave us recovery?”
Do more of it deliberately
Change one thing
Question 4
“What will we change next sprint?”
One action, owned by one person
Check the pace like you check velocity.
Module 6Psychological safetyDays 51–60
Day 51 / 100 · Psychological safety · What it is (and isn't)
Safe to speak. Not soft.
Amy Edmondson defines psychological safety as a shared belief that the team is safe for interpersonal risk-taking. It isn't niceness, and it doesn't mean low standards.
Apathy
Low Safety · Low Standards
People keep their heads down
Nobody expects much, and nobody says much
Comfort
High Safety · Low Standards
Pleasant, but not stretching
Nice isn't the same as safe
Anxiety
Low Safety · High Standards
High pressure, silent mistakes
Problems surface late, if ever
Learning
High Safety · High Standards
Candour, plus accountability
Where performance is found
Safe to speak up. Expected to deliver.
Day 52 / 100 · Psychological safety · The four stages
Safety is built in stages.
Timothy R. Clark describes four stages of psychological safety. Each one builds on the one before, and you can't skip to challenge.
1 · Inclusion
“I Belong Here.”
Accepted for who you are
Invited in, not just allowed in
2 · Learner
“I Can Ask And Fail.”
Questions are welcome
Mistakes are treated as learning
3 · Contributor
“My Work Counts.”
Trusted to add real value
Given autonomy and a voice
4 · Challenger
“I Can Question How We Do Things.”
Safe to challenge the status quo
Even when the boss likes it
Include, invite, then welcome the challenge.
Day 53 / 100 · Psychological safety · Leader behaviours
Safety starts with the leader going first.
Edmondson points to three leader moves that make it easier for others to speak. All three are behaviours, not slogans.
Frame the work
As A Learning Problem
“There's a lot we don't know yet.”
Uncertainty named up front
Voices are needed, not optional
Admit fallibility
Say What You Got Wrong
“I might be missing something.”
Makes mistakes discussable
Status stops blocking honesty
Model curiosity
Ask, Then Listen
“What are you seeing that I'm not?”
Genuine questions
Listen longer than you talk
Go first.
Day 54 / 100 · Psychological safety · Making it safe to speak up
How you respond is the whole game.
People decide whether to speak up based on what happened the last time someone did. The invitation matters, but the response matters more.
Ask specifically
Better Invitations
“What am I missing?”
Not “any questions?”
Ask named people gently
Give time to think
Respond well
Thank, Then Engage
“Thanks, that's useful.”
No sighs, no eye-rolls
Separate the idea from the person
Even when the news is bad
Close the loop
Show What Happened
“Because you raised it, we…”
Report back on the outcome
Or explain why not
Silence feels like dismissal
How you respond is the whole game.
Day 55 / 100 · Psychological safety · Blameless postmortems
Ask how it made sense at the time.
Blame shrinks the information you get. Blameless reviews, popularised in tech by John Allspaw at Etsy, fix the system instead. The delivery process lives in the Agile & Delivery pillar.
Timeline
What Happened
Facts in sequence
Actions, not accusations
Include what went right
Factors
Why It Made Sense
What did they know then?
What did the system allow?
No “human error” as root cause
Actions
Change The System
Guardrails, not warnings
Owned and dated
Shared widely
Fix the system that let it happen.
Day 56 / 100 · Psychological safety · Healthy disagreement
Fight about ideas, not people.
Research (Karen Jehn) separates conflict about the task from conflict between people. The personal kind is reliably harmful. Task conflict, handled well, sharpens decisions.
Task conflict
About The Work
“I think the other design is safer.”
Challenges ideas
Surfaces risks
Useful when respectful
Relationship conflict
About The Person
“You always overcomplicate.”
Attacks character
Spreads fast
Poisons future debate
Disagree & commit
Then Move Together
“I'd go another way, but I'm in.”
Everyone heard first
Decision made, and owned
No quiet sabotage
Fight about ideas, not people.
Day 57 / 100 · Psychological safety · Inclusion in meetings: who gets to speak
Design who speaks. Don't leave it to chance.
Today is about who speaks. Day 36 covered how much meeting time, and Day 72 covers how meetings run. Left alone, meetings reward the fastest and loudest voices.
Before
Level The Start
Agenda and pre-reads shared early
Reflective thinkers get time
Questions posted in advance
During
Share The Air
Silent writing first, then discuss
Rounds, so everyone speaks
Call out interruptions kindly
After
A Second Door
Async input for 24 hours
“What didn't you get to say?”
Decisions noted with who shaped them
Design who speaks. Don't leave it to chance.
Day 58 / 100 · Psychological safety · Safety in remote teams
Distance quietly erodes safety.
Remote and hybrid work strip out the small signals that tell people they're safe, and add new ways to feel left out.
The cue gap
Less To Read
No body language, no hallway
Silence is ambiguous
Worries grow in the gaps
Proximity bias
Seen = Valued
Office people get more airtime
Decisions made in corridors
Remote people hear last
Deliberate connection
Build It On Purpose
Cameras optional, voices expected
Regular 1:1s, never skipped
Informal time, scheduled
If one person's remote, everyone's remote.
Day 59 / 100 · Psychological safety · Measuring safety
Measure the team, never the person.
You can track psychological safety, carefully. Edmondson's short survey includes items like “If you make a mistake on this team, it is often held against you.”
Survey
Short &Amp; Anonymous
A few validated items, quarterly
Reported at team level only
Observe
Watch The Behaviour
Who speaks, who gets interrupted
How fast bad news travels
Trend
Direction Over Number
Compare the team with itself
Look for shifts after changes
Act
Or Don'T Ask
Share results with the team
Agree one action together
Measure the team, never the person.
Day 60 / 100 · Psychological safety · Repairing trust
Trust breaks fast. Rebuild it on purpose.
Every team damages trust sometimes. What matters is the repair: specific, owned, and followed by changed behaviour.
Own it
Specific, No “But”
“I blamed you in public. That was wrong.”
Name exactly what happened
Name the impact
Repair
Change Something
“Here's what I'll do differently.”
A concrete behaviour change
Or a system change
Rebuild
Consistency Over Time
“Watch what I do next.”
Trust returns slowly
Every repeat resets the clock
Trust breaks fast. Rebuild it on purpose.
Module 7Learning & growthDays 61–70
Day 61 / 100 · Learning & growth · Learning with AI as a tutor
Ask it to teach, not to do.
The same AI that can do the work for you can teach you to do it. The difference is in how you ask.
Explain mode
Why, Not Just What
“Explain why this works, step by step.”
Understanding, not just output
Ask for the concept behind the fix
Socratic mode
Let It Question You
“Quiz me on this. Don't give answers.”
Active recall beats re-reading
Exposes gaps fast
Check mode
Tutors Can Be Wrong
“Where can I confirm this?”
Verify against the source
Especially specs and standards
Ask it to teach, not to do.
Day 62 / 100 · Learning & growth · Deliberate practice
Practise the hard part, on purpose.
Anders Ericsson's research showed that expertise comes from focused practice on specific weaknesses, with feedback. Time on the job alone isn't enough.
Specific goal
Not “Get Better”
One narrow skill at a time
e.g. spotting race conditions
Clear enough to measure
At the edge
Just Beyond Comfort
Hard enough to struggle
Not so hard you give up
Uncomfortable by design
Fast feedback
Know How You Did
Immediate, specific
From a mentor, a test or a result
Then repeat
Practise the hard part, on purpose.
Day 63 / 100 · Learning & growth · Pairing
Two heads, one keyboard.
Pairing spreads knowledge, catches mistakes early and speeds up learning. There are several styles, each for a different job.
Driver / navigator
Classic
One types, one thinks ahead.
Swap roles often
Good for most work
Ping-pong
With Tests
One writes a test, the other makes it pass.
Built-in rhythm
Great for TDD
Strong-style
For Teaching
Ideas go through the other person's hands.
The expert navigates
The learner types everything
Pair for learning, not just output.
Day 64 / 100 · Learning & growth · Communities of practice
Learn across teams, not just within them.
Etienne Wenger described communities of practice: people who share a craft and get better at it together. They cut across team lines.
Feedback works best as a steady stream, not an annual flood. Keep it specific enough to act on, and let it flow in every direction.
Situation, Behaviour, Impact
A Simple Shape
“In Tuesday's demo, you skipped the edge cases, and the client asked twice.”
Facts, not labels
Soon & often
Not Saved Up
“Can I give you a quick thought on that?”
Within days, not months
Two-way
Leaders Ask Too
“What's one thing I could do better?”
Ask, thank, then act
Small, soon, specific.
Day 66 / 100 · Learning & growth · Growth mindset at team level
Build the practices, not the posters.
Carol Dweck's growth mindset idea is popular, but the evidence for mindset interventions on their own is mixed. What reliably helps is team practices that make learning safe and visible.
Ask about process
Not Just Outcomes
“How did you approach it?”
Values the method
Useful even when it failed
Say “not yet”
Skill Is A Trajectory
“You can't do it yet.”
Frames gaps as temporary
Pairs with a plan
Supported stretch
Hard Work, With A Net
“Try it; I'll review with you.”
Real challenge
Real backup
Build the practices, not the posters.
Day 67 / 100 · Learning & growth · Learning from failure
Not all failure is equal.
Amy Edmondson separates failures by type. Each one needs a different response, and only one kind deserves celebrating.
Knowledge that lives in only one head is a single point of failure, and a heavy load for that person. Sharing spreads both the knowledge and the weight.
Learning budgets work when they come with protected time, real choice and a way to share what was learned.
Time
The Real Budget
Protected learning hours
On the calendar, not “when quiet”
Planned into capacity
Money
Simple To Use
Courses, books, conferences
Low-friction approval
In SA, WSP and ATR to your SETA can reclaim part of the skills levy
Share-back
Multiply The Value
A 10-minute team summary
Notes in the wiki
One idea tried at work
Money without time is a gesture.
Day 70 / 100 · Learning & growth · Team learning plans
Plan learning like you plan delivery.
Individual development plans matter. A team learning plan asks a different question: what does this team need to get better at together?
Where we are
Step 1
Skills map and confidence (Day 26)
Single points of failure (Day 68)
Where we need to be
Step 2
Next year's roadmap and tech
The skills that work will demand
How we close the gap
Step 3
Pairing, practice, courses
AI as a tutor (Day 61)
How we share
Step 4
Guilds and demos (Day 64)
Budget and time (Day 69)
Plan learning like you plan delivery.
Module 8CommunicationDays 71–80
Day 71 / 100 · Communication · Clear writing when AI drafts first
Decide the point. Then prompt.
AI makes writing effortless, and it makes padding effortless too. Clear writing still starts with you knowing what you want the reader to do.
Point first
Before You Prompt
“In one sentence: what do I need?”
Bottom line up front
If you can't say it, AI can't either
Cut the fluff
Ai Pads By Default
“Could this be half as long?”
Delete the throat-clearing
Keep what the reader needs
Own every line
Your Name Is On It
“Would I say this?”
Check facts and tone
Rewrite what isn't you
Decide the point. Then let AI help say it.
Day 72 / 100 · Communication · Meeting design: how a meeting runs
Every meeting ends with a decision.
Day 36 covered how much time meetings get. Day 57 covered who speaks. Today is about structure: how a meeting runs from open to close.
Purpose
Name The Type
Decide, inform or generate?
Inform can usually be async
The outcome goes in the invite
Structure
Shape The Time
An agenda of outcomes, not topics
Timeboxes for each item
A facilitator and a note-taker
Close
Never Just “Thanks All”
Decisions read back aloud
Owners and dates named
Notes out the same day
Every meeting ends with a decision or an action.
Day 73 / 100 · Communication · Decision records
Write down why, while you still know.
Architecture Decision Records, popularised by Michael Nygard, capture a decision's context and consequences in about a page. Memory fades fast; records don't. Delivery practice for these lives in Agile & Delivery.
Context
What Was True Then
The problem and the constraints
The forces pulling different ways
Decision
What We Chose
Stated plainly
Including the options rejected
Consequences
What Follows
Good, bad and neutral
What becomes easier or harder
Status
Still True?
Proposed, accepted or superseded
Linked to what replaced it
Write down why, while you still know.
Day 74 / 100 · Communication · AI summaries and information overload
Summaries for scanning. Sources for deciding.
AI summaries help with overload, and they quietly drop nuance, doubt and dissent. Know which you're reading, and when that matters.
What they're good for
Triage
What happened while I was away?
Is this relevant to me?
Where should I read in full?
What they lose
The Edges
Objections and caveats
Who said what, and how strongly
Uncertainty, smoothed into “agreed”
How to use them
Summary + Source
Always link to the original
Read the source before deciding
Never summarise a summary
Summaries for scanning. Sources for deciding.
Day 75 / 100 · Communication · Asking for help
Stuck is fine. Stuck alone isn't.
Teams lose days to people who are silently stuck. Make asking easy, specific and normal, especially for new joiners.
When
A Timebox
Stuck for a set time? Ask.
e.g. 30–60 min for most tasks
Agreed as a team norm
Not a sign of weakness
How
A Good Ask
“I'm trying X. I tried Y. I'm stuck on Z.”
Context, attempts, the specific question
Easy to answer quickly
Normalise it
Leaders Ask Too
“Anyone know how this works?”
Seniors ask in public channels
Thank people for asking
Stuck is fine. Stuck alone isn't.
Day 76 / 100 · Communication · Difficult conversations
Every hard talk is three talks.
Stone, Patton and Heen's classic, “Difficult Conversations”, shows that every tough conversation runs on three levels at once.
What happened
The Facts
“Here's what I saw. What did you see?”
Shift from blame to contribution
Assume you're missing information
Feelings
The Emotions
“I was frustrated. How was it for you?”
Feelings leak if you don't name them
Acknowledge before problem-solving
Identity
What It Says About Me
“Am I competent? Am I a good person?”
What's really at stake for them
For you, too
Have it early, in person, with curiosity.
Day 77 / 100 · Communication · Remote communication
Write for someone who wasn’t there.
In remote teams, most shared understanding happens through text. Clarity has to do the work that hallway context used to do.
Assume no context
Self-Contained
Link the ticket, name the system
Spell out acronyms once
State the ask and the deadline
Match the channel
Rich Vs Lean
Complex or emotional: call
Simple or factual: text
Decisions: always written
Mind the tone
Text Loses Warmth
“ok.” can read as cold
Add a line of intent
Assume good faith when reading
Write for someone who wasn't there.
Day 78 / 100 · Communication · Cross-team communication
Design team interfaces like an API.
Most friction lives between teams, not within them. Team Topologies suggests each team publish a clear “team API”: how to work with it.
Team API
How To Work With Us
What we own
How to request work
Response expectations
Named links
People, Not Just Tickets
A contact for each dependency
Regular short syncs
Escalation path agreed
Shared forums
See Each Other'S World
Joint demos and planning
Shared incident reviews
Rotations and shadowing
Design team interfaces like an API.
Day 79 / 100 · Communication · Communicating change
Say why first. Then say it again.
People can handle change. What drains them is change without reasons, without clarity on what stays, and without a way to ask questions.
Why
Before What
The problem this solves
Why now
What happens if we don't
What changes, and what doesn't
Both Halves
Be specific about the change
Name the stable anchors (Day 88)
Admit what's not known yet
Repeat & listen
Once Is Never Enough
Several channels, several times
Open Q&A, anonymous too
Answer the questions you get
Say why first. Then say it again.
Day 80 / 100 · Communication · A communication charter
One page on how we talk.
A communication charter pulls this module together into one page, then rolls into the team operating manual on Day 91.
When leaders don't know yet, the best thing they can offer is a clear map: what's known, what isn't, and when that will change.
What we know
Say It Plainly
“The team stays together through June.”
Facts, not spin
Even when unwelcome
What we don't
Say That Too
“We don't know the reporting lines yet.”
Naming gaps builds trust
Guessing destroys it
When we'll know
A Date, Not “Soon”
“We'll update you on the 14th.”
Keep the date, even with no news
Consistency is reassuring
Honest uncertainty beats false certainty.
Day 84 / 100 · Change & uncertainty · Small wins
Make progress visible.
Teresa Amabile's research found that making progress in meaningful work is one of the strongest boosts to people's day. That matters most in long, uncertain stretches.
During change, people need some things to stay the same. Naming what isn't changing is as important as explaining what is.
Rituals
Keep The Rhythm
Stand-ups, retros, 1:1s continue
Especially when times are busy
People
Keep The Bonds
Teams kept together where possible
Managers stay close
Purpose
Keep The Why
Who we serve hasn't changed
Link the change back to it
Principles
Keep How We Work
Our values and agreements hold
Blameless, honest, focused
Change what you must. Anchor the rest.
Day 89 / 100 · Change & uncertainty · Team resilience practices
Resilient teams have slack, not grit.
Team resilience isn't about toughing it out. It's the team's capacity to absorb a shock, adapt and recover. That comes from design.
Before
Build Capacity
Slack in plans
Cross-skilling (Day 26)
Runbooks and docs (Day 68)
During
Adapt Together
Clear roles, fast decisions
Short, regular check-ins
Scope cut early, not late
After
Recover &Amp; Learn
Recovery time (Day 49)
Blameless review (Day 55)
Update the playbook
Resilient teams have slack, not grit.
Day 90 / 100 · Change & uncertainty · After the change
Close the chapter before the next.
Most teams go straight from one change to the next. Taking time to close properly is what lets a team take on change again.
Review
What Did We Learn?
What worked, and what didn't
For the next change, not for blame
Recover
A Lighter Stretch
A planned slow period
Leave actually taken
Recognise
Name The Effort
Thank specific people
Acknowledge what it cost
Reset
Update The Basics
Team agreements and roles
Run a health check (Day 10)
Close the chapter before starting the next.
Module 10Building the systemDays 91–100
Day 91 / 100 · Building the system · One team operating manual
One manual. One link.
Across the playbook, the team has written several agreements. Today they come together as a single operating manual: how this team works.
AI norms
From Day 29
Welcome, check, off-limits, disclose
Approved tools and PII rules
Focus agreement
From Day 40
Focus blocks and the urgent path
Response windows
Communication charter
From Day 80
Channels, meetings, decisions
Summary plus source
Pace & safety
From Days 50 &Amp; 54
Pace check and its trigger
How we respond to speaking up
One manual. One link. Reviewed quarterly.
Day 92 / 100 · Building the system · Your team's ritual calendar
A rhythm, not a pile of ceremonies.
The playbook has introduced many practices. Mapped onto a calendar, they become a light rhythm rather than one ceremony stacked on another.
Daily
Minutes
Written stand-up (Day 35)
One assumption we're testing (Day 20)
Each sprint
In Existing Meetings
Pace check in retro (Day 50)
Pre-mortem for big items (Day 17)
Monthly
30–60 Min
Health check (Day 10)
Guild or kata session (Days 27, 64)
Quarterly
Half A Day, Total
Health retro (Day 96)
Offloading audit and learning plan (30, 70)
A rhythm, not a pile of ceremonies.
Day 93 / 100 · Building the system · Metrics without surveillance
Measure conditions, not people.
Cognitive health metrics should show whether the system is healthy, never who is “underperforming.” POPIA's purpose and minimality principles point the same way.
Do measure
Team-Level Signals
Anonymous health and pace scores
WIP, cycle time, meeting hours
Trends over time
Don't measure
Surveillance
Keystrokes, screen time, mouse activity
Individual chat or email volume
Sentiment scanning of messages
Protect
Popia-Minded
A clear purpose, stated up front
Collect the minimum
Minimum group sizes (Day 59)
Measure conditions, not people.
Day 94 / 100 · Building the system · The manager's toolkit
A few tools, used every time.
A manager doesn't need all 100 days in their head. They need a small toolkit with a clear rhythm, and they need to know when to reach for what.
Every 1:1
Weekly Or Fortnightly
What's on your list? (Day 47)
One thing each way (Day 65)
Every sprint
With The Team
Pace check (Day 50)
WIP visible and limited (Day 44)
Every month
The Pulse
Health check (Day 10)
Act on the lowest score
When needed
The Escalations
Escalation path (Day 46)
Hard talks (76) · Referral (8)
A few tools, used every time.
Day 95 / 100 · Building the system · Onboarding
Onboard into how we think.
Onboarding usually covers tools and access. The best onboarding also covers how the team works, thinks and looks after its attention.
Before day one
A Warm Start
A named buddy
The operating manual (Day 91)
First week planned
First 30 days
Belong &Amp; Ask
Inclusion first (Day 52)
Ask-for-help norm (Day 75)
AI norms explained (Day 29)
First 90 days
Contribute &Amp; Grow
On the skills map (Day 26)
A real contribution shipped
A 90-day check-in, both ways
Onboard into how we think, not just what we use.
Day 96 / 100 · Building the system · Health retros
Retro the team, not just the sprint.
Sprint retros look at delivery. Once a quarter, a health retro looks at how the team is thinking, focusing and coping. For sprint retro formats, see Agile & Delivery.
Check
15 Min
Review health and pace trends
Days 10 and 50 data
What moved, and what didn't
Explore
25 Min
Dig into the lowest area
Why, not who
Everyone heard (Day 57)
Act
20 Min
Pick one or two changes
Update the manual (Day 91)
Owner and date
Once a quarter, retro the team, not the sprint.
Day 97 / 100 · Building the system · Right-to-disconnect and focus policies
Write the boundary. Then live it.
France (2017), Portugal (2021) and Australia (2024) have legislated forms of the right to disconnect. In SA there's no specific statute yet, so it comes down to company policy.
After hours
No Expected Replies
Messages can wait until morning
Scheduled send by default
On-call is explicit and paid for
Focus time
Protected In Policy
Team focus blocks recognised
Meeting-free windows
Not overridden by seniority
Exceptions
A Defined Urgent Path
What truly counts as urgent
Who can escalate, and how
Reviewed when abused
Write the boundary. Then live it.
Day 98 / 100 · Building the system · Tools that help (AI included)
Every tool should take load off.
Tools can protect attention, or quietly eat it. Before adding one, ask a single question: will this reduce the team's cognitive load, or add to it?
Protect attention
Guard The Focus
Focus modes and status
Scheduled send
Notification controls (Day 34)
Reduce load
Offload Wisely
Automation and runbooks
AI for drafts and summaries, with norms (Day 29)
Fast builds (Day 39)
Support thinking
Make Reasoning Visible
Decision records (Day 73)
Shared docs over DMs
One searchable home (Day 68)
Every tool should take load off, not add it.
Day 99 / 100 · Building the system · Scaling across teams
Share the core. Let teams own the rest.
What works in one team won't copy-paste everywhere. Scale a small shared core, and let each team adapt the rest to its own work.
Shared core
Every Team
Monthly health check (Day 10)
Blameless reviews (Day 55)
AI and PII norms (Day 29)
Local choice
Each Team Decides
Focus times and rituals
Meeting and chat norms
Their own operating manual
Network
Learn Across
Champions guild (Day 64)
Share what worked, and what didn't
Aggregate data, never individuals
Share the core. Let teams own the rest.
Day 100 / 100 · Building the system · Your team's cognitive health plan
Start with three. Keep going.
A hundred days, ten modules. The point was never to do it all. It's a 90-day plan your team actually runs, then the next one.