The purpose of a theory of change
The difference between a diagram and a discipline.
Most organizations I meet already have a theory of change. It is usually a diagram, built for a funder, living in an appendix. It has boxes and arrows; it uses the word increased several times; and almost no one has looked at it since the grant was signed. That is not a theory of change. That is a picture of one.
The distinction matters more than it sounds. A diagram answers a single question: what will we promise to report? A theory of change answers a harder one: what do we actually believe about how this change happens, and how would we know if we were wrong? The first is a compliance artifact. The second is a discipline.
A theory of change is not a deliverable you finish; it is a habit of being honest, together, about how you think the world works.
I have spent fifteen years in community mental health and Indigenous health and social services, much of it on work that did not lend itself to tidy arrows. When the diagram and the discipline get confused, the cost is real: teams measure activity instead of mechanism, funders mistake motion for progress, and the people the work is meant to serve become data points in someone else's logic model. The fix is not a better template. It is a few changes in how the conversation is held.
Three things I have learned
- Start with the mechanism, not the activities. Activities are easy to list; they are the things you can put on a workplan. Mechanisms are the reasons those activities would change anything, and they are where the real thinking lives. "We will run workshops" is an activity. "Peer facilitators build trust that professionals cannot, and trust is what lets people ask for help earlier" is a mechanism. Name the mechanism and the activities organize themselves.
- Say the riskiest assumption out loud. Every theory of change rests on assumptions, and the most dangerous one is usually the assumption no one in the room wants to name; that the funding will continue, that the community actually wants what we are offering, that the people doing the work will still be here in two years. Surfacing it is not pessimism. It is the difference between a plan that can adapt and one that quietly breaks.
- Treat it as a living instrument. A theory of change earns its keep when reality disagrees with it. If your results never surprise you, you are not learning; you are only confirming. Build in moments to revisit it, and give people permission to say "this part isn't true anymore." The document should change because the work taught you something.
A note on community-led work
In Indigenous health and social services, a theory of change is also a question of who holds the pen. It is easy to write an elegant model in a boardroom and call the resulting consultation "community-led." But if the mechanism of change is trust, self-determination, and lived experience, then the act of authoring the theory cannot be outsourced to the consultant. My job, when I do it well, is to make the thinking rigorous and to get out of the way of whose thinking it is. The best theories of change I have been part of were ones I helped structure but did not own.
So when someone asks me to "build them a theory of change," I usually slow the question down. We can certainly produce the diagram; funders need it and it has its place. But the value was never in the boxes. It is in the honest, sometimes uncomfortable conversation the boxes are supposed to represent; and that conversation is the work.
The logic model and its limits
A useful map that too often becomes a straitjacket.
The logic model is a genuinely useful tool, and it is also one of the most quietly misused. On one page it lays out inputs, activities, outputs, and outcomes in a tidy left-to-right chain. For aligning a team and satisfying a funder, that clarity is worth a great deal. The trouble starts when people mistake the map for the territory.
A logic model implies a clean, linear causality: do these activities, get these outputs, produce these outcomes. Real social change rarely behaves so politely. It loops back on itself, depends heavily on context and relationships, and produces effects no box predicted. When a logic model is treated as a contract rather than a hypothesis, it can do real harm; it fixes a model that should be staying adaptive, and it flattens exactly the context and relationship that make the work succeed or fail.
A logic model is a map, not the territory; useful, as long as you remember you are allowed to redraw it.
The fix is not to throw the tool out, but to hold it more loosely. Treat the logic model as your current best hypothesis about how change happens, and pair it with a theory of change that explains the why underneath the boxes. Then revisit it, on purpose, when reality disagrees. For programs that are genuinely new or complex, a rigid logic model is worse than none, because it forces a premature certainty that crowds out the learning the work most needs.
Use it to align, to communicate, and to start the conversation. Just do not let a one-page diagram quietly become the thing you are accountable to, instead of the people the program is for.
Co-design is not consultation
The difference is who holds the pen.
"Co-design" has become one of those words that gets used to describe whatever engagement a project happened to do. It is worth being strict about, because the difference between co-design and consultation is not a matter of degree. It is a matter of power.
Consultation asks people to react to a plan you have already made. You frame the problem, you draft the options, and you invite feedback, which you may or may not take. Co-design shares the pen from the beginning: the people affected help frame the problem, shape the options, and make the decisions. The test is brutally simple. Could what you heard have changed the design in a fundamental way? If the answer is no, it was not co-design, whatever the agenda called it.
If the design could not have changed based on what you heard, it was not co-design; it was theatre.
This matters everywhere, but it matters most in work with communities who have been "consulted" many times and seen little change, because tokenistic engagement does not just fail to help; it actively erodes trust, faster than no engagement at all. People can tell the difference between being asked and being used to ratify a decision already made, and they remember.
In Indigenous and community contexts, co-design is not only the ethical choice; it is the epistemically necessary one. The people closest to a problem hold knowledge the designers simply do not have, and a process that keeps the pen in the consultant's hand will produce a tidier plan and a worse one. Sharing the pen is harder, slower, and messier. It is also the only way to design something that fits the lives it is meant to serve.
Writing a survey that tells you something
Most surveys are built to confirm, not to learn.
A survey looks like the easy part of evaluation, which is exactly why it is so often done badly. Most surveys are written, without anyone meaning to, to confirm what the team already believes rather than to learn something that might surprise them. The result is data that feels reassuring and tells you almost nothing.
The usual culprits are familiar once you look for them. Leading questions that telegraph the desired answer. Double-barrelled items that ask two things at once, so you cannot tell which one the answer is about. Jargon that means something precise to you and nothing to the respondent. Scales that do not fit the question. And, above all, length; the forty-one-item survey nobody finishes tells you far less than the twelve-item one they do.
A survey is a conversation you cannot follow up on, so ask as if you only get one chance, because you do.
The principles that fix most of it are not complicated. One idea per question. Plain language a tired person understands on the first read. Balanced response options that make it as easy to disagree as to agree. Never ask for something you have no intention of acting on; it wastes the respondent's time and your credibility. And tell people, up front and honestly, that their answers are anonymous and what you will do with them.
Then pilot it with a few real people before it goes out, and watch where they hesitate or frown. The questions that confuse your test group will confuse everyone, and you only find them by asking a human being to try, before you ask three hundred.
Numbers and stories together
Quantitative and qualitative, and why neither is enough alone.
There is an old, tired argument about whether numbers or stories are the more serious form of evidence. The honest answer is that each one misleads you without the other, and the most rigorous thing you can do is refuse to accept either on its own.
Numbers tell you what and how much: the scope of a problem, the size of a pattern, whether something moved. Stories tell you why and what it means: the mechanism behind the pattern, the experience the number compresses into a single digit. A satisfaction score of 3.2 out of 5 is not a finding; it is a question. Until someone tells you why, you have no idea whether to celebrate or worry. And a moving quote is not a finding either, until you know whether it speaks for many people or one.
Rigour is not choosing numbers over stories; it is refusing to trust either without the other.
Mixed methods simply means using each to check the other. Let the quantitative show you the shape and the scale; let the qualitative tell you what it means and where the survey missed. When they agree, your confidence is earned. When they disagree, you have found the most interesting thing in the whole study, the place where the official numbers and the lived reality part ways.
In community and Indigenous contexts this is not a methodological nicety; it is often where the truth lives. The relational, qualitative knowledge frequently carries what a standardized instrument cannot capture, and an evaluation that listens only to the survey will confidently measure the wrong thing.
Good programs that fail to take hold
A program isn't implemented when it launches; it's implemented when it's used.
There is a quiet graveyard in every sector: programs that were well designed, properly funded, and launched with real fanfare, and that simply never took hold. The logic model was sound. The training happened. And six months later, people are doing what they always did. The gap between a good plan and an adopted practice is where most change actually fails, and it is almost never a failure of the plan.
It fails because change gets done to people instead of with them. Organizations pour their energy into the technical side, the new model, the new system, the new policy, and treat the human side as something that will sort itself out. It does not. People do not adopt a change because it is logical; they adopt it when they understand why it matters, want to make it, know how, are able to, and are reinforced for doing so.
A program is not implemented when it is launched. It is implemented when it is used, by default, without being chased.
That is the heart of structured change practice. The work is to build adoption in from the beginning, not bolt it on at go-live: name who is affected and how; give people a real reason and a real say; equip them, not just inform them; and, crucially, plan the reinforcement, because the most common point of failure is the leadership team that announces a change and then moves on, leaving no one to make the new way the normal way.
And measure the right thing. Most rollouts track activity, sessions delivered, materials distributed, systems switched on. Adoption is a different question: are people actually using the new practice, and is it producing the outcome it was meant to? A dashboard full of green rollout metrics can sit happily on top of a change that no one has actually made.
Designing for adoption is not softer than designing the model; it is harder, and it is what determines whether all the rest of the work survives contact with the people who have to live it.
Running a session that decides
Lively discussion is not the same as a decision.
We have all sat through the workshop that generated three hours of energetic discussion, a wall of sticky notes, and no decision anyone could name afterward. Good facilitation is what stands between a meeting and that outcome, and it is far more about design than about charisma.
A session that decides starts before the room does. It has a clear purpose stated as a question to be answered, not a topic to be discussed. It has the right people, the ones with the knowledge and the authority to decide, and not a cast of thousands. And it has a structure that deliberately moves the group from divergence, where every idea and concern gets on the table, to convergence, where the group actually chooses.
A good session is judged by what gets decided and done, not by how lively the conversation felt.
In the room, the facilitator's most valuable asset is neutrality; the moment you are seen to be steering toward your own answer, the trust that makes honesty possible evaporates. The craft is in the small things: making it safe to disagree, managing the person who would happily talk for the full hour, and drawing out the quiet one who often holds the insight everyone needs. And it is in refusing to let people leave until the decisions, and the names of who owns each next step, are written down where everyone can see them.
Energy in a session is pleasant. A decision, with an owner and a date, is the point.
The last mile of research
Findings that never reach a decision were never finished.
A great deal of good research dies in the last mile. The study is sound, the findings are real, and they come to rest in a report that the people who could act on them never read. We tend to treat that as someone else's problem, the decision-maker's failure to engage. It is more honest to treat it as part of the work that simply did not get done.
Knowledge translation is the discipline of closing that gap; of turning evidence into something a specific audience can actually use, and use in time. It is often misread as "dumbing down," which gets it backwards. Translating a finding into plain language, the right format, and the decision-maker's actual question is harder than writing the technical report, not easier, because it requires you to know what matters and to let the rest go.
Research that nobody uses is not finished; it is abandoned at the last mile.
There is a useful spectrum here. The weakest approach is pure push: produce the report and hope it lands. Better is pull: start from what the decision-maker actually needs and shape the work to answer it. Best is exchange: a relationship in which the people who will use the evidence help shape what gets studied and how it gets told, so that by the time the findings arrive, there is already someone waiting to act on them.
The practical moves are modest and they compound: lead with the "so what," match the format to the audience rather than your habits, and deliver it when the decision is being made, not three months after. None of it is glamorous. All of it is the difference between research that informs a choice and research that decorates a shelf.
The dashboard nobody opens
Why most dashboards get abandoned, and what makes one useful.
Organizations spend real money commissioning dashboards that get opened twice and then quietly abandoned. It is rarely a technical failure; the charts work fine. It is a design failure, and it comes from building the dashboard around the data that exists rather than the decisions it is supposed to inform.
The abandoned dashboard has a few tells. It shows everything, because no one was willing to choose, so the signal drowns in forty metrics of equal visual weight. It answers questions nobody is actually asking. It leads with numbers instead of meaning, leaving a busy director to reverse-engineer the "so what." And it was built for the person who made it, not the person who has to act on it.
The best dashboard is not the one with the most charts; it is the one that changes a decision.
A useful dashboard starts from the other end. Name the handful of decisions it should support, and build only what informs them. Show a few things well. Lead with the "so what" and let the chart be the evidence underneath it, not the headline. Be honest about confidence and gaps, because a dashboard that hides its uncertainty is worse than no dashboard. And make it accessible and plain, so a tired person can read it on a hard day.
The test I use is simple: can someone glance at it and know what to do differently? If the honest answer is no, you have not built a decision tool. You have built decoration with good production values.