Uncompromising Deadline Building
Give builders less time, not more, to stop scope from silently expanding
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 75%
Dee Hawk's approach to building Visa's core technology (the BASE authorization system and its redundant data center) was to hand a small team an extremely short, non-negotiable deadline rather than an open-ended timeline. His stated belief, that engineers will simply consume however much time they're given, led him to compress national-scale infrastructure builds into nine months and even six months for a second data center, forcing ruthless prioritization instead of scope creep. The mechanism is essentially Parkinson's Law turned into an operating principle: constrain the time variable first, then let the team figure out the minimum viable system that fits inside it.
Origin
After outside vendors like IBM and systems integrators returned wildly over-budget, over-time bids to build Visa's authorization network, Hawk hired away the most impressive bidder's engineer and gave him nine months to build the entire system in-house.
Core principles
- 01More time given to a technical project will just be consumed, not saved
- 02Constrain the deadline before defining the full scope
- 03Put a single accountable owner in charge, not a committee
- 04Redundancy and resilience can be built into the original architecture, not bolted on later
How to run it
- 1
Set the deadline first
Before scoping every feature, fix a hard, aggressive deadline for the system to go live, communicating that the timeline itself is non-negotiable.
Watch out An arbitrary deadline without organizational buy-in can backfire; Hawk paired his deadlines with direct authority and resources for the builder.
- 2
Recruit a proven builder and hand over full ownership
Identify the individual or small team that has already demonstrated the strongest grasp of the problem (Hawk poached the standout engineer from the losing vendor bid) and give them autonomy to build.
- 3
Strip to the minimum viable capability
Focus the build on the single most critical function first (in Visa's case, replacing manual phone-based transaction authorization) rather than trying to solve every downstream problem at once.
- 4
Design for resilience from day one, not as an afterthought
When a real risk is identified (a single data center vulnerable to earthquake and fire), fold the fix directly into the original architecture as concurrent, load-sharing systems rather than a cold standby.
Pro tip Running both sites live, rather than one active and one idle backup, gets you redundancy and extra capacity for the same infrastructure spend.
- 5
Resist requests to extend the timeline
When engineers or vendors push back that more time is needed, treat that as a signal to cut scope further rather than automatically granting an extension.
Watch out Pushed too far, uncompromising deadlines can sacrifice quality or burn out a small team; Visa's success depended on pairing the deadline with a genuinely capable owner.
In the wild
Dee Hawk hired Aram Tatulian away from TRW and gave him nine months to build the nationwide authorization network, including telecom infrastructure, bank-side computer systems, staff training, and a new centralized data center, entirely from scratch.
→ The system, later known as VisaNet, was live and working within nine months, eliminating slow bank-to-bank phone calls for transaction authorization.
When an engineer flagged that Visa's single wood-framed data center sat near the San Andreas Fault and dry brush, Hawk gave him a new job on the spot: build a redundant site anywhere on the East Coast within six months.
→ The team built the first known concurrently-running (not cold-standby) redundant data center architecture, a design pattern now standard across the industry.
Common mistakes
Believing more time yields proportionally better outcomes
Hawk observed that given more time, technical teams would simply consume it without necessarily producing a better result, so he intentionally kept timelines short.
Outsourcing to vendors without a forcing function
When Visa put the authorization system out to RFP with major vendors like IBM, every bid came back over budget and over time, showing that external vendors without a hard internal deadline defaulted to slower, costlier plans.
Is it for you?
Not ideal for
Complex research-driven projects where the problem itself is not yet well understood enough to compress into a fixed timeline.
From the transcript
“D gives him nine months to build this entire thing from scratch.”
From the episode
Visa