Between Mondays

Author: Brad McKinney

  • Measuring Progress When Milestones Don’t Show Up in a Status Report

    Measuring Progress When Milestones Don’t Show Up in a Status Report

    The status report said nothing moved that week. The status report was wrong about what mattered.

    Eight months into a legacy system replacement, I asked for a progress update ahead of a steering committee review. The report was thin. No milestone had closed that week. The same bar sat on the Gantt chart it had sat on three weeks earlier, still in progress, nothing to bump. That week was a clean example of something specific: milestones don’t always show up in a status report. Real progress can still be happening underneath it.

    Here is what had actually happened that week. A business analyst fielded a question about the old system. For the first time, they answered it from the new one without opening the legacy screen to check. A partner team resolved a data discrepancy themselves, using the new reconciliation process, without escalating it to us. A new hire onboarded straight onto the target-state workflow. Nobody needed to explain “the way we used to do it” as a reference point. None of that closed a milestone. All of it was the transformation actually taking hold. None of it was in the report I was about to carry into the room.

    The status report and the transformation measure different things

    A project plan tracks task completion: requirements signed off, code deployed, data migrated, training delivered. That is real and worth tracking. It does not tell you whether the change took hold. Process, technology, and culture shift on different clocks. A status report built around milestones is built to track the first two. Culture, the slowest of the three, does not close out on a Gantt chart. It shows up in whether people reach for the new way without being told to. That kind of evidence does not fit in a field that expects a percentage.

    That is not a flaw in status reporting. Status reports answer a specific question, is the work on track, and answer it well. The mistake is treating them as the only instrument for a different question: is the change actually sticking. That question needs its own evidence, and most of that evidence already exists somewhere. It just is not being looked at.

    A milestone tells you a task finished. It does not tell you whether anyone believes in what replaced it.

    Find the data that is already being collected

    The temptation is to treat this as purely qualitative, something you sense in meetings but cannot point to. Usually that is not true. Most programs are already generating the exhaust that would answer this, nobody has gone looking for it:

    • System usage, not system rollout. Login and transaction volume on the legacy system versus the new one, tracked weekly. A legacy system that stays busy six months after go-live is telling you something a training-completion metric never will.
    • Ticket categorization. Help desk and support tickets tagged by which system they reference. A rising share of tickets ask how to do something in the new system. A shrinking share ask why the new system doesn’t work like the old one. That shift is a real trend line, not an anecdote.
    • Defect and workaround trend, post go-live. Not the defect count itself, the shape of the curve. Defects that trail off while workaround requests keep climbing means the software shipped but the process did not.
    • Training completion versus proficiency. Completion tells you people sat through it. Proficiency, measured by whether they can complete a real transaction unassisted two months later, tells you something different. Almost nobody tracks the second one.

    Ten minutes with whoever owns each of those systems usually turns up more real signal than a month of status meetings. The data was never designed to answer this question, but it was collecting the answer anyway.

    The same signal can mean two opposite things

    The hardest part of this practice is that every good sign has a bad twin. They look identical from a distance. Escalations dropping means people found a working path, or it means people stopped believing anyone would act on them. Workaround chatter going quiet means the gap closed, or it means the team gave up flagging it. A quiet week can be the best week of the program, or the first sign of disengagement. A status report cannot tell you which.

    The only way to tell them apart is to ask, directly. It takes the same discipline that turns a vague objection into a real requirement. Do not accept the absence of a signal as good news until someone checks. When escalations drop, ask the team who used to raise them. Did the problem go away, or did they just stop bringing it up? Do this on a schedule, not only when something feels off. By the time something feels off with disengagement, it has usually been building for months.

    Somebody has to own collecting this, on a cadence

    None of the above happens by accident. It does not happen from one director reading meeting notes once a quarter. It needs an owner and a rhythm, separate from status reporting. Pencil in a short recurring check-in, every one to two weeks. The question is not “what did you complete,” but “what did you notice, and what changed that nobody logged.”

    Rotate who is asked. A single source of “good news” every week is not a trend, it is one person’s optimism. Confirmation bias is easiest to catch when you can see whose voice is missing from the pattern over time.

    What this is worth saying out loud to the people above you

    The consequence of skipping all of this is not abstract. A multi-year program that only ever shows “in progress” on a milestone chart starts to look stalled to the people funding it. That is true whether or not it actually is. Steering committees deprioritize what looks stuck. Teams disengage from a plan that never seems to finish. This happens even while the real transformation is well underway beneath the chart they are staring at.

    The fix is not replacing the milestone chart. The committee still needs it. It is walking in with both: the task-completion view they expect, and the adoption evidence that answers the question milestones were never built to answer. That evidence looks like system usage shifting, ticket mix changing, escalations resolving without you.

    Naming that second view out loud, on a cadence, is the same practice behind building real shared understanding. It replaces just sending more updates. It is often the difference between a program that gets the benefit of the doubt through a slow quarter, and one that does not.

    Where AI actually helps here

    None of this needs to be automated to be useful. Turning it into a dashboard too early tends to flatten exactly the nuance that makes it worth doing by hand. What AI is genuinely good at is being a thinking partner across more raw material than one person can hold in their head at once. Using it that way changes each piece above.

    The reporting problem needs a skeptical reader. Feed it your notes before the steering committee meeting. Ask it to argue the skeptical read: why would this not be enough evidence? You want the weak spots in your own story surfaced in private, not live in the room.

    For the data problem, it is a fast way to brainstorm what exhaust already exists in systems you have not thought to check. Think ticket tools, login logs, training platforms. Do that before you go ask their owners for it.

    The two-faced signal problem needs a different move. Ask it, every time, what it would mean if this were actually the bad version. Let it hold that second read until someone verifies which one is true.

    Ownership and cadence benefit from the same trick. It can sit across weeks of raw check-in notes and flag what a single re-read would miss. For example: the same person always reporting the good news, or a thread mentioned once in week three that quietly never came up again.

    Finally, the scenario itself, the specific detail that makes any of this credible, works best when AI plays interviewer. It pushes past “things are going well” until it gets specifics: a name, a system, a week, a thing someone actually said.

    What to walk into the room with

    None of that replaces judgment. It extends how much a director buried in status updates can actually notice, which was always the real constraint here.

    The steering committee wants the milestone chart, and it should get one. The team building the future deserves to hear, just as often, the version of progress that milestones were never built to capture. That version needs to be backed by evidence, checked for the version that says otherwise, and owned by someone on a schedule.

    More essays like this one live on the Between Mondays articles page.

    Further reading: the U.S. Government Accountability Office’s Schedule Assessment Guide and the Project Management Institute. Both publish on measuring real progress across long, complex programs.

  • Why Stakeholders Resist Change (and Why That’s Not the Problem)

    Why Stakeholders Resist Change (and Why That’s Not the Problem)

    Resistance is not the obstacle. It is the clearest requirements document you will get for free.

    A downstream report broke during testing, three months into a program that was otherwise on track. The number behind it had been wrong for years, quietly corrupting billing data nobody had traced back far enough to notice. The person who could have stopped it had already tried. In a requirements workshop months earlier, she had flatly refused to let a single field get cut from the new design. Nobody on the project team could find a use for it. Two people gently suggested she let it go. She would not move, so the team noted her as resistant, worked around her, and kept the agenda moving.

    That field was the only place a specific reconciliation number lived, the one she pulled by hand every month to catch a billing error nobody else knew existed. She had not been resisting change. She had been protecting the one piece of the current process that actually worked, and nobody had asked her why it mattered before deciding it did not.

    Resistance is data, not a problem to manage

    Most of what gets labeled resistance is not opposition to change itself. It is a person telling you, in the only language available to them in that moment, that the proposed future does not yet account for something they know to be true. Treating that as a behavior to overcome, something to manage with better change communication or more stakeholder buy-in sessions, throws away the most specific input you are going to get. It is the same instinct behind treating a process gap as a failure to correct instead of information about how the system actually works: the reaction contains the requirement, if you are willing to ask instead of push past it.

    This reframe changes what a requirements conversation is for. The goal stops being persuasion, getting the room to agree with the design, and becomes discovery, finding out what the pushback is protecting before deciding whether it still needs protecting.

    Telling protective resistance from comfort resistance

    Not every objection is a hidden requirement. Some really are just discomfort with change, and pretending otherwise wastes just as much time as ignoring the ones that matter. The two look identical in the room. They sound different the moment you ask one follow-up question: “What would actually break, for you or for someone downstream, if we did this anyway?”

    • If the answer is specific, a report, a reconciliation, a downstream team, a regulatory check, a manual workaround for a known defect, you are looking at protective resistance. Treat it as a requirement that has not been written down anywhere yet, because it hasn’t. It has only ever lived in one person’s head and their weekly routine.
    • If the answer is vague, “it just feels risky,” “we’ve always done it this way,” “I’m not sure, it just seems wrong,” you are looking at comfort resistance. That is real too, and worth acknowledging directly, but it is a change-management conversation, not a requirements one.

    The test is not whether someone can articulate their objection well in the moment. Plenty of people who are protecting something real are bad at explaining why on the spot. The test is whether a concrete consequence exists at all, findable or not yet found. That is what step two, below, is for.

    Where this shows up, and what to actually do

    The pattern repeats across every phase of a program. Each phase needs a specific action, not just a reframed question.

    • Requirements validation. Pushback on removing a field, a step, or an approval is rarely about the field itself. Before the decision gets made, not after, trace it: who consumes this today, by name, and what do they use it for. Do not let “we couldn’t find a use for it” stand in for “we asked the person who uses it.”
    • Current-state mapping. When someone insists the documented process is wrong, do not note it and move on. Schedule a short, dedicated follow-up with that person specifically, walking the actual steps they take, in order, including the parts that feel too obvious to mention.
    • Future-state design. When a stakeholder pushes back hardest on a proposed future workflow, the fix is not a better explanation after the fact. It is bringing that person into the design conversation itself, before the workflow is finished enough to defend, starting from their own picture of success rather than presenting one already built.

    A three-step response, not a slogan

    When resistance shows up in the room, run it through the same three steps every time:

    1. Ask what it protects. “What would break, for you or downstream, if we did this anyway?” Ask it plainly, without defensiveness, and let the silence sit if it takes a moment to answer.
    2. Verify the answer instead of taking it at face value or dismissing it. Trace the field, interview the downstream consumer, pull the report, check the regulation. This is the step teams skip most often, either accepting the objection uncritically to avoid conflict, or waving it off to keep the agenda moving.
    3. Decide, and document the reason, not just the outcome. Keep it as-is, redesign around it, or consciously retire it, but write down why, in terms of what was verified in step two.

    The stakeholder who won’t let go of a requirement is usually the one who understands the current state best.

    What this is not

    This is not a mandate to keep every field, step, or approval anyone objects to. It is not a script for winning an argument, and asking “what does this protect” as a rhetorical move, without actually verifying the answer, is worse than not asking at all, because it trains people to stop bringing concerns forward. It is also not a reason to skip the harder comfort-resistance conversations by relabeling them as protective. The three-step process above only works if step two is real, if you actually go check, rather than accepting or dismissing what you hear in the room. It is the same discipline behind building real shared understanding instead of just sending more updates.

    The stakeholder who pushes back hardest in a requirements session is frequently the same one who, three months later, would have told you exactly where the future state was about to break, if anyone had asked what success looked like to her before deciding what to build.

    More essays like this one live on the Between Mondays articles page.

    Further reading: the American Psychological Association and the Project Management Institute both publish on the psychology of resistance and requirements practice.

  • The Power of Shared Understanding

    The Power of Shared Understanding

    How alignment isn’t created in isolation. It’s built through communication and coordinated clarity.

    Two team leads sat in the same thirty-minute call, listening to the same decision get made. A week later, one had told their partner the rollout was delayed a month. The other had told theirs it was delayed two weeks, contingent on a fix that was already in progress. Nobody had lied. Nobody had missed the call. They had simply heard the same sentence and built two different pictures of what it meant, and neither picture got corrected until a partner asked why the two teams were telling a different story.

    I have been chewing on something all week. We talk a lot. We meet, we send updates, we document decisions, we write plans. By any honest measure we communicate constantly. And yet I keep running into moments like that one, where two people walk out of the same conversation carrying two different versions of what was decided. That should bother us. It bothers me.

    Communication is not the same as understanding

    Here is where I landed. We have been treating communication as the goal when it is really just the tool. The goal is shared understanding, and those two things are not the same. I can send a perfectly clear message and still not reach you. You can nod in a meeting and still leave unsure. Information moving from one person to another is not the same as two people actually seeing the work the same way.

    That gap matters more on programs like this than almost anywhere else. When you are replacing many interconnected systems at once, coordinating across partners who have run their own operations for years, you are asking a lot of people to trust a picture of the future they cannot fully see yet. Alignment on work like this does not happen because someone held a meeting or published a document. It happens when people across every team and every partner genuinely understand what is being built, why it matters, and what their part in it is. It is the same understanding gap that makes the story behind a decision matter as much as the decision itself.

    Three habits that close the gap

    So what actually needs to change. A few things worth getting more deliberate about:

    • Seek understanding before giving direction. Before handing someone a direction, you owe them the work of understanding where they are starting from. This is especially true with partners. They are not resisting for the fun of it, they are protecting something that has worked for them, and if you do not understand what that is, your direction lands as a demand instead of a shared plan. It is the same instinct behind starting from a partner’s picture of success instead of a finished plan.
    • Communicate proactively instead of reactively. Most of the hardest conversations happen after something has already gone sideways. In practice this means a standing rule, not a good intention: if something changes that affects another team or partner, they hear it the same day, from you, before they have a reason to ask.
    • Confirm understanding, do not just deliver a message. Ask people to say back what they heard, in their own words, before assuming a room left aligned. Call it the read-back: one sentence, in the other person’s own words, on what they think just got decided and what it means for their part of the work.

    As a director, the temptation is to measure success by how much you have communicated: how many updates went out, how many meetings were held, how thorough the documentation is. None of that is the actual goal. The actual goal is whether the people doing the work and the people depending on it are seeing the same picture.

    Communication is what you send. Shared understanding is what actually arrives.

    The quiet warning sign

    There is a tell for when the gap is opening up, and it is quieter than most people expect. It is not conflict. It is two people giving you the same answer with different confidence, or in slightly different words, when you ask them separately what happens next. Confident disagreement is easy to catch. Two calm, cooperative people who are each certain of a different thing is the actual warning sign, and it almost never shows up in the meeting itself. It shows up a few days later, in a hallway conversation or a partner’s confused email, once the gap has already turned into a real problem, often for the same quiet reasons a process gap goes unreported, or a transformation quietly stalls without anyone naming it.

    Closing that gap is slow, unglamorous work. It means asking more questions than feels efficient, checking for understanding when it would be faster to assume it, and treating a moment of confusion as information instead of an inconvenience. But it is the difference between a team that is technically informed and a team that is actually aligned, and only one of those gets the work done.

    More essays like this one live on the Between Mondays articles page.

    Further reading: Gallup Workplace and MIT Sloan Management Review both publish extensively on team alignment and organizational communication.

  • Start With Their Picture of Success

    Start With Their Picture of Success

    The strongest collaborations do not start with a plan. They start with a question. What does success look like to you? It is a simple thing to ask and an easy thing to skip, and skipping it is where a lot of good projects quietly go wrong.

    When we bring partners into a program, the instinct is to show up with the plan already shaped and ask them to help carry it. It feels like a good use of everyone’s time. The plan exists, it is reasonable, and walking someone through it feels like progress. But it skips the step that actually makes partnership work, which is understanding what winning looks like from where they sit.

    What a partner’s current process is actually protecting

    Partners who have run their own operations for years did not arrive at their current way of working by accident. It survived contact with real constraints:

    • Budget cycles that do not line up with the program’s own timeline.
    • Staffing realities that limit how much change they can absorb at once.
    • Relationships with their own stakeholders, built over years, that a new plan can put at risk.
    • Past efforts that failed for reasons nobody wrote down, and no one wants to repeat.

    When a plan shows up without first asking about any of that, it reads as a demand instead of an invitation, even when nobody intended it that way — the same blind spot that makes an undocumented workaround look like a mistake instead of a reasonable adaptation.

    A plan that skips their picture of success is not really a shared plan. It is your plan, waiting for their agreement.

    What asking early actually buys you

    Asking the question early does two things at once. It surfaces constraints early, while there is still time to design around them, instead of months later when a decision that felt final has to be unwound. And it signals something about the relationship itself: that this is being built together rather than delivered to them. That signal matters more than most schedules give it credit for. People commit differently to a plan they helped shape than to one they were handed.

    As a director, this is one of the cheapest habits to adopt and one of the easiest to forget under deadline pressure. It takes one conversation, maybe two, before the plan is fully formed. What it buys in return is a partner who can tell you early when something will not work, instead of one who nods along and quietly routes around the plan later — the same slow, quiet erosion that makes a transformation feel stalled long after the real damage was done.

    The picture of success a partner describes rarely matches the plan word for word. That gap is not a problem to smooth over. It is the actual starting point. Find it first, and the plan you build from there has a real chance of being one both sides actually want to see through.

    More essays like this one live on the Between Mondays articles page.

    Further reading: the Project Management Institute and Harvard Business Review both cover stakeholder alignment in more depth.

  • Why the Gaps You Find Are the Point

    Why the Gaps You Find Are the Point

    A few months into any process improvement effort, someone on the team says some version of the same thing. “I thought we all did it the same way.” Then it turns out three people on the same team handle the exact same task three different ways, and none of those ways match what the manual says, and none of them match what leadership thinks happens.

    The instinct is to treat this as a problem. Somebody did not follow the process. Documentation is out of date. Training failed somewhere. All of that might be true. But there is a more useful way to think about it, one that comes out of safety and reliability research, not management theory.

    Treat the gap as data, not a verdict

    In that world, a gap between the documented process and the actual process is not treated as a failure. It is treated as data. It tells you where the written process does not match the conditions people are actually working in. Maybe the manual assumes a resource that is not always available. Maybe the “correct” way takes twice as long under real workload, so people quietly built a faster path that mostly works. Either way, the gap is information about the system, not a verdict on the person.

    A process nobody actually follows is not a process. It is a suggestion with better formatting.

    As a director, the instinct when you find one of these gaps is to close it immediately, tell everyone to follow the documented process, and move on. That instinct is usually wrong, or at least premature. Ask why the gap exists before deciding which side of it is right:

    • Sometimes the documented process is correct and people drifted from it for reasons worth correcting.
    • Just as often, the workaround people invented is the more honest description of how the work actually gets done, and the manual is the thing that needs to change.

    What changes when gaps are safe to report

    This reframe changes how a team responds when gaps surface. Instead of bracing for blame, people start bringing the gaps forward voluntarily, because they have seen that surfacing one leads to a better process rather than a harder conversation. That shift alone is worth more than any individual fix. A team that hides its workarounds cannot be improved. A team that surfaces them can — the same shift in posture that makes it possible to tell the truth plainly in a status update instead of dressing it up.

    The goal was never for everyone to do it the same way for its own sake. The goal is for the way it gets done to actually work, to be known, and to be something the organization chose rather than something that accumulated by accident. Finding out three people do it three different ways is not the failure. Not finding out would have been — it is the same quiet blind spot that makes a transformation feel like it is stalling when it is actually just under-measured.

    More essays like this one live on the Between Mondays articles page.

    Further reading: OSHA and NIST both publish extensively on treating near-misses and process deviations as safety signal rather than blame.

  • The Story Behind the Decision

    The Story Behind the Decision

    How we communicate complex work, and earn the trust to lead through it

    There is a particular moment that shows up in every major technology program. Something has to be decided. Maybe the original plan no longer fits the reality on the ground. Maybe two paths forward exist and both carry risk. Maybe a deadline is slipping, a vendor relationship is strained, or a design assumption from months ago no longer holds. Whatever the trigger, the team has done the hard work of understanding the problem. Now the work shifts, and it shifts to communication.

    How we tell the story surrounding that decision matters more than most people realize. Not because the truth needs to be dressed up or spun. But because leadership, the people with the authority and accountability to act, can only make good decisions when they clearly understand what they are deciding and why.

    This is one of the most important skills a director can build. Not just for escalation moments, but every week, in every written update, status report, and hallway conversation. Much of the job is translating complex work into something that makes sense to people who are not living inside it every day — the same translation work that makes a slow-feeling transformation legible to the people funding it.

    The team that can explain what it is doing, and why it matters, earns the credibility to keep doing it.

    If anything, complexity is the reason we have to be more intentional about it. The more complex the work, the more important it is that the people responsible for the organization’s success can understand what is happening and why it matters.

    Where updates usually go wrong

    There is a version of this that goes wrong often enough to name directly. A team gets so close to a problem that it forgets what it sounded like before it understood it. The update comes out dense with acronyms and caveats, technically accurate and functionally useless to the person reading it. That person then makes a decision based on a headline instead of the substance, because the substance was never made available to them in a form they could use.

    Three questions worth answering before the meeting

    The fix is not to simplify the truth. It is to do the translation work before the meeting instead of during it:

    1. What is the decision, in one sentence?
    2. What are the real options, in plain terms?
    3. What happens if we choose wrong?

    A leader who can answer those three questions clearly has usually already done the hardest part of the job. It is the same discipline behind naming a process gap plainly instead of burying it — the gaps a team finds are the point, not something to explain away.

    We have an obligation to meet people where they are. To translate. To simplify without being condescending. To tell the story around the decision, not just the decision itself. When we do that well, we do not just get better outcomes on the immediate issue. We build the kind of credibility that makes everything else easier.

    More essays like this one live on the Between Mondays articles page.

    Further reading: Harvard Business Review and the Project Management Institute both write regularly on communicating decisions under uncertainty.

  • Why Transformation Feels Slow

    Why Transformation Feels Slow

    Most people expect change to feel like change. They imagine a clear before and after, a moment where the old way gives way to the new. What they get instead is months of meetings, miscommunication, and incremental progress that barely registers on a day-to-day basis. It can feel like nothing is working. Usually, everything is.

    The trouble is that real transformation requires three things to shift at once, and each one moves at a different speed:

    • Processes — the easiest to document, and the hardest to actually change once people have muscle memory built around the old way.
    • Technology — needs configuring, integrating, testing, and retesting, and no system survives contact with reality without adjustments nobody budgeted time for.
    • Culture — the slowest of the three. It shifts only through repetition and through leadership behaving consistently with the stated values, over and over, for a long time.

    Together, these three create a pace that can look, from the outside, like stalling. Processes are the easiest to document and the hardest to change. People have muscle memory built around the old way. Even when they understand the new approach intellectually, their instinct is to fall back on what they know when things get busy or stressful. That is not resistance. That is just being human.

    How to lead through the slow middle

    A go-live date changes a system. It does not change a habit.

    So progress tends to feel invisible for a while. Teams are learning. Systems are stabilizing. Habits are forming beneath the surface. And then something clicks. A team hits a milestone that felt impossible six months ago. A process that used to take three days takes three hours. People stop asking how the old system worked because they have genuinely stopped thinking about it.

    As a director running programs like this, the hardest discipline is resisting the urge to manufacture a feeling of speed. It is tempting to add a dashboard, a new status color, a fresh set of metrics, just so the pace looks faster than it feels. None of that changes the underlying math. Three systems have to shift together, and none of them shift on command. It is the same discipline behind asking a partner what their picture of success looks like before handing them a plan — slowing down on purpose, in the moment it is least comfortable to do so.

    What actually helps is naming the slowness out loud, early, before anyone starts to panic about it. Tell the team and the stakeholders: this will feel slower than it is. Explain why. Then keep pointing at the small, real signs of movement instead of waiting for one big moment that proves the change worked. Those moments rarely arrive on schedule. The quieter evidence is there the whole time, if you know where to look — often in the same unglamorous places a team’s process gaps turn out to hide it.

    That is the shape of meaningful change. Getting the story right when you have to explain that pace to leadership is its own skill, one worth as much attention as the change itself.

    More essays like this one live on the Between Mondays articles page.

    Further reading: McKinsey on organizational transformation and the Project Management Institute both cover the mechanics of large-scale change in more depth.