Nick — really good question. I think the two frames are strongly compatible, but they cut reality along slightly different lines.
Your “doing things well / doing things better / doing better things” lens is fundamentally about quality and direction of improvement:
• Doing things well = reliable execution (quality, consistency, safety)
• Doing things better = incremental improvement (refinement, continuous improvement)
• Doing better things = strategic choice / redesign (changing what you do and why)
Run / Serve / Change is a bit different: it’s a way of naming the three work-loads that show up at every level of an organisation:
• Run = keep the system stable and dependable
• Serve = respond to stakeholders and context (the “interface work” with customers, partners, users)
• Change = redesign the system (experiments, transformation, new architecture)
So the overlap looks like this:
• Run mostly aligns with doing things well
•Change mostly aligns with doing better things
• Serve doesn’t map 1:1 — it’s the context-facing load that tells you what “better” even means, and where the pressure for improvement is actually coming from.
And “doing things better” is almost a mode that can apply across all three:
• doing Run better (reliability, fewer defects, smoother throughput)
• doing Serve better (faster resolution, better relationships, less friction, better outcomes in context)
Where I find Run / Serve / Change especially useful is in diagnosing why improvement efforts stall: most organisations don’t fail because they don’t know they should “do better things.” They fail because they keep mixing the loads, demanding Run reliability while piling on Change, expecting Serve responsiveness while treating Serve as invisible glue work, and then trying to manage the whole mess through dashboards.
So in short: your frame is brilliant for asking “are we improving in the right way?” Run/Serve/Change is brutal (in a good way) for asking “who is carrying which load, and what breaks when we pretend it’s all the same kind of work?”
Richard, could you put the Run / Serve / Change thinking back onto a traditional factory? I'm guessing design of the factory itself is Change, and making sure it's doing what it's supposed to do is Run. I'm wondering what actions and decisions would constitute Serve in your thinking - in addition to the relationships with suppliers, customers, other services etc., is it also reading the signals coming from Run and making decisions about how the work flows?
“What would it look like to make similar choices about where Run, Serve and Change live in our world?”
*Not copy-paste*. Translation. (🤭🤭🤭)
Let’s stay concrete.
(You tell 'em, Dr. Richard! 🤣)
Thanks for sharing, Richard. Really enjoying this.
What similarities and differences do you see between run, serve, change and doing things, well, doing things better and doing better things? https://mrnickhart.substack.com/p/layers-of-school-improvement-activity
Nick — really good question. I think the two frames are strongly compatible, but they cut reality along slightly different lines.
Your “doing things well / doing things better / doing better things” lens is fundamentally about quality and direction of improvement:
• Doing things well = reliable execution (quality, consistency, safety)
• Doing things better = incremental improvement (refinement, continuous improvement)
• Doing better things = strategic choice / redesign (changing what you do and why)
Run / Serve / Change is a bit different: it’s a way of naming the three work-loads that show up at every level of an organisation:
• Run = keep the system stable and dependable
• Serve = respond to stakeholders and context (the “interface work” with customers, partners, users)
• Change = redesign the system (experiments, transformation, new architecture)
So the overlap looks like this:
• Run mostly aligns with doing things well
•Change mostly aligns with doing better things
• Serve doesn’t map 1:1 — it’s the context-facing load that tells you what “better” even means, and where the pressure for improvement is actually coming from.
And “doing things better” is almost a mode that can apply across all three:
• doing Run better (reliability, fewer defects, smoother throughput)
• doing Serve better (faster resolution, better relationships, less friction, better outcomes in context)
• doing Change better (cleaner experiments, faster learning loops, better adoption)
Where I find Run / Serve / Change especially useful is in diagnosing why improvement efforts stall: most organisations don’t fail because they don’t know they should “do better things.” They fail because they keep mixing the loads, demanding Run reliability while piling on Change, expecting Serve responsiveness while treating Serve as invisible glue work, and then trying to manage the whole mess through dashboards.
So in short: your frame is brilliant for asking “are we improving in the right way?” Run/Serve/Change is brutal (in a good way) for asking “who is carrying which load, and what breaks when we pretend it’s all the same kind of work?”
Richard, could you put the Run / Serve / Change thinking back onto a traditional factory? I'm guessing design of the factory itself is Change, and making sure it's doing what it's supposed to do is Run. I'm wondering what actions and decisions would constitute Serve in your thinking - in addition to the relationships with suppliers, customers, other services etc., is it also reading the signals coming from Run and making decisions about how the work flows?
Love your (and Stefan's) work.