Thanks! Great question. And I think it's worth unpacking a bit. First, on the tooling side: you're not wrong that there isn't a dedicated "guidelines tool" out there. But I think the practical answer is that guidelines don't need their own tool—they need to live inside whatever tools people are already using. A checklist item in a project management tool, a required field in a support ticket, a Slack bot that prompts "did you consider X?" before a deploy, a simple checkbox on a form—these are all ways to make a "doing" consideration more lightweight. The examples in the article were meant to gesture at exactly this: the tooling is less about finding the right platform and more about embedding the consideration into accessible and easy checkable tools for that context.
That said, I think your question points at something deeper and important, which is the administrative burden. And here I think it's important to be clear: yes, this approach does require more work than the alternative. But it's worth being clear about what "the alternative" actually is. In most cases, the alternative is selective enforcement—where rules technically exist but are only enforced when someone in authority decides to care. That approach feels lighter, but only because it offloads the work onto informal power dynamics and ambiguity. It's not that the work disappears; it just gets hidden (and often lands on the people with the least power to push back).
So the real question isn't "how do we eliminate the administrative burden?" but "who should carry it?" And my general answer is: the burden belongs to the person whose tension the guideline is meant to resolve. If you're the one who needs something to be considered, then it's on you to make that consideration as easy and realistic as possible for the people you're asking it of. That might mean designing a simple checklist, writing a clear prompt, or choosing a "doing" consideration that fits naturally into existing work. But however it gets operationalized, it means taking responsibility for the design of your own expectation.
So at the end of the day, some amount of administrative work is the honest cost of actually aligning on expectations. The goal isn't zero friction—it's right-sized friction that respects everyone's judgment and time, but all of that said, I think the tools can make a big difference.
Think of how many apps won't let you proceed without checking an "I agree to the terms" box. In theory, you might be able to build the same kind of gate into everyday workflow tools. For example, a shared task board where a ticket can't be moved to "done" unless a required field like "considered/not applicable/tradeoff accepted" is filled in. The person still decides what to do, but the system won't let them skip the act of considering. There are downsides to making the consideration too smooth though (as the article coming out on next week will explain), but I hope that helps give you some ideas.
Great, thanks for adding that extra layer of detail!
Important and useful insight that the burden of enforcement belongs to the person feeling the tension.
And it seems to me that „inserting an assertion into someone else’s workflow“ as well as the richness of expression of guidelines (e.g. being prompted to state the rationale after ticking a checkbox) is not easy to implement in the workflow tools that I know.
That might make implementing MRM’s ideas more challenging, though desirable.
To me, it’s always fascinating to see how many digital workflow tools still seem to lack a certain conceptual depth. And building something like this in a generic way might be very challenging. Building it in a way that work processes remain lively and fun seems even more challenging.
I always get excited when thinking about an architecture to scaffold excellent coordination and collaboration. I think the world can greatly benefit from this - both from concepts like MRM and from tools to make their implementation as easy as possible.
Agreed. From my perspective, the tools need only be as sophisticated as the situation requires. Again, there is even an argument to be made that by making them awkward...making people stop what they are doing in the normal flow of things...and click something or write a sentence or two is actually BETTER for it. In my experience, I've seen this mostly done retroactively, meaning it is only when a tension surfaces do we pursue the line of questioning regarding whether the agreed upon considerations were done. I've argued (somewhere) that Holacracy is essentially a management-by-guideline approach because most of its rules (when done well) are enacted in precisely this retroactive way. So, I don't think of this so much as me pitching an idea I had about how things COULD work, but an explanation of how things ALREADY do (when they go well).
Wonderful article again. Thanks, Chris!
And I wonder about tooling once more: I don’t know any tool where I could make guidelines live in a beautiful way.
And without support tools, I can see how the mental load would be way too high for people who are not the process-nerds we are.
Am I missing something? Am I being too tool-focused? How to do this in practice?
Thanks! Great question. And I think it's worth unpacking a bit. First, on the tooling side: you're not wrong that there isn't a dedicated "guidelines tool" out there. But I think the practical answer is that guidelines don't need their own tool—they need to live inside whatever tools people are already using. A checklist item in a project management tool, a required field in a support ticket, a Slack bot that prompts "did you consider X?" before a deploy, a simple checkbox on a form—these are all ways to make a "doing" consideration more lightweight. The examples in the article were meant to gesture at exactly this: the tooling is less about finding the right platform and more about embedding the consideration into accessible and easy checkable tools for that context.
That said, I think your question points at something deeper and important, which is the administrative burden. And here I think it's important to be clear: yes, this approach does require more work than the alternative. But it's worth being clear about what "the alternative" actually is. In most cases, the alternative is selective enforcement—where rules technically exist but are only enforced when someone in authority decides to care. That approach feels lighter, but only because it offloads the work onto informal power dynamics and ambiguity. It's not that the work disappears; it just gets hidden (and often lands on the people with the least power to push back).
So the real question isn't "how do we eliminate the administrative burden?" but "who should carry it?" And my general answer is: the burden belongs to the person whose tension the guideline is meant to resolve. If you're the one who needs something to be considered, then it's on you to make that consideration as easy and realistic as possible for the people you're asking it of. That might mean designing a simple checklist, writing a clear prompt, or choosing a "doing" consideration that fits naturally into existing work. But however it gets operationalized, it means taking responsibility for the design of your own expectation.
So at the end of the day, some amount of administrative work is the honest cost of actually aligning on expectations. The goal isn't zero friction—it's right-sized friction that respects everyone's judgment and time, but all of that said, I think the tools can make a big difference.
Think of how many apps won't let you proceed without checking an "I agree to the terms" box. In theory, you might be able to build the same kind of gate into everyday workflow tools. For example, a shared task board where a ticket can't be moved to "done" unless a required field like "considered/not applicable/tradeoff accepted" is filled in. The person still decides what to do, but the system won't let them skip the act of considering. There are downsides to making the consideration too smooth though (as the article coming out on next week will explain), but I hope that helps give you some ideas.
Great, thanks for adding that extra layer of detail!
Important and useful insight that the burden of enforcement belongs to the person feeling the tension.
And it seems to me that „inserting an assertion into someone else’s workflow“ as well as the richness of expression of guidelines (e.g. being prompted to state the rationale after ticking a checkbox) is not easy to implement in the workflow tools that I know.
That might make implementing MRM’s ideas more challenging, though desirable.
To me, it’s always fascinating to see how many digital workflow tools still seem to lack a certain conceptual depth. And building something like this in a generic way might be very challenging. Building it in a way that work processes remain lively and fun seems even more challenging.
I always get excited when thinking about an architecture to scaffold excellent coordination and collaboration. I think the world can greatly benefit from this - both from concepts like MRM and from tools to make their implementation as easy as possible.
Agreed. From my perspective, the tools need only be as sophisticated as the situation requires. Again, there is even an argument to be made that by making them awkward...making people stop what they are doing in the normal flow of things...and click something or write a sentence or two is actually BETTER for it. In my experience, I've seen this mostly done retroactively, meaning it is only when a tension surfaces do we pursue the line of questioning regarding whether the agreed upon considerations were done. I've argued (somewhere) that Holacracy is essentially a management-by-guideline approach because most of its rules (when done well) are enacted in precisely this retroactive way. So, I don't think of this so much as me pitching an idea I had about how things COULD work, but an explanation of how things ALREADY do (when they go well).