Every enterprise engagement starts the same way: someone asks for a discovery phase. Two weeks to "understand the landscape." A month to "align stakeholders." By the time anyone writes code, half the budget is gone and the original problem has morphed into something nobody recognizes.
Strike exists to prevent that. It's a 72-hour pressure test where we determine whether a Proof Sprint is feasible, price it, and define the exact conditions under which we'll kill it if it's not working. No discovery theater. No alignment workshops. Just decisions.
Why meetings become black holes
The traditional enterprise meeting has a fatal flaw: it rewards talking over deciding. The person who raises the most concerns looks diligent. The person who asks for more research looks thorough. Nobody gets blamed for slowing things down, but everyone gets blamed if something ships and fails.
So meetings expand. They spawn subcommittees. They generate "parking lot" items that never leave the lot. Three weeks later, you've got 47 people on a recurring invite, a SharePoint folder full of decks nobody reads, and exactly zero decisions made.
Strike inverts this dynamic. We don't reward caution. We reward clarity. You have 72 hours to decide if this thing is buildable and worth building. Everything in the room is structured to force that decision.
Protocol one: clock discipline
Every topic in Strike gets a 12-minute segment. That's not a suggestion—it's enforced. When the clock runs out, we record the outcome and move on.
Twelve minutes sounds brutal, and it is. But here's what we've learned: most topics don't need more time. They need less ambiguity. When you tell someone they have an hour to present, they'll fill the hour. When you tell them they have twelve minutes, they'll cut to the point.
The 12-minute constraint forces preparation. Participants can't show up with vague concerns and expect the room to workshop them. They need a specific question, relevant context, and a proposed answer. If they don't have those things, they're not ready—and that's information too.
Every segment ends with three recorded artifacts: the decision made, the owner responsible, and the kill criterion that would reverse the decision. That last one is critical. We don't just decide "yes, build it"—we decide "yes, build it, and here's exactly what would make us stop."
Protocol two: evidence over opinions
Debates in Strike happen in the repo, not the room.
If you think the proposed architecture won't scale, show a load test. If you think the data model is wrong, submit a schema alternative with migration notes. If you think the timeline is unrealistic, point to a similar build and its actual duration.
We've banned a specific class of objection: the concern without evidence. "I'm worried about security" is not an objection. "Here's a threat model showing three unmitigated attack vectors" is an objection. The first one wastes time. The second one advances the conversation.
This isn't about being dismissive. It's about being rigorous. Vague concerns are easy to raise and impossible to resolve. Specific concerns can be addressed, mitigated, or accepted as known risks. Strike only works if everyone in the room commits to specificity.
Buyers participate in this too. When a stakeholder wants to expand scope, they don't argue for it in a meeting—they submit a proposal to the repo with a cost estimate attached. Engineers respond with commits, not conjecture. The conversation becomes auditable.
Protocol three: kill criteria visible
The most important output of Strike isn't the green light. It's the red lines.
Before anyone commits to a Proof Sprint, we define exactly what would make us abort. Not vague "if things go south" language—specific, measurable conditions. Latency above 200ms on the critical path. Security review surfacing any P0 vulnerability. Integration with the legacy system requiring more than 40 hours of reverse engineering.
These kill criteria get signed by everyone who matters: procurement, security, delivery, and the business owner. They're not suggestions. They're contractual.
This changes the entire dynamic. Instead of fighting about whether something is risky, we define what "too risky" looks like upfront. Instead of scope creep happening invisibly, every expansion has to survive against the kill criteria. "Can we add this feature?" becomes "Does this feature violate any kill criteria? If yes, do we renegotiate the criteria or drop the feature?"
Kill criteria also protect us from the sunk cost trap. When you've spent 80% of the budget, it's hard to admit the project isn't working. But when you defined at the start that "test coverage below 70% by day 8 triggers abort," the decision is mechanical. You're not failing—you're executing the plan.
Who sits in the room
Strike requires exactly four roles, no more:
Business owner: The person who will use what we build and has authority to make scope decisions on the spot. Not their delegate. Not someone who needs to "check with leadership." The actual decision-maker.
Technical lead: An engineer who can evaluate feasibility in real time. They're not there to present slides—they're there to say "yes, that's buildable in 10 days" or "no, that requires infrastructure we don't have."
Security representative: Someone who can approve the threat model or flag blocking concerns. They have veto power on architecture decisions, but they have to exercise it with evidence.
Procurement/finance: The person who can authorize the spend. They're there to hear the kill criteria and sign off on the risk envelope.
If any of these people can't attend for the full 72 hours, we don't run Strike. Sending alternates defeats the purpose. The entire point is to compress decision-making authority into one room for one focused push.
What comes out
At the end of 72 hours, you have one of two outcomes:
Go: A priced Proof Sprint with a fixed scope, a defined timeline (always 10 days or less), signed kill criteria, and a backlog your engineering team has already reviewed and accepted. No surprises. No hidden complexity. The thing we're building is the thing we're building.
No-go: A documented decision not to proceed, with specific reasons. This is a success, not a failure. Finding out in 72 hours that something isn't feasible is infinitely better than finding out in 6 months. The documentation becomes institutional knowledge—next time someone proposes something similar, you have evidence.
Both outcomes include a full audit trail. Every decision, every objection, every kill criterion, every owner assignment—all recorded, all timestamped, all tied to specific evidence in the repo. When someone asks "why did we decide this?" six months later, the answer is in the Strike log.
Why this works
Strike works because it treats decision-making as a production process, not a social one.
Most enterprise planning fails because it's designed around consensus. Everyone needs to feel heard. Every concern needs to be addressed. Every stakeholder needs to sign off. The result is a process that optimizes for comfort instead of clarity.
Strike optimizes for clarity. It's uncomfortable. People don't like having 12 minutes to make their case. They don't like having their concerns rejected for lack of evidence. They don't like being held to kill criteria they signed three days ago.
But they like the outcomes. They like knowing in 72 hours whether something is worth building. They like starting Proof Sprints with genuine confidence instead of optimistic assumptions. They like inheriting backlogs that their teams actually want to work on.
The discomfort is a feature. If your planning process is comfortable, it's probably not producing decisions.