Gatekeepers hold a rival's project in review while their own team builds a near-identical version, launches it first, and takes the credit for the idea.
An example
Usage-based billing was the proposal a staff engineer at a business software company took to the platform architecture review in February. The review board, chaired by the platform team's director, returned it with questions about data residency. In April it asked for a load model. In June, for a security design. Each question was reasonable. In August the platform team announced a usage-metering service at the company's internal demo day, built on the same event model the staff engineer's proposal had described in its appendix. The chief technology officer praised the platform team for its initiative. The staff engineer's proposal was closed as duplicative. The staff engineer had the original proposal, its date, and the review board's emails, and sent them to the chief technology officer, who asked the platform director for the metering service's design history.
Why it works
Shipping first makes the gatekeeper's version look like the real thing, so their option looks better, while the rival loses the originator's credit and their stalled project starts to look derivative or late. The delays themselves load the rival with cost: burn without progress, falling morale, and sponsors losing patience. It needs authority over the rival's clearance path, hidden capacity to build in parallel, deniable reasons for each delay, and an audience that rewards shipping over originating. It fails when the rival can escalate independently or the copy is plainly derivative.
The thinking behind it
Robert Greene Robert Greene's The 48 Laws of Power (1998), a popular synthesis of historical anecdotes and not research, states as Law 7: get others to do the work for you, but always take the credit. Stall and Steal is that law run through a review process: the proposer does the thinking and the design, and the reviewer's team ships it. Dated provenance is the defense, because it records who did the work before credit is assigned.
Jonathan Baron Outcome Bias in Decision Evaluation (1988), by Baron and Hershey, found that people judge a decision and its maker more favorably when the outcome is good, even where the outcome carries no information about the decision. A team that ships a working service is judged the more capable one, and the stalled proposer looks slow. Escalating with the record before the copy ships gets the work judged before the outcome decides the question for everyone.
Warning signs
While the reviewed project sits in the queue collecting new questions, the reviewer's own team is building something similar. Each cleared gate produces a new one. The questions come from the person whose team would compete with the project. A near-identical build appears from the reviewer's side, sometimes using details from the proposal itself.
How to defend yourself
Invest early in provenance. Record priority dates for your ideas in places you do not control alone: a dated proposal in a shared repository, an email to your sponsor, a design review with minutes. Ask for reviews with a fixed clock, and for any reviewer whose team works in the same area to step aside. When delays mount, escalate directly to leadership with the dated record; a protest after the copy ships tends to sound like sour grapes, so move before. If you can, build a working prototype in parallel, since a working artifact counts for more than a proposal in a queue.
How a leader shuts it down
Separate gatekeepers from teams that compete with what they review, and require conflict-of-interest declarations on review boards. Put a fixed clock on reviews. Keep dated provenance for proposals, and check it when a reviewing team ships something similar to what it was reviewing.