Most leadership posts about deadlines on LinkedIn sound the same.
"The date was impossible. We hit it anyway."
Long heroic story. Late nights. One photo of someone asleep at a desk. A note about resilience. A vague compliment to "the team." Then back to whatever the founder was selling that week.
Here is a less common leadership flex.
"We looked at the actual risk, we protected the client, and we moved the date."
That is the version I want to write down today, because it is the version more teams should be running, and because the one time my delivery team did it cleanly is a story I keep coming back to.
What actually happened
A few weeks ago, one of our long-running clients was winding down their website. Years of relationship. A site we had built, supported, secured, and watched a brand grow on top of. The kind of engagement where the original kickoff was sometime back when our daughter was still in elementary school.
Closure work like that is more complicated than people think it is.
You are dealing with backups. With DNS. With security tooling. With email handoff. With payment integrations that have been quietly running for years. With vendor accounts that someone needs to either transfer or terminate. With domain expirations that are scheduled in different places, by different people, on different platforms.
Each one of those has a way to break loudly. The cost of a small mistake on the way out is a public outage on a site the founders still emotionally own, even though they are stepping away from the business behind it.
The original closure date was March 11.
A few days into the work, our team disconnected the security tool one step too early in the sequence. Specifically, the WAF and malware-scanning layer was wound down before the rest of the closure had completed. The site flickered. Nothing catastrophic. No data loss. A small dip in availability for a few minutes. Enough to make the room go quiet on the internal call.
Our delivery team paused. They looked at what was left to do. They re-sequenced the remaining tasks. And then they did something I want more teams to feel allowed to do.
They moved the date to March 30.
Not because the team was slow.
Because the team was honest.
The brave move was naming the gap, not pushing through it
The instinct under deadline pressure is to grind. Add hours. Move blockers off-screen. Ship the date because the date is the date.
That instinct is taught early. Most of us learned it in school, where the deadline was the assignment and the assignment was the grade. Then we carried it into work and called it "delivery."
The instinct that is harder to develop is the one that says, "this date no longer serves the client, the outcome, or the team. We are going to change it, and we are going to tell everyone why."
The first instinct gets celebrated on LinkedIn. The second one gets the better outcome.
The clue is usually emotional. When a date stops feeling like a tool and starts feeling like a thing you are defending in front of yourself, you have already left engineering and entered politics. The conversation is no longer about how to do the work. It is about how to look while the work is being done.
The brave version of leadership is naming that out loud. To the team first. To the client second. With specifics.
The line our delivery lead wrote in the daily update was almost embarrassingly plain.
"The due date for remaining closure tasks was moved from March 11 to March 30, 2026 to allow more time for careful completion."
No drama. No throat-clearing. No "given current capacity constraints." No "we are committed to excellence and therefore." Just the new date, the reason, and the part the client gets to be part of.
The client read it, agreed with it, and the closure work finished cleanly nineteen days later. Nothing else broke.
I trust that team a little more this quarter than I did last quarter. The reason is not that they hit a date. It is that they did not.
Due dates are tools, not commandments
This is the framing shift I want more service firm leaders, and frankly more founders, to make.
A due date is a tool. It exists to align humans around a shared horizon. It is supposed to make the work go better.
The moment the date is making the work go worse, you should be willing to renegotiate it. Out loud. With reasons.
Most of the dates on your roadmap right now were set six weeks ago by someone who had less information than you have today. The roadmap was a guess. A useful guess, but a guess.
You are allowed to update the guess.
The reason most leaders do not is not engineering. It is identity. Somewhere along the way, we decided that "delivers on time" is the headline metric of being good at the job. So a moved date feels like a missed date, which feels like a personal failure, which we would rather avoid than admit.
I have done this myself. More than once. There are dates on my own past roadmaps that I held too long because the cost of moving them, to my own ego, felt larger than the cost of holding them. The math was almost never right. The team paid for it. The client paid for it. The relationship paid for it.
A moved date and a missed date are not the same thing.
They look the same on a Gantt chart. They feel very different to the client.
A moved date, communicated early, with a specific reason, with the new commitment named: that is leadership.
A missed date, surfaced late, with vague language about "challenges": that is operations debt.
A missed date can usually be traced backwards to a moment, two or three weeks earlier, where someone in the room had the information needed to move the date, and chose not to surface it. That is the moment I want more leaders to be brave at.
The script we use before moving any date
When my delivery lead and I sit down to ask "should this date move?", we have four questions we walk through. None of them are clever. All of them are uncomfortable.
1. What is the cost to the client of holding the original date?
Not to us. To them. Be specific.
If we hold the date, what does the client pay? In dollars, in risk, in customer experience, in trust.
For the closure-work example, the cost of holding March 11 was a real risk of another small outage on the way out. The cost of that outage to the client was not the few minutes of downtime. It was the last impression the brand left on its remaining customers.
Holding the original date was protecting our pride. Moving it was protecting their reputation.
When the cost of holding is borne by the client and the benefit is borne by us, the date should always move.
2. What is the cost to the team of holding it?
Burnout. Mistakes. The next-client-suffers cost. Be specific.
A team that hits a date by going through fire is a team that will leave you within twelve months. A team that hits the next date by going through more fire is a team that will leave you within six.
There is a thing some founders do where they call this resilience. It is not resilience. It is a slow-motion attrition event with a heroic story stapled to the front.
The honest version of this question is, "if we hold this date, what is the probability the team makes a different, larger, costlier mistake on the next project?"
If the probability is non-trivial, the cost of holding is not measured by the current project. It is measured by the one after.
3. If we knew what we know now, would we have set this date in the first place?
If no, the original date is debt.
Debt can be carried. Debt can also be retired. The question is whether carrying it is cheaper than retiring it.
Most of the time, when leaders ask this question honestly, the answer is no. The date was set in good faith based on a smaller set of information. The information has changed. The date has not. The right move is to update the date, not to defend the moment in which it was set.
There is a corollary here that is worth saying out loud. If the original date was a stretch goal that the team never quite believed in, and now reality has come back to confirm it, the brave move is not to extend that fiction further. It is to acknowledge it and replace it.
4. What is the new date we can commit to and not move again?
If we cannot answer that one, the new date is not a date yet. It is a hope.
The single most expensive version of "moving the date" is moving it to a new arbitrary number that you have not actually pressure-tested. That is not moving the date. That is rolling the same dice again, with the same odds, and pretending you are doing something different.
When we move a date, the new date has to come with a small amount of slack and a list of the specific things that have changed since the old date was set. If the new date cannot survive those two tests, the conversation is not about moving the date. It is about scoping the work down, or breaking it apart, or surfacing a risk that we have not been naming.
If you cannot make it through those four
The answer is not always to move the date. Sometimes the answer is to hold the date because the cost of moving it actually is higher than the cost of holding it. Sometimes the work that needs to happen is not date-related at all. It is scope-related, or trust-related, or staffing-related.
The four questions are not a script for permission to slip. They are a script for honest conversation.
When we sit with them, the outcome usually falls into one of three buckets.
We hold the date and find one specific thing to scope out, so that what ships on the date is smaller but cleaner.
We move the date and commit to a new one with the specific changes named.
We surface a different problem entirely: the team is short, the client expectations are misaligned, the work was never the right work in the first place. The date was the symptom, not the problem.
Most teams I have watched do this well end up using the questions less often over time. The questions teach the team how to spot the bad date earlier in its life. The earlier you spot it, the cheaper it is to renegotiate.
What this connects to
This is not the first time I have written about the cost of holding on to a date, or a process, or a commitment that has stopped serving the work.
The closest neighbor on this blog is The Crash. That piece is about my parents losing millions in rental property, and the two lessons that came out of it. One of them is "you cannot do it all yourself." The other is "know when to let go." Knowing when to let go of a date is the same muscle as knowing when to let go of a role, a hire, or a strategy that is not working. It is uncomfortable in the moment and obvious in hindsight.
The other neighbor is The Founder Nobody Sees. The behind-the-scenes founder is often the one with the clearest read on what is actually happening with the work. Which makes them the one most likely to know that a date needs to move. Which also makes them the one most likely to swallow that knowledge instead of surfacing it, because the surface-it-cleanly conversation is harder when you are the operator and not the storyteller.
The bravery to move a date is the same bravery as the willingness to delegate, the willingness to let go, and the willingness to be the operator who tells the truth even when the truth costs the team a clean LinkedIn post.
What "moving the date" looks like inside the firm
For service businesses specifically, here is what a clean move looks like in practice.
You name the move in writing, not in a meeting. The written version forces precision. The meeting version invites hedging.
You name the new date. Not "early April." Not "the next two weeks." A specific date, with a specific deliverable attached.
You name the reason. Specific, factual, not adjectival. "We disconnected the WAF one step early in the sequence and need to re-sequence the remaining closure tasks." Not "we ran into challenges with the technical complexity of the closure."
You name what the client gets to be part of. Most service-firm date moves are unilateral. The best ones are not. Invite the client into the new commitment. Tell them what you would like them to do, or not do, between now and the new date. Make the new date a shared one.
You make the announcement small. One paragraph, sometimes two, in the regular cadence the client is already used to. A daily update, a weekly sync note, a project channel. Not a separate "crisis email" that escalates the moment further than it deserves.
You hold the new date the way you should have held the first one.
The compounding effect of this on the relationship is real. Clients who have lived through a clean date move with you trust you more, not less. They have seen how you operate under uncertainty. That is the operating data they will use the next time someone asks them whether you are good to work with.
The metric most service firms are not tracking
A small operational metric I would love to see more service firms watch: date-move ratio.
Not "percentage of dates hit on time." That is the vanity metric.
Date-move ratio is, "of the dates that were ever set, how many were moved, and how many of the moves were surfaced more than five business days before the original date?"
A high move ratio with mostly-early surfacing is a healthy team. They are catching drift early and renegotiating cleanly.
A low move ratio with a high missed-date ratio is an unhealthy team. They are pretending dates are commandments and then failing them quietly.
A high move ratio with mostly-late surfacing is a team that has learned that moving dates is allowed, but has not yet learned to do it early. That is fixable. The fix is not "fewer moves." It is "surface them sooner."
Most leadership dashboards do not include this. Most should.
What you can do this week
Look at your current roadmap and pick one date.
Not the easy one. The one that has been sitting in the back of your head with a slightly bad feeling on it. The one that you have been quietly defending in your own head for two or three weeks without quite admitting that you are defending it.
Ask the four questions out loud. With another person if you can. With your delivery lead, your co-founder, your operating partner. Someone who is allowed to push back without it costing them anything.
Then, separately, ask yourself the question most operators do not ask out loud.
"Am I serving this date because it still makes sense, or because it is written down?"
If the answer is the second one, the bravest thing you can do this week is move it. Cleanly, with a reason, with a new commitment, with the client in the room.
The leaders I trust most are not the ones who grind to hit every date. They are the ones who can tell the difference between a moved date and a missed date, and who will pick the right one out loud.
The boring version of that skill is what protects the client, the team, and the relationship long after the project closes.
If your team is not making the date-move conversation easy to have, that is a leadership job, not a delivery job. The team will not be braver than you are. They will read whether moving a date is safe or expensive by watching what you do, not what you say.
Make it safe. Make it specific. Make it early.
The next time someone on your team says, "I think we should move this date," do not flinch. Ask the four questions with them. Decide together. Commit to the new one cleanly.
That is the version of leadership the rest of LinkedIn is not writing about. It is the version that quietly compounds for the next ten years of your firm.
Want help running this conversation in your own delivery org? I write about the boring operational stuff that decides whether your services firm actually serves the client or just performs serving. The newsletter goes out on Substack, the long versions live here. If you want a working version of the date-move script (the four questions plus the email template we send to clients), reply to the Substack and ask. I send it back.