Every engagement has one thing that can kill it. Find it in week one.
Deployments rarely die of many small problems. They die of one specific blocker that was findable on day three and got discovered in month three. Five of them account for most cases, and each has a question that surfaces it early.
13 MIN
TL;DR: Most failed engagements have a single cause that was discoverable at the start. Five recur: no data access, no adoption owner, an unpassable security posture, a cost that cannot work, and a definition of success nobody agreed. Go looking for them deliberately.
Where you are. You know how to behave in the room. This is what to actually find out while you are in it, and it is the hour that pays for itself most often.
Late discovery is the whole problem
A blocker found in week one is a scoping decision. The same blocker found in month three is a cancelled project, a burned relationship, and an engineer who spent eight weeks building something that could never ship.
The information rarely changes. Nobody hid the fact that the data warehouse is refreshed weekly rather than hourly. It simply never came up, because nobody asked, because everyone assumed somebody else had. The killer is almost never a secret. It is an unasked question.
The technique for extracting those questions on purpose is the premortem, from Gary Klein's work on decision making. A postmortem asks why something failed after it did. A premortem is run before anything starts: assume it is a year later and the project has failed, then have everyone write down why. The reason it works is social rather than analytical. Asking a room what might go wrong invites optimism and gets vague risks, while telling them it has already failed licenses people to say the specific thing they privately suspect. The five below are what a premortem on an FDE engagement produces almost every time, which is why you can go looking for them rather than waiting for the room to volunteer them.
The five, and the question that finds each
No usable data access. Not "does the data exist", which is always yes. Can a process you control read it, at the freshness you need, without a procurement cycle. Ask: what would it take for a service I run to read this every hour, starting Monday? The answer is either a credential or a project, and you need to know which. The definitive telling is in Nabeel Qureshi's account of his eight years at Palantir: customers would buy an eight-to-twelve-week pilot, the team would spend all of it negotiating data access, and the final week scrambling to have something to demo. That was the company that invented this role, operating at its peak. Ask for access the day the contract is signed, not the day you arrive.
No adoption owner. Covered last lesson. If nobody's job changes, nothing changes.
A security posture you cannot pass. Some environments will not permit an outbound call, or any processing outside their tenancy, at any price. That is not an obstacle to negotiate, it is an architecture constraint, and it decides your design. Ask: has anything here ever been approved that sends data outside your network? A long pause is the answer.
Unit economics that cannot work. Worth a moment because it is newly common. If a workflow runs a hundred thousand times a day and the value per run is small, there is a cost ceiling per run, and some designs simply cannot fit beneath it. Do this arithmetic during discovery on the back of an envelope. Discovering it after building is expensive and entirely avoidable.
No agreed definition of success. If three stakeholders describe success differently, you will satisfy at most one. This surfaces late because everyone nods at the vague version. Force the number.
Look for the previous attempt
One shortcut is worth more than the rest combined: find out whether somebody already tried this.
They usually have. There is a stalled project, an abandoned tool, a consultant's report in a shared drive. Whatever killed it is probably still there, and it is often precisely the blocker you are looking for. Your account executive will not know about the previous attempt, not from concealment but because optimism is a professional requirement and the pipeline runs on it.
Ask plainly: has anyone tried to solve this before, and what happened? People answer this honestly and in detail, because it is a story about someone else. Then ask to see the artifact. Half an hour with a dead project's repository or report tells you more about the real constraints than a day of meetings.
Report it as a decision, not a warning
Having found the blocker, you have to say it in a way that produces a decision rather than anxiety.
The shape: here is the thing that decides whether this works, here is what would have to be true, here is who can make it true, and here is what I would do instead if they cannot. Four clauses. The fourth is what separates a useful engineer from a pessimistic one, because a blocker with an alternative is a plan and a blocker without one is a complaint.
Sometimes the alternative is a narrower scope where the blocker does not apply. That is usually the right answer, and it is a much better week-one conversation than a month-three one.
Do this before moving on
Take a project you have seen fail or stall. Identify which of the five killed it, then work out the earliest moment it was findable and what question would have surfaced it. The gap between when it was findable and when it was found is the cost of not asking, and it is nearly always measured in weeks.
Go deeper
- Scoping ambiguous problems is where the narrower alternative comes from when a blocker holds.
- AI cost and unit economics is the arithmetic behind the fourth killer, which is the newest of the five.
- VPC deployment is the usual answer when the security posture forbids anything leaving the network.
- Stakeholder management is how you get a real answer about who has said no before.
- Reading systems is the method for the half hour you spend with the dead project's code.
Key takeaways
- Engagements die of one findable blocker, not many small problems, and the information was usually available in week one.
- Five recur: no usable data access, no adoption owner, an unpassable security posture, unit economics that cannot work, and no agreed success.
- Ask whether anyone tried this before. The previous attempt's cause of death is usually your blocker.
- Report a blocker in four clauses: what it is, what must be true, who can make it true, and what you would do instead.
Check yourself
Answer before you look. Recalling it is what makes it stick; recognising it does not.
1Why is 'does this data exist' the wrong access question, and what is the right one?
2A workflow runs 100,000 times a day and each run saves a small amount of money. Which deal-killer applies and when should you check it?
3You have found a blocker. What is the fourth clause that makes your report useful rather than pessimistic?
Sign in to track which lessons you have finished.