Between Mondays

Author: Brad McKinney

  • When the Vendor Relationship Gets Strained

    When the Vendor Relationship Gets Strained

    The contract says what they owe you. It says nothing about what happens when the relationship is the thing actually at risk.

    A vendor relationship gets strained the same way most program problems do: quietly, one small accommodation at a time. Eighteen months into a multi-year systems replacement, a vendor missed a delivery date for the third time in a quarter. Nobody on our side was surprised anymore, and that was the real problem. The first miss had triggered a hard conversation and a recovery plan. By the third, the conversation had turned into an email thread, then a status-report line item, then a shrug in the hallway. The relationship had not broken. It had gone quiet. Quiet is worse. It means both sides have started managing around each other, instead of managing the problem together.

    Strain rarely announces itself

    Nobody wakes up and decides the vendor relationship is now adversarial. It erodes one small accommodation at a time. A deadline slips, and the team absorbs it without a real conversation about why. Whoever is more tired that week resolves a scope question, instead of checking what the contract actually says. A status call that used to run long with real problem-solving now ends in exactly thirty minutes. Neither side wants to be the one who brings up what is actually wrong.

    The strain usually shows up in the data months before anyone says the words “this relationship is strained” out loud. Meeting notes get shorter. Escalations that used to come with context start arriving as bare facts. The vendor’s project lead stops copying their own leadership on updates that used to include them. None of that shows up on a status report built around milestones. All of it is the early warning system, if anyone is looking.

    A vendor relationship does not fail on the day of the missed deadline. It fails in the weeks before, when nobody says out loud that something has changed.

    Contract enforcement and relationship repair are different tools

    The instinct when a vendor underperforms is to reach for the contract. Cite the SLA, document the miss, escalate through the account team. Sometimes that is exactly right, and skipping it does not serve anyone. But contract enforcement only answers one narrow question: did the vendor meet the obligation? It does not answer the question that actually determines whether the next eighteen months go well. That question is whether both sides still trust each other enough to surface problems early.

    Those are two separate tracks, and the mistake is running only one of them. A team that only enforces the contract gets compliance without candor. The vendor delivers exactly what the contract says, and nothing more. That includes the early warnings that used to come free when the relationship was healthy. A team that only tends the relationship, without ever naming the pattern of misses directly, gets candor without consequence. The misses keep happening, because nothing has actually changed the vendor’s incentives.

    Both tracks need to run at once, and they need different owners in the room. The contractual conversation belongs with whoever owns the commercial relationship. The relationship conversation belongs with whoever actually works with the vendor’s team day to day. It needs to happen even when, especially when, the contractual conversation is tense.

    Naming the pattern without accusation

    The hardest part of this is the conversation itself. One version sounds like a grievance list. It puts the vendor on the defensive before anyone says anything useful. Another version treats the pattern as a shared problem to solve. That version tends to get somewhere.

    The difference is usually in how the conversation opens. Not “you have missed three dates,” which is true but invites a defense. Something closer to this works better: here is the pattern we are both seeing. Here is what it is costing on our side. We want to understand what is driving it before we decide what to do about it. That framing assumes the vendor’s team is not trying to fail. Usually they are not. Usually there is a resourcing problem, a scope ambiguity, or a dependency on something outside their control. Naming the pattern this way surfaces the real cause, instead of triggering a defense.

    • Bring the pattern, not just the latest incident. One missed date is an incident. Three is a pattern, and patterns deserve a different conversation than incidents do.
    • Ask what changed on their side before assuming what changed on yours. A vendor whose best people rotated onto a different account is a different problem than one who simply stopped trying. So is a vendor whose subcontractor fell behind.
    • Separate the relationship conversation from the escalation conversation, even when they happen in the same week. One is about restoring trust. The other is about consequences. Blending them turns every relationship conversation into a negotiation.
    • Decide together what “back on track” looks like, specific enough that both sides would recognize it without anyone saying so. A vague commitment to “do better” is not a recovery plan.

    Escalating on a vendor issue is not different from escalating on any other

    This is the same discipline as any other hard call on a program. A strained vendor relationship rarely affects only the two teams having the tense conversation. Teams depending on that vendor’s deliverable for their own timeline need to see the real picture, not a softened version. Otherwise they keep planning against a date that everyone closer to the problem already knows is at risk. Solving a vendor problem in isolation creates the same blindside that isolation creates anywhere else on a program. It happens quietly, managing around the problem while a status report still shows green.

    It also helps to remember that this vendor was a partner once, before the strain set in. Partnerships that work start by understanding what success looks like from the other side of the table. A strained vendor relationship is often a partnership that skipped that step. Or it is one that did the step once at kickoff and never came back to check whether the picture had changed. The same resistance you would expect from a skeptical internal partner shows up here too. It is rarely resistance for its own sake. Usually the vendor’s team is protecting something: a margin, a staffing commitment, a relationship with their own leadership. Understanding what that is changes the conversation.

    Protecting a vendor relationship and protecting your own program are not in conflict as often as people assume. Most of the time, the relationship survives the conversation you were avoiding. It does not survive the silence.

    Where AI actually helps here

    This is not a place to let a tool run the relationship. People rebuild trust in conversation, not in a generated message. What a thinking partner is genuinely good for is preparation and pattern-spotting. Those are the two things that are easy to under-invest in when a vendor relationship is already consuming emotional energy.

    Before the hard conversation, describe the pattern you are seeing. Ask it to draft the opening framing two ways: once as a list of grievances, and once as a shared problem. That way you can feel the difference before you are in the room. Then you can pick deliberately, instead of defaulting to whichever version comes out first when you are frustrated.

    Across a longer relationship, it is useful for exactly the kind of pattern-spotting that is hard to do from memory. Feed it a quarter of status notes and meeting summaries. Ask when the tone actually shifted, not when the first missed date happened. Those are often different weeks. When a recovery plan comes back from the vendor, ask it to check the commitments. Are they specific enough to verify, or just language that sounds like progress but resolves nothing?

    None of that replaces sitting across from the vendor’s team and having the conversation nobody wanted to start. It only means you walk in having already thought through what you are actually trying to say.

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

    Further reading: the Project Management Institute publishes extensively on vendor governance and contract management in complex programs. The U.S. Government Accountability Office has published widely on contract oversight and vendor performance management on large public programs.

  • Escalate or Absorb: A Framework for the Call Nobody Wants to Make

    Escalate or Absorb: A Framework for the Call Nobody Wants to Make

    You are not deciding the outcome. You are deciding who needs to see the problem clearly enough to help decide it.

    Every program leader eventually faces the same quiet question: escalate, or absorb? A dependency slipped three weeks before a planned cutover. The team closest to it worked the technical angle for two days, found a workable path, and had a recommendation ready before anyone outside the team knew there had been a problem. It was a good recommendation. It was also missing something nobody in that room could have seen: the staffing plan for a partner team that had built its schedule around the original date, and a budget line that assumed the old timeline held. Both surfaced a week later, after the recommendation had already hardened into a plan. Neither was a surprise to the people who owned them. They were only a surprise to us, because we never asked.

    The real question is not escalate or absorb

    Every program leader faces some version of this moment. Something breaks, or is about to. The instinct is to treat the choice in front of you as a binary about risk tolerance: push it up, or handle it here. That framing feels practical, but it skips a step that matters more than either option. Both versions of that question assume the job is to decide the outcome. It is not. The job is to decide who needs to see the problem clearly enough to shape the decision with you, before any outcome gets decided at all.

    Get that step right and escalate-or-absorb mostly answers itself later. Skip it, and it does not matter which one you picked. You already made the mistake.

    Solving in isolation feels like competence

    It rarely looks like a mistake in the moment. You have the expertise. You can see the technical shape of the problem faster than anyone else, and looping in four or five other leaders feels like it will slow down a decision that needs to move now. So you work it through with the two or three people closest to the detail, and you arrive at a clean recommendation. It feels efficient. It feels like ownership.

    The moment you have a preferred outcome before the impacted people are in the room, you have stopped being a steward of the message and started being an advocate for a conclusion.

    That distinction, steward versus advocate, is the whole framework. A steward’s job is to make sure the people who will live with a decision have an accurate, complete picture of the situation in time to shape it. An advocate’s job is to get a particular answer approved. Both can look like leadership from the outside. Only one of them holds up when the problem turns out to be more complicated than it looked from where you were standing, and it almost always is, because you were never standing where everyone else was.

    What pulling people in actually looks like

    This is not a call for consensus by committee, and it is not about slowing every decision down until everyone has signed off. It is about being deliberate, early, about who is impacted, and getting them the same picture you have before the path forward hardens into something that is socially expensive to change.

    • Map every area the problem touches, not just the area where it started. A dependency issue is rarely only a technical issue. It is a staffing issue, a partner-communication issue, sometimes a budget issue, and the people who own those angles will see risk in the first ten minutes that would take the technical team a week to find alone.
    • Bring the problem before the recommendation. Share what you know and what you still do not know. Showing up with the answer already built makes it socially expensive for anyone to raise something you missed, even when they can see it clearly.
    • Ask the people closest to each impacted area what they see that you do not. Not as a formality. Some of the best catches on this program have come from someone whose piece of the puzzle looked unrelated, right up until they said the one sentence that reframed the whole problem.
    • Decide together what happens next, even if you are the one who ultimately carries it forward or escalates it further. The value is not in a vote. It is in the decision being shaped by everyone who has to live with it.

    Escalate or absorb becomes an easier question once you have done this

    Here is the part that surprised me the first few times I actually practiced it. Once the right people are in the room with an accurate picture, the escalate-or-absorb question mostly answers itself. If the impacted leaders look at the full picture and see something the group can handle within its own authority, you absorb it together, and everyone downstream already understands why. If they look at the same picture and see something that needs a decision above your collective authority, escalation is not a failure or an admission you could not handle it. It is the natural next step for a group of people who already did the hard work of understanding the problem the same way, clearly enough to hand it up in a form someone else can act on.

    Either way, nobody is blindsided later. Nobody finds out secondhand that a decision touching their team was made in a room they were never invited into.

    Where AI actually helps here

    This is not a step to automate. Deciding who belongs in the room is a judgment call, and the value of that call comes from actually talking to the people in it, not from a checklist that generates itself. What a thinking partner is genuinely good for is stress-testing the map before you convene anyone. Describe the problem and ask it to push back on your list of impacted areas: what teams, budgets, or partner relationships touch this that you have not named yet. You want the gaps in your own picture surfaced in private, before the meeting, not live in front of the people you invited.

    It is also useful after the fact, on the discipline itself. Feed it your notes from a recommendation that hardened before the right people saw it, and ask what would have looked different if the impacted leaders had been in the room three days earlier. That kind of after-action read is easy to skip when the outcome turned out fine anyway. It is exactly the pattern that catches up with you on the next one.

    None of that replaces the room. It only makes sure you know who belongs in it before you start.

    Being a steward of the message means the people affected by a decision never learn about it after the fact. They were in the room while it was still a question.

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

    Further reading: the Project Management Institute on governance and escalation paths in program management, and the U.S. Government Accountability Office, which publishes extensively on risk oversight and reporting discipline in large public programs.

  • 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.