04: How to Make It Stick (When Everything Wants to Drift Back)
You fixed it. Now here's how to keep it fixed.
📺 Prefer video?
Watch this 7-minute version, or keep reading.
Where We Are
Over the past few weeks, you’ve learned:
Single Source of Truth: Give each information type one predictable home
The 5Cs Framework: Design communication for different minds
The Findability Principle: Make information retrievable, not just delivered
If you’ve tried any of these, you probably noticed something: they work immediately.
Put event details in one place instead of five? Parents stop asking where to find them.
Write your weekly update with clear structure? People actually read it.
Answer the three findability questions? Follow-up emails drop.
The improvements are real. The relief is immediate.
And then, about three weeks in, something shifts.
Someone bypasses the calendar and sends event details via email. A colleague writes an announcement that ignores the 5Cs. Your carefully structured communication system starts feeling like something only you remember to maintain.
The system didn’t fail. It just started drifting back.
Here’s what nobody tells you about implementing better systems: The hard part isn’t the initial fix. It’s keeping it fixed when the novelty wears off and everyone gets busy again.
Why Good Systems Drift Back to Bad Ones
There’s a principle in systems thinking: Organizations naturally drift back to whatever pattern required the least conscious effort.
It’s not that people want to go back to the messy way. It’s that the old way is encoded in muscle memory, and the new way requires intention.
Here’s what happens:
Week 1: You implement Single Source. Everyone’s excited. It works.
Week 3: Two people forget. You’re busy, so you let it slide. “Just this once.”
Week 4: Half the team is back to the old way. The calendar exists but nobody trusts it anymore because information is scattered again.
Week 6: You’re back where you started.
This is what happens when you change behavior without assigning ownership.
The Missing Piece: Clear Ownership
When nobody owns a system, everyone assumes someone else is handling it.
You implement Single Source for the calendar. It works beautifully. Then someone adds an event and forgets to update it. Then someone announces a change via email only. Then someone creates a secondary calendar “just for our department.”
Nobody broke the system intentionally. But nobody was specifically maintaining it either.
Related: Learn about how to set up a Single Source of Truth for your school.
The principle:
Every system needs an owner, someone who:
Monitors whether the system is being used correctly
Redirects when people drift back to old patterns
Advocates for the system when others want to bypass it
Enter: The Ownership Checklist
For each system you implement, answer four questions:
1. What’s the system?
Be specific.
❌ “Better communication”
✅ “Single Source calendar on school website—all events posted here, all announcements link here”
2. Who owns it?
Name a person, not a department.
❌ “The admin team”
✅ “Communications Coordinator maintains. Principals have edit access. All staff view-only.”
3. What does ownership mean?
List 3-5 concrete responsibilities.
Example for Single Source calendar:
Reviews calendar weekly for accuracy and completeness
Redirects staff who post events elsewhere: “Please add to master calendar instead”
Runs monthly check: Are all upcoming major events posted with complete details?
Updates process documentation when workflow changes
Example for 5Cs communications:
Reviews principal’s weekly update draft against 5Cs before sending
Maintains templates showing 5Cs structure
Quarterly: surveys 5 teachers on communication clarity
4. Who backs up the owner?
Systems can’t depend on one person.
“Assistant Principal steps in when Communications Coordinator is out.”
Real Example
What Ownership Looks Like in Practice
A school implemented Single Source for their official documentation—one central Doc Hub where all current forms, policies, and handbooks live.
They assigned ownership:
Owner: Digital Learning Coordinator
Responsibilities:
Set up the system and standard templates
Train staff on correct usage
Support colleagues during implementation
Eventually migrate responsibility for long-term maintenance
Backup: Digital Learning Support Specialist
Result: Twenty months later, the Doc Hub still stands. Changes have been made to evolve with the needs of the school. New staff are trained to use it during onboarding.
The system stuck because someone was explicitly maintaining it.
The Two Mistakes Schools Make
Mistake #1: Assuming ownership is obvious
“Of course the Communications Director owns the calendar.”
But does she know that includes redirecting people who bypass it? Does she know it includes monthly audits? Does she have authority to tell a principal “please don’t create a separate athletics calendar”?
Make ownership explicit. Write it down. Tell the owner. Tell the team.
Mistake #2: Making ownership a burden instead of a defined scope
If ownership means “fix every problem that emerges,” nobody will want it.
Instead, define ownership as specific, manageable responsibilities with clear boundaries.
“You own making sure the calendar is accurate and current. You don’t own whether people like the calendar interface; that’s an IT decision.”
Bounded ownership is sustainable ownership.
Your Move This Week
Pick the one improvement that’s working best right now. Maybe it’s Single Source calendar. Maybe it’s your redesigned weekly update. Maybe it’s a form you fixed.
Spend 10 minutes creating your own Ownership Charter:
Name the system (one sentence—what exactly are we talking about?)
Assign an owner (a person, not a role description)
Define ownership (3-5 specific responsibilities they can actually do)
Name a backup (who steps in when they’re out?)
Then do two things:
First, tell the owner explicitly. Don’t assume they know.
“Amy, I’m formally making you the owner of our Single Source calendar. Here’s what that means: [list responsibilities]. Does this feel manageable? What support do you need?”
Second, tell the team.
In your next staff meeting or email: “Quick update on our calendar system: Amy is now the official owner. If you need to add an event, here’s the process. If you’re not sure where something goes, ask Amy. She’s maintaining this so it stays reliable.”
That’s it.
One improvement. One owner. Ten minutes of documentation. One conversation.
What This Unlocks
When you assign clear ownership, three things change:
The system stops being “everyone’s responsibility” (which means it’s actually nobody’s responsibility) and becomes someone’s responsibility.
Drift gets caught early. When someone has explicit authority to redirect behavior, old habits don’t creep back silently.
Improvements can compound. When one system stays fixed because someone owns it, you can move on to fixing the next thing—instead of constantly re-solving the same issues.
P.S. Want the template? I’ve created an interactive Ownership Checklist where you can fill in your details and instantly download a formatted .txt file. The AI-assisted form walks you through each question with examples.
Your Experience
What’s one system improvement you’ve made that’s starting to drift back, or that you want to protect before it does?
Hit reply and tell me what you’re assigning ownership to this week. I’m collecting real examples of what sticks (and what doesn’t) to share in future posts.
Systematically yours,
About the Author:
G (short for Gitane) is co-founder and Chief Creative Officer at EKG Collective, helping international schools turn communication complexity into systematic clarity. Learn more at ekgcollective.com.