A client sent me her resume last spring with a fourteen-month hole in it. Not a gap in the usual sense: she had been employed the whole time, at a company that is still in business, in a role she held for three years. She had simply deleted those months from her own history, because the only thing she did during them was build a product that got cancelled six weeks before launch. "There's no result," she wrote. "What am I supposed to put?"
I have been editing resumes for eleven years, and this is the most expensive unforced error I see. Not typos, not formatting, not the wrong file type. Deletion. People remove their hardest and most senior work from the record because it ended in a way they are ashamed of, and then they wonder why their resume reads thin for someone with their years.
The convention that creates the problem
In 1943, the mathematician Abraham Wald was working with the Statistical Research Group at Columbia University on a question from the military: where should armor go on bombers? The available data was the damage on planes that returned from missions, which clustered in particular places. The intuitive answer was to armor where the holes were. Wald's memoranda argued close to the opposite. If hits arrive more or less uniformly, then the areas showing few holes on returning planes are the areas where a hit stops a plane from returning at all. The sample was not planes. It was survivors. (The popular retelling has picked up embellishments over eighty years, and the American Mathematical Society's "The Legend of Abraham Wald" is a careful account of which parts are documented; the underlying reasoning is genuine, and the original memoranda stayed classified until the Center for Naval Analyses reissued them decades later.)
A resume is built on exactly the sample Wald warned about. Every guide, mine included, tells you to lead with results, to quantify outcomes, to show impact. That advice is correct, and it quietly instructs you to submit only the planes that came back. The work that took the hit is not disqualified by any rule. It just has no obvious slot in the format, so it falls out, and what falls out of a resume tends to fall out of how you talk about yourself.
How much work actually ends badly
Before the editing method, the base rates, because the shame here is almost entirely a calibration problem. People believe a cancelled project is a personal anomaly. It is closer to a coin flip.
Those are only the measured cases. Google alone has shut down 299 products, services, and hardware lines since 2006 according to the Killed by Google archive, and every one of them had a team of people who are now describing that work in interviews. Then add the failure modes that never make a dataset: the reorg that dissolved your team, the acquisition that shelved the roadmap you spent a year on, the pilot that worked and got no budget. If you have a decade of experience, the probability that all of it succeeded is very low, and a recruiter reading your resume knows this about their own career even if they never say it about yours.
The most useful number I know on this subject is not about projects at all. Amy Edmondson, who studies organizational failure at Harvard Business School, has asked executives two questions in sequence: how many of the failures in your organization are genuinely blameworthy, and how many get treated as blameworthy. In her 2011 Harvard Business Review account, the answers are 2% to 5% for the first and 70% to 90% for the second. Somewhere between sixty-five and eighty-eight percentage points of unearned blame is sitting in the average workplace, and job seekers carry it out the door with them and apply it to their own resumes with no one's help.
The attribution split
Here is the method. It takes about fifteen minutes per project and it is mechanical, which is the point: you should not have to make a judgment call about your own worth while editing a document.
Take the project that ended badly and write down every fact you know about it. Then sort each fact into one of two columns. Column one: things that were true regardless of how it ended. Scope. Budget. Headcount. Systems touched. Milestones hit. Decisions you made and when. Artifacts that exist. Column two: things that were only true if it succeeded. Revenue. Adoption. Retention. Renewal. Award.
Column one is your resume. Column two is gone, and here is the part worth sitting with: column two was mostly never yours. Adoption depends on market timing, on a sales motion you did not own, on a competitor's launch, on a funding round that closed or did not. The CB Insights post-mortem research on hundreds of shut-down companies puts "ran out of capital" at the top of the cited causes at around 70%, with product-market fit next at roughly 43%. Notice what is not on that list: "the engineer who built the data pipeline built it badly."
Three questions that settle almost every case
1. If this project had shipped on schedule, what would this bullet say? Write that line, then delete only the clauses that depend on shipping. What remains is honest and is usually 70% of the sentence. 2. Would a peer who did identical work at a company that happened to survive be allowed to write this line? If yes, so are you. Your bullet is not less true because someone else's balance sheet was better. 3. Does this sentence require the reader to believe something false? If not, it is not a lie. It is an edit, and editing is the whole job.
That third question is the boundary, and it is a real one. The split does not license inventing an outcome. "Drove 30% adoption growth" for a product that never had users is not a reframe, it is a fabrication, and it is the kind that collapses in a twenty-second follow-up question from anyone who has done the job. Everything below stays on the honest side of that line.
Five ways work ends badly, and what each one can carry
The failure modes are not interchangeable, and the standard advice ("focus on what you learned") flattens them into mush. Each one leaves a different set of facts intact.
| How it ended | What is still true | What the bullet should carry | What sinks it |
|---|---|---|---|
| Cancelled before launch | The entire build, at real scope, with real constraints | Scale, systems, the stage you reached, what got reused | Naming the cancellation in the bullet itself |
| Shipped, then failed | A launch happened; adoption did not follow | Launch mechanics, what you instrumented, what you changed in response | Quoting adoption numbers with the denominator hidden |
| Company shut down | Every piece of work you did; only the balance sheet failed | Scope, growth up to the point it stopped, wind-down work you ran | Omitting the company, or stretching the end date |
| Reorg dissolved the team | Deliverables completed before the org chart changed | What you finished, and the transition you handed over | Any hint of the politics involved |
| You were removed from it | The portion you completed, and nothing after that | The completed portion, stated briefly and moved past | A narrative of any kind; length signals defensiveness |
Cancelled before launch: before and after
Before: "Worked on a customer portal redesign that was cancelled." After: "Led front-end build for a customer portal serving 40,000 account holders: shipped design system, auth flow, and 11 of 14 planned screens to staging; component library adopted by two other product teams after the program was shelved." Nothing invented. The cancellation is simply not the subject of the sentence, and the salvage clause at the end does more work than any launch metric would have.
Company shut down: before and after
Before: "Operations Manager, [Startup] (company ceased operations)." After: "Operations Manager, [Startup] (Seed-stage logistics startup, 34 employees at peak; wound down 2025). Built the fulfillment operation from 200 to 4,100 monthly shipments across two warehouses; ran the 60-day wind-down, including vendor settlement and placement support for 19 staff." The closure appears once, as a neutral fact in the company descriptor where it belongs, and the wind-down itself is senior work almost nobody thinks to claim.
What the ATS actually knows about your outcomes
This is the most freeing fact in the article and the one I have never seen stated plainly: the parser does not know how it ended.
An Applicant Tracking System scores the overlap between the language in your document and the language in the requisition: titles, skills, tools, seniority markers, dates, duration. There is no outcome field. There is no "was this successful" column to populate. A bullet describing an eighteen-month data platform migration contains the same tokens whether that platform went live or got shelved in month seventeen: the same Airflow, the same Snowflake, the same team size, the same eighteen months. If you want the mechanics, we cover them in detail in how an ATS actually parses and scores a resume.
What does hurt you in a parser is precisely what my client did by instinct. A fourteen-month hole between two date ranges is structured, machine-readable arithmetic. It is one of the few things in your document a system can evaluate without understanding a word of it, and in the Harvard Business School and Accenture "Hidden Workers" research, roughly half of U.S. employers reported filters that exclude candidates with employment gaps beyond six months. You cannot be filtered on a cancelled project. You can absolutely be filtered on a subtraction. If your situation involves a genuine gap rather than a self-inflicted one, how to address an employment gap handles that case directly.
The four numbers that survive any outcome
The objection I hear next is always the same: fine, but this cluster of the site is about quantified achievements, and a cancelled project has no numbers. It has four, and most people use none of them.
- 1Scale, the size of the thing you were trusted with. Budget, headcount, records, endpoints, geographies, SKUs, transaction volume. Scale is assigned before the outcome is known, which is exactly why it is honest to claim: "Owned a $2.4M program budget across a nine-person cross-functional team" is true on the day the program is killed.
- 2Velocity, what you completed and how fast. Milestones cleared, releases cut, environments migrated, integrations delivered. "Migrated 380 of 500 microservices to the new orchestration layer in seven months, ahead of a nine-month internal target" survives the program's death intact.
- 3Decision quality, what you recommended and when, including the recommendation to stop. This is the most senior signal available in a failed project and the most consistently omitted. "Recommended sunset after a 400-user pilot showed 4% weekly retention; decision adopted three months later" tells a hiring manager you can read evidence and say an unpopular thing on time.
- 4Salvage, what outlived the project. Code reused elsewhere, documentation still in service, a vendor contract renegotiated, a hiring process that stuck, a team that shipped somewhere else. Salvage is the strongest of the four because it requires no charitable reading whatsoever: the thing exists, in production, and it exists because of you.
If none of the four produce a number in your case, the fallback is the same one that applies to any unmeasured work, and we have a full method for it in how to quantify achievements without numbers. Concrete specifics beat vague claims even when nothing is countable.
When they ask about it in the interview
They will, and it is a much smaller moment than you are expecting. Three sentences, roughly forty seconds, in this order. One neutral sentence of context. One specific sentence about what you did. One forward-looking sentence about what you took from it and where you applied it. Then stop talking.
A version that works
"We built it for a segment that turned out to be much smaller than the market sizing suggested, and leadership pulled it two months before GA. I owned the data layer and the integrations, and we hit every engineering milestone through staging. The thing I took from it is that I now ask to see the demand evidence before the architecture is locked, which is a habit I brought into the platform work I did at my next role." No blame, no apology, no defense. Notice that the last sentence is the only one that would differ if the project had shipped, and it is the one that makes you sound like someone worth hiring.
The dread is out of proportion to the evidence. Gompers, Kovner, Lerner and Scharfstein studied performance persistence among venture-backed founders and found that entrepreneurs whose previous company failed succeeded in their next venture 20% of the time, against 18% for people who had never started one, and 30% for those who had previously succeeded (Journal of Financial Economics, 2010). Prior success is genuinely valuable. Prior failure, in the most brutally quantified failure market that exists, cost essentially nothing against never having tried. The market's memory for your failure is far shorter than yours.
The three lines that actually hurt you
- ▸The blame clause: "Project cancelled due to leadership changes." It may be entirely accurate. It reads as a person who arrives with a grievance, and it puts the reader in the position of adjudicating a dispute they know nothing about. Cut the clause; keep the work.
- ▸The apology: "Unfortunately the launch did not meet targets, though the team worked hard." Nobody asked. Volunteering a verdict on yourself invites the reader to accept it, and "worked hard" is the phrase people reach for when they have stopped believing they have evidence.
- ▸The deletion, which is the costliest of the three by a wide margin and the only one that is invisible to you while you are doing it. It removes your most senior work, creates a date gap that machines can measure, and leaves you unable to answer "what was the hardest thing you have worked on" with the true answer.
My client put the fourteen months back. It became four bullets: the scale of the build, the milestones through staging, the recommendation she made to stop six weeks out (which was ignored, and correct), and the internal library two other teams still use. She got an offer in the second interview loop she ran. I do not think the bullets got her the job. I think being able to talk about the hardest year of her career without flinching did.
Key takeaway
Write the work, not the outcome. Sort your facts into what was true regardless of how it ended and what was only true if it succeeded, put the first column on the page, and let the second one go. The outcome was mostly never yours to control, no system that screens you has a field for it, and the only version of this that reliably costs you a job is the one where you quietly take the year out.