You decided on the change carefully. The new placement policy, the revised schedule, the added team, the software everyone will finally use, whatever it was, you thought it through, pressure-tested the logic, and concluded it was the right move. Then you rolled it out and it landed badly. Staff gave families three different versions of it. The people it affected heard about it secondhand. Two weeks in you could not tell whether it was working, and by the time the complaints reached you the change had already soured, not because you chose wrong but because the organization was not ready to absorb what you chose.
Here is the part that is easy to miss when you are confident in a decision. Whether a change is a good idea and whether your organization is ready to run it are two separate questions, and most directors pressure-test the first one hard and skip the second one entirely. A right change dropped into an organization that cannot absorb it fails the same way a wrong change does, and it fails more painfully, because everyone can see the idea was sound and assumes the execution problem is somebody's fault. The readiness question is the one that determines whether your good decision survives contact with your actual program, and it deserves its own deliberate check before anything gets announced.
The Readiness Check
The instinct, before a change, is to keep improving the decision: refine the policy, get the details right, make sure it is the correct call. That work matters, and a poorly designed change cannot be rescued by good rollout. The deeper move is to run a separate test on the organization rather than the idea, because readiness is a property of your program's current capacity and clarity, not of how smart the change is, and it is the property that decides most rollouts and gets checked in almost none.
The readiness check is four questions you answer honestly before you announce anything. If the answer to any of them is no, the change is not dead; it means you have a specific piece of preparation to do first, and doing it now is far cheaper than repairing a botched rollout later. The four questions catch the four ways a sound change most often comes apart on the way to the field.
1: Does It Have a Real Owner?
The first question is whether one named person is accountable for this change landing, or whether it will default to whoever happens to be in the room when a problem comes up. A change with no owner becomes everyone's job, which makes it no one's, and the gaps get filled by whoever was nearby rather than by whoever should decide. Name the person who owns this rollout end to end, give them the authority to make the calls it will require, and make sure they know they own it, because a change that cannot survive one person owning it was never going to survive being owned by no one.
2: Is There Room in the Calendar to Absorb It?
The second question is whether the change is landing in a stretch that has capacity or stacking onto a week that is already full. A new system introduced during your busiest month competes for attention nobody has, and it gets a half-effort rollout that dooms a full-strength idea. Look at what else the affected people are carrying when the change hits, and if the honest answer is that they are underwater, either clear something or move the timing, because the same change introduced into a week with room lands as an improvement and introduced into an overloaded one lands as one more thing.
3: Can You Explain It in One Pass?
The third question is whether the people affected can understand the change the first time they hear it, or whether it needs a translation. If you cannot explain the new policy in three sentences a family reads once and gets, they will fill the gaps with their own interpretation, and their interpretation is usually worse than reality. Write the explanation before you launch, keep it to a short email or a one-page handout, and test it on someone outside the decision, because leaving no room for doubt at the moment of announcement prevents the rumor-and-confusion spiral that a vague rollout guarantees. A change families understand on the first pass gets absorbed, while a change they have to decode gets resisted.
4: Will You Know Within Weeks Whether It's Working?
The fourth question is whether you have decided, in advance, how you will tell if the change is succeeding and what you will do if it is not. Most rollouts have no defined signal, so a change drifts for months while everyone forms private verdicts you never get to address. Before you launch, name the one or two things you will watch, set a date a few weeks out to check them, and decide now what adjustment you will make if the early read is bad. A change you are measuring can be corrected while it is still correctable, and a change you launched and stopped watching becomes permanent by default whether or not it worked.
Running It Before Your Next Change
The readiness check takes about fifteen minutes and belongs in the window after you have decided on a change and before you have announced it, which is exactly the window most programs skip because the decision feels like the finish line. Walk the four questions honestly, and treat any no as a task rather than a veto: no owner means assign one, no calendar room means move the date, no clean explanation means write it, no success signal means define it. Then launch, having removed the four failure modes that sink good changes, rather than discovering them one complaint at a time.
The check earns its fifteen minutes most on the changes you are most sure about, because confidence in the idea is exactly what tempts you to skip the readiness question, and a sound change is the one whose rollout failure will confuse you most when it comes. Run it especially before anything that touches how families or staff experience the program day to day, since those are the changes where a readiness gap turns into a trust problem fastest.
You already put real thought into whether the change is right. The readiness check adds the second half of that work, the part that asks whether your program as it exists today can carry the change you designed, so the good idea you were confident in actually lands as the improvement you meant it to be. Run the four questions before you announce, and the change stops failing for reasons that had nothing to do with whether it was a good one.
