The steering committee was on a Thursday in October. Fourteen people on the video call. The slide had a Gantt chart with eighteen workstreams compressed into a timeline ending March 31st. The project sponsor—the VP of Product who controlled the budget but had attended exactly two of the previous twelve steering committees—asked one question: “Are we confident in this date?”
The project manager, three weeks into the role, inheriting the timeline from someone who’d left to join a fintech startup, said “Yes.”
Nobody else said anything.
The technical lead, who had told the project manager in a 1:1 two days earlier that the date was “at least two months optimistic if everything goes perfectly, which it won’t,” was on mute. His director had told him, in a separate conversation, that “we need to show commitment to the sponsor.” He read this as: do not contradict the timeline in a forum the VP can see.
The head of QA, who was in that meeting, later told me over coffee: “I looked at the date, I looked at my team’s capacity, I did the math in my head, and I decided it wasn’t my job to say something in that room.”
The silence lasted four seconds. The sponsor moved to the next slide. The timeline was now official.
The Cost of Saying “This Is Wrong”
The timeline didn’t become fiction in that moment. It was already fiction. It had been fiction since August, when the previous project manager built it backward from a board commitment that predated any technical assessment. What happened in the steering committee was ratification. Fourteen people witnessed it. Not one of them said the word that would have stopped it.
I’ve watched this happen three times. Same pattern every time: the cost of saying “this timeline is wrong” in a group setting is always higher than the cost of saying nothing. The person who speaks up inherits the timeline as their problem. They become the obstacle to launch. The one who “isn’t aligned.” The person who stays silent keeps their capital, their relationships, their option to say “I told you so” later—except they never do. By the time the timeline collapses, everyone has retroactively known it was wrong, and the failure is distributed so widely that no individual carries it.
The timeline becomes a performance document. A piece of optimism staged for the sponsor. Its function is not to plan. Its function is to produce a screenshot for a quarterly review. The actual planning happens elsewhere—in side channels, in 1:1s, in Slack threads that are never archived, in the parking lot after the meeting.
Targets vs. Threats
Deadlines come in two flavors: targets and threats. Most project participants are never told which one they’re operating under.
A target is an aspiration date. A point in time the team is aiming for, with the shared understanding that the work might take longer and that the organization has made some provision for that possibility. Targets invite honesty. If you tell me the target is March and you genuinely want to know whether that’s realistic, I’ll tell you what I think.
A threat is a date backed by a consequence the team cannot absorb. “If we don’t ship by March, we lose the enterprise customer that represents forty percent of our pipeline”—that’s a threat. Threats do not invite honesty. They invite compliance. They produce the specific kind of “yes” that means “I heard you and I disagree but I lack the capital to say so.” They produce timelines that are fiction.
Threats are almost never named as threats. They get called targets, because calling something a threat in a steering committee is an admission that the organization has backed itself into a corner, and nobody with budget authority wants to make that admission in a room with fourteen witnesses. So the threat wears the costume of a target, and the timeline is built to match the costume, not the body underneath.
I watched a CTO present a “target date” to a project team when everyone in the room knew the company’s Series C round was contingent on shipping the feature before fiscal year end. That was not a target. That was a gun. But calling it a gun in the meeting would have required the CTO to acknowledge that the funding strategy and the engineering strategy were in direct conflict—and that was a conversation he was not prepared to have with the people who would have to work the weekends.
The Person Who Wrote the Estimate Is Never in the Room
I’ve seen this pattern in every timeline collapse I’ve been brought in to diagnose: the person who wrote the original estimate is systematically excluded from the room where it gets questioned.
This is not usually deliberate. It’s structural. The engineer who did the original sizing—the one who sat with the requirements, talked to the architects, counted the integration points, and produced a range that was then compressed to a single number by someone with a calendar—has moved on. Reassigned. Joined another team. Left the company. The estimate outlives the estimator.
When the timeline gets questioned in the steering committee, the people in the room are: the sponsor, who wants a date; the project manager, who inherited the plan; the functional managers, who own headcount; and maybe a technical lead who has context on the current state but not on the original assumptions. Nobody in the room can answer “what did we assume when we built this?” because nobody in the room was there.
The timeline cannot be interrogated. It can only be accepted or rejected. Nobody can say “we assumed the API would be ready by November, and that assumption was made in August by someone who has since left, and we have never validated it.” The assumption is invisible. The timeline looks like it was grown, not built—as if it emerged from the ground fully formed, rather than being constructed from a set of guesses that were never written down.
Timelines as Narrative Artifacts
A project timeline tells a story. It has a beginning (the start date), a middle (the dependencies, the parallel workstreams, the critical path), and an ending (the launch). It has protagonists (the teams doing the work) and antagonists (the risks, the blockers, the competing priorities). It has a plot structure: this must happen before that, this can happen at the same time as that, and if this does not happen by then, the ending changes.
We don’t usually think of timelines this way. We think of them as engineering artifacts—Gantt charts, PERT diagrams, sprint backlogs. But the narrative structure is doing more work than the technical structure. The timeline tells a story about what is possible, and the story is shaped by the assumptions—often unexamined—that the storyteller brought to it. The order of events implies causality. The placement of milestones implies confidence. The compression of the tail implies that the hard part is at the beginning, when often it is at the end.
Surfacing the narrative structure matters. When you can see the plot—the shape of the story the timeline is telling—you can identify where the fiction lives. You can ask: what is the inciting incident that makes this workstream start on this date? What is the turning point that lets us move from phase one to phase two? What is the climax, and what happens if we miss it?
In fiction writing, the formal structures that make a plot visible—three-act, five-act, the hero’s journey—are tools for surfacing what the story is actually doing, not what the writer thinks it is doing. A plot generator built for novelists makes this explicit: it takes what you know about your story and externalizes its structural skeleton, so you can see where the stakes are embedded in the structure and where they are merely assumed. The same principle applies to project timelines. Externalizing the structural shape of a timeline—using a novel plot generator as a diagnostic lens to map the beats of what comes first, what depends on what, and what the ending looks like—can reveal where the timeline is performing optimism rather than reflecting reality. The point is not to plan the project with a fiction tool. The point is to see the story the timeline is telling, and then ask whether that story is true.
The frameworks that help one writer think clearly make another seize up. Same with project planning frameworks. The Gantt chart that gives one project manager confidence gives another a false sense that the work is understood. The critical path that helps one team see dependencies gives another team permission to stop thinking about the things that are not on the path. A framework is only as good as the questions it prompts. A timeline that does not prompt questions is a story that nobody is editing.
Pre-Agreed Thresholds Instead of Required Bravery
The Google SRE Book, in its chapters on embracing risk and postmortem culture, describes a practice that maps almost exactly onto what project timelines need: the error budget. An error budget is a pre-agreed threshold for how much unreliability a system can tolerate before the team must stop adding features and focus on stability. The threshold is set before the system fails. It does not require anyone to raise an alarm when breached. It simply triggers a response.
The error budget works because it removes the social cost of naming a problem. Nobody has to be the person who says “we are failing.” The threshold says it for them. The team does not have to admit anything. They just have to follow the protocol they agreed to when the threshold was set.
Project timelines need the same mechanism. A pre-agreed trigger condition for re-baselining that does not require anyone to stand in a steering committee and say “this timeline is fiction.” The trigger should be defined when the timeline is created—when everyone still feels optimistic and the cost of agreeing to a re-baseline condition is low. It should specify what measurable condition—missed milestones, scope changes, team capacity shifts, dependency delays—will automatically initiate a re-planning conversation. Not a re-planning decision. A conversation. The difference matters: a decision requires someone to advocate for it, which means someone has to own the narrative of failure. A conversation triggered by a pre-agreed condition requires no such ownership. The protocol owns it.
Google’s approach to reliable product launches at scale is built on this principle: risk and uncertainty are treated as explicit, quantified variables, not as optimism staged for sponsors. The launch criteria are written before the launch, not during it. The decision to proceed or delay is made against the criteria, not against the mood of the room.
What I Do Now
I have a protocol I use when I encounter a timeline I suspect is fiction. I run it in the first two weeks of any project I’m asked to assess.
Write the assumptions before the estimate. Before any number goes on any slide, I ask the team to write down every assumption that underlies the timeline. Not in a document that will be filed and forgotten—on the same page as the timeline. Each assumption is a sentence with a subject, a verb, and a date. “We assume the API will be production-ready by November 15th.” “We assume two frontend engineers will be available full-time starting October 1st.” “We assume the data migration tooling from the vendor will work as demonstrated.” If the assumption cannot be written as a sentence, it is not an assumption. It is a vibe.
Attach a confidence range to each assumption. Not a percentage. A range. “High confidence: this is based on a working demo and a signed contract.” “Medium confidence: this is based on a vendor’s verbal commitment.” “Low confidence: this is based on a hope expressed by someone who has since left the team.” The range tells you where the fiction lives. A timeline built on three high-confidence assumptions and seven low-confidence assumptions is not a timeline. It is a wish list with a Gantt chart.
Identify who made each assumption and whether they are still reachable. If the person who made the assumption is gone, the assumption is unvalidated. Unvalidated assumptions are risks. Risks go on the risk register, not the timeline. I have seen projects where the entire critical path rested on the expertise of one engineer who had given notice. The timeline did not reflect this because the assumption was never written down, and the engineer’s departure was treated as a staffing issue, not a planning issue.
Define the re-baseline trigger before the timeline is approved. I write a paragraph that begins: “This timeline will be re-baselined if any of the following conditions occur.” Then I list them. “If the API is not production-ready by November 15th.” “If scope changes exceed fifteen percent of the original estimate.” “If team capacity drops below eighty percent of planned allocation for more than two sprints.” The conditions are measurable. They do not require interpretation. They do not require someone to be brave. They just require someone to read the calendar and count.
Put the trigger condition on the steering committee agenda as a standing item. Not as a contingency. As a standing item. Every steering committee meeting starts with: “Have any re-baseline triggers been hit since the last meeting?” If yes, the conversation happens. If no, the meeting continues. This normalizes re-baselining. It makes it a routine question, not a confession. The project manager who inherited the timeline from the person who left does not have to be the one who raises it. The agenda raises it.
Name the deadline type in the timeline document. Target or threat. If it is a target, say so. “This date is an aspiration based on current understanding. We will re-assess at each milestone.” If it is a threat, say so—but say it to the people doing the work, not just the people funding it. “This date is tied to a fiscal year commitment. If we miss it, the project’s continuation is at risk.” The team deserves to know which kind of deadline they are operating under. The fiction happens when a threat is presented as a target, and the team plans for one while being governed by the other.
I ran this protocol on a project last year where the timeline had already been presented to the board. The assumptions document revealed that eleven of nineteen assumptions were low-confidence, and four of those were made by people who had left the company. The re-baseline trigger was hit in week six, when the vendor’s data migration tooling failed its first integration test. The conversation happened in the next steering committee because it was on the agenda. The timeline was re-baselined. Nobody had to be the person who said “this was wrong.” The protocol said it for them.
The project shipped four months later than the original timeline. The sponsor—the VP who had asked “are we confident in this date?” in that October steering committee—later said the re-baseline was the most useful thing the project had done, because it gave her something she could take to the board before the board found out on its own.
The timeline that was fiction became a timeline that was a plan. Not because anyone was brave enough to say it was wrong. Because the protocol made bravery unnecessary.