Iowa’s caucus app failed at rollout before it failed in code

The week

On February 3, 2020, the Iowa Democratic Party held its presidential caucuses and, for the first time, asked precinct chairs to report results through a new smartphone app built by a vendor, Shadow Inc. Caucuses are local meetings where party members gather in person to show support for candidates, and Iowa’s traditionally come first in the presidential nominating season, so the whole country was watching.

The night carried more reporting than any previous caucus. After the disputes of 2016, the party had committed to releasing three sets of numbers for each precinct: the first alignment of supporters, the final alignment after realignment, and the delegate results. Caucusgoers also recorded their choices on paper preference cards, which created a paper trail that earlier caucuses had lacked.

The caucus format made each report more complex than a vote count. Candidates who fell below a viability threshold in a precinct, usually 15 percent of attendees, were dropped after the first alignment, and their supporters could move to another group. Each precinct chair therefore had two rounds of counts and a delegate calculation to report, under the eyes of campaigns that were checking every figure.

The app reached precinct chairs through a route built for testers. Motherboard reported that one chair was invited to test it in mid-January through a platform for sharing pre-release Android apps, and that a new version was pushed out two days before the caucus. Signing in took several steps: an email address and password, a second authentication factor using a one-time code from an authenticator app, and then a precinct PIN.

For a volunteer precinct chair in a small Iowa town, the evening went something like this. After hours in a school gymnasium counting neighbors as they grouped themselves by candidate, the count was done and written down, and the numbers had to be reported. The chair opened the new app, and it would not allow a sign-in. A second try failed too. Then came the backup number, and a long wait.

The app had a coding problem that caused it to report incomplete data. The party said the app recorded data accurately but passed on only part of it. Separately, many precinct chairs had trouble installing the app or logging in at all. County chairs had heard of installation problems on the morning of the caucus, hours before any results were due.

The backup was a telephone hotline, which was quickly overwhelmed as chairs who could not use the app turned to it. One precinct chair told NBC News he had been on hold for 90 minutes. Motherboard reported that another, unable to get through, drove his precinct’s paper results to the county office.

The party delayed releasing results. On Tuesday it said the problem had been identified and fixed, that independent cybersecurity consultants had tested its systems, and that there had been no intrusion. It began releasing partial results that afternoon, and full results took days. Throughout, the party said the underlying paper records were sound: the votes had been counted and written down correctly; the problem was getting the numbers from the gymnasiums to headquarters.

The consequences spread quickly. Public records showed that the Iowa and Nevada Democratic parties had both paid the same developer. The Nevada party said within a day that it would not use the app for its own caucuses later that month.

The caucuses were run by a political party, not a government election office. But the failure was widely discussed as a warning about technology in civic processes, and its causes are familiar to anyone who has launched a new system to staff or to the public. Most of them had less to do with the code than with everything around it.

Post-mortems of the Iowa caucus app focused on the code. The coding error mattered. What made the night a public failure came from three operational decisions that agencies make whenever they launch a citizen-facing or field-facing system. They are getting the software into users’ hands, making sure people can operate it, and sizing the fallback.

Agencies running benefits portals, inspection apps or election support tools face the same three, and all of them belong to whoever owns the launch rather than to the developers. That is good news for non-technical leaders. You do not need to read code to ask whether a launch is ready. You need to ask about people, devices and phone lines.

The analysis starts with a short primer and a walk through a launch day, then takes the three decisions in turn. It closes with who owns them, how vendor contracts should divide them, what failure costs in different sectors, and what readiness looks like.

Last miles, test platforms and fallbacks

What a “launch” really involves

When an organization introduces a new system, the software is only one part. A launch also involves distributing the software to the people who will use it, setting up their accounts and training them. It means providing support when they get stuck and keeping a backup route open for when things go wrong. Technologists sometimes call this “the last mile,” borrowing the phrase from telecommunications, where running cable down each street to each house is often harder and costlier than building the main network.

App stores and testing platforms

Most people install phone apps from the Apple App Store or Google Play. Those stores make installation a single tap, and they handle updates automatically. Developers who are still testing an app often distribute it instead through testing platforms, services that let a limited group install pre-release software. Those platforms are designed for testers who are comfortable with technology. They typically involve extra steps, such as receiving an invitation, installing a separate helper app or changing a phone setting to trust the developer.

Organizations that own their devices have a third route. Mobile device management tools let an agency push an app directly to its own phones and tablets, configure it and update it without the user doing anything. That route works well for staff with agency-issued devices. It does not reach volunteers, contractors or the public, who use their own phones.

Fallback channels

A fallback channel is the backup route people use when the main route fails: a phone line, a paper form, an in-person office. It is like the stairs in an office building. Most days nobody uses them, but if the elevators stop, everyone does, all at once.

Why backup lines collapse

Phone queues behave in a way that surprises people who have not run a contact center. While calls arrive more slowly than agents can answer them, waits stay short. Once calls arrive faster than agents can answer them, the queue grows for as long as the surge lasts. Doubling the calls does not double the wait. It can turn a two-minute wait into an hour.

Two behaviors make it worse. Callers who give up usually call again, so each abandoned call becomes a new one. And the surge arrives at exactly the moment the primary channel fails, because the failure is what sends people to the phone. A fallback sized for average demand will fail when it is needed most, since the demand on it rises and falls with the failure it exists to cover.

How a launch day goes wrong, step by step

The three risks combine on the day itself. Take a hypothetical county launching a new online portal for residents to renew a permit, with a deadline at the end of the month. The software has passed its tests. The project team is confident.

On launch morning, the first problem is access. Residents must create an account, confirm their email and then link their existing permit using a code mailed to them weeks earlier. Many cannot find the letter. Some confirmation emails land in spam folders. A share of residents gives up at each step, and a growing number of them pick up the phone.

The second problem is the county’s own staff. Counter clerks were shown the portal in a short briefing, but most have never completed a renewal in it themselves. When residents call or walk in asking for help, clerks cannot reproduce the screens the residents are describing. They escalate to the project team, which is busy watching the servers.

The third problem is the fallback. The county’s help line normally handles a modest number of calls a day. By midmorning it is receiving several times that, mixing simple questions such as “is the site down?” with people trying to complete their renewals by phone. Wait times climb. People who cannot get through call again, which makes the queue longer. Local news picks up the story by the afternoon.

At no point in this story did the software crash. Each problem came from a decision made, or not made, weeks earlier: how residents would get access, how staff would be prepared and how much the help line could absorb. Those three decisions therefore deserve as much leadership attention as the code itself.

The same sequence in Iowa

The caucus night followed the same order. Installation problems were reported in the morning, before any results existed. Sign-in problems appeared in the evening, when chairs first tried the full sequence of password, second factor and precinct PIN under time pressure. The phone line filled with chairs who could not get in, before the reporting defect had even become visible. When the party then found that the app was passing on only part of its data, the phone line was the only working route, and it was already full.

The late software update matters too. A new version pushed two days before the event means that any practice users had done was on a different build. Late changes are sometimes unavoidable, but each one resets part of the rehearsal. A launch plan should set a date after which only critical fixes go out, and should require a fresh sign-in check after any update that does.

Getting the software into users’ hands

The app was reportedly distributed through mobile testing platforms rather than the public app stores, which meant precinct chairs had to follow unfamiliar installation steps. Some could not complete them; others gave up. Distribution looks like a solved problem until it involves hundreds of volunteers with different phones, different operating system versions and no IT support.

For agencies, the equivalent is any launch that depends on users installing, enrolling or activating something under time pressure: a new identity credential, a device management profile, a field app for inspectors or caseworkers. Each extra step loses a share of users, and the losses compound. A process with four steps that each work for most people can still fail for a large minority.

The arithmetic of drop-off

The arithmetic is worth spelling out, because it surprises people. Suppose a county’s new inspection app requires inspectors to open an email, download a helper app, enter an activation code and then set a password. If each step works for nine in ten people, only about two-thirds will make it through all four. A third of the workforce is stuck before it has used the app once. No single step looks like a problem on its own.

The Iowa sign-in shows how quickly the steps add up. A password, a second factor from a separate app and a precinct PIN are three checks, each reasonable on its own, after an installation that was itself several steps long. Every one of them was a place where a volunteer at the end of a long evening could get stuck.

Rehearsal under real conditions

The control is a rehearsal under realistic conditions, with real devices held by real users, well before launch day. The rehearsal produces a number: the share of intended users who have installed the software and signed in successfully. Program leaders should see that number trend upward week by week, and should know who the stragglers are, so support can reach them before the day rather than during it.

A device matrix helps. The project team lists the phone models and operating system versions its users actually carry, tests installation on each, and records which combinations fail. For a volunteer workforce, that list can be gathered with a short survey weeks ahead. For agency staff, it comes from the device management console. Either way, the team learns about the old phone that cannot run the app before its owner does.

How distribution differs by organization

The right distribution route depends on who the users are. A state agency equipping its own inspectors can push the app through device management and confirm installation centrally. A county relying on poll workers or volunteers must work through personal phones, which argues for a public app store listing or a web application that needs no installation at all. A program serving the public should assume the widest range of devices and the least patience, and should test accordingly.

When no installation is the better choice

Sometimes the best distribution route is none at all. A mobile-friendly web application runs in the phone’s browser, needs no store listing or helper app, and updates for everyone the moment it changes. It gives up some things a native app offers, such as reliable offline use and tight integration with the phone’s security features. For a task performed once a year by volunteers, those losses are usually smaller than the cost of an installation step that a fifth of users fail. For a daily tool used by inspectors in places with poor signal, the balance can tip the other way.

Public app stores add their own timing risk. Store review can take time and can raise questions late. Teams that plan to use a store listing should submit early, and should treat approval as a milestone on the launch plan rather than a formality.

Making sure people can operate it

Many precinct chairs had not used the app before caucus night. Training was limited, and login problems surfaced only when results were due. The workforce had been treated as a given rather than as part of the system.

Field and frontline staff are the part of a public system that is hardest to change at short notice. You can fix a line of code overnight. You cannot retrain hundreds of volunteers in an evening. A sound launch plan therefore treats their readiness as a gate. A defined share of users must have completed a realistic test transaction, using the same accounts and devices they will use on the day, before go-live is approved. That turns training from a calendar event into a criterion a program director can see and act on.

Practice runs, not demonstrations

A realistic test transaction is different from a demonstration. In a demonstration, a trainer shows the screens while users watch. In a test transaction, each user picks up their own phone, signs in with their own account and submits a practice entry from start to finish, the way they will on the day. The difference matters because most launch-day problems live in exactly the steps a demonstration skips: the forgotten password, the phone that needs a software update, the setting that blocks the app. A practice run surfaces those problems one user at a time, weeks ahead, when they are cheap to fix, instead of all at once on the night.

The practice run should include the hardest part of the real task. For a caucus, that meant entering three sets of numbers for a precinct with many candidates. For a benefits portal, it means a case with an unusual household or a missing document. Practice on the easy case builds confidence that does not survive contact with the hard one.

Job aids for the moment of use

Volunteers and occasional users forget what they learned weeks earlier. A one-page job aid, printed and handed out with the other materials for the day, closes much of that gap. It shows the sign-in screens, the steps for a reset, what to do if the app will not open, and which number to call for which problem. It costs almost nothing, and it is the document people actually have in hand when something goes wrong.

Support that does not compete with submissions

Readiness also includes support. Users need a channel for help that is separate from the channel used to submit results, staffed by people who know the app. Combining the two means that every password reset competes with every real submission, which is roughly what happened in Iowa.

Credentials and the security trade-off

Credentials deserve their own rehearsal. Credentials are the usernames, passwords, codes or PINs that prove who a user is. Users who receive login details by email or text weeks in advance lose them, mistype them or find them expired. Agencies issuing credentials for a launch should confirm each user has signed in at least once. They should offer a tested self-service reset, and decide what a user does on the day if the reset fails. Each of those decisions is mundane. Missing any one of them can stall hundreds of users at the same moment, which is a far bigger problem than any single user’s difficulty.

There is a real tension here. A system that carries election results or benefit payments needs strong authentication, and multi-factor sign-in is the right default. The answer is to keep the strength and remove the surprise. Users should complete the full sign-in, second factor included, during the practice run, so that on the day it is familiar. The party said its systems had been tested by independent security consultants. Its chair later acknowledged that he had not tested the app himself. Security testing asks whether an attacker can get in. Readiness testing asks whether the legitimate user can, and both questions need an answer.

Readiness for every user

Readiness also covers users who rely on screen readers, larger text or another language. A practice run that includes them finds problems a standard test misses. For public agencies this is also a legal matter. Federal agencies are bound by Section 508 of the Rehabilitation Act. The Justice Department’s 2024 rule under Title II of the Americans with Disabilities Act set technical accessibility standards for the websites and mobile apps of state and local governments. Counsel can confirm which obligations apply to a given launch.

How readiness differs by workforce

Employees can be scheduled for training, measured on completion and given time to practice. Volunteers and seasonal workers, such as poll workers or precinct chairs, cannot be compelled in the same way and may use the system once a year. Contractors fall between the two. The less control an organization has over its users, the earlier it should start the readiness program and the simpler the task on the day should be.

Sizing the fallback

The fallback was a phone line. When the app failed, almost everyone turned to it at once, and it could not cope. Callers waited for long periods, and some reportedly could not get through. A fallback designed for a minority of users turned into the primary channel, and nobody had planned for that.

Every digital service has a fallback: a call center, a paper form, an in-person office. The test is what happens if the digital channel fails completely at peak and everyone moves to the fallback together. If the fallback collapses too, the agency has one channel, not two.

Cheaper ways to absorb the peak

Sizing a fallback does not always mean paying for idle capacity. Agencies have several cheaper options.

• Stagger demand. Ask different groups of users to act at different times, so not everyone needs the fallback in the same hour.
• Publish clear status updates. Many calls to a backup line are people asking whether there is a problem. A status page or text alert answers that question once, for everyone.
• Capture now, process later. Prepare a simpler manual process that records information safely for later processing, instead of handling everyone in real time.
• Offer callbacks. A queue that takes a number and calls back removes repeat dialing, which is one of the main drivers of overload.
• Arrange overflow in advance. A contact center vendor or a pool of trained staff from other units can be placed on standby for the launch window, with scripts and access ready.

In Iowa, the paper records existed; the pressure came from trying to report everything by phone on the same night. A process that let chairs secure and photograph their paper records, then report over the following hours, would have spread the load.

Keeping the fallback for the people who need it

A fallback that anyone can reach can be overwhelmed by people who have no business on it, by accident or on purpose. Field users can be given a number that is not published, or a line that asks for a precinct or staff PIN before routing the call. The public gets a different number with a recorded status message. Separating the two keeps the people carrying out the process from competing with everyone else who is curious, confused or hostile.

Tiers instead of a single line

Fallbacks also work better in tiers. In a caucus, county chairs could act as collection points for their precincts, so the state line receives a few dozen calls rather than hundreds. At least one Iowa chair created that tier on the night by driving his paper results to the county office. A county permit office can do the same thing with branch counters and a central line. Each tier absorbs part of the load and passes on a summary.

Paying for the fallback

The trade-off is cost. Standby capacity that is never used looks like waste in a budget review, and the better the launch goes, the more wasteful it looks. Leaders should treat fallback capacity like insurance, priced against the cost of a public failure, and should release it in stages once the digital channel has proved itself in live use.

Who owns these decisions

The three decisions belong to the program office, the operations lead and the vendor manager. That matters because launches are often governed as technology projects, with progress measured in features built and tests passed. Those measures tell leaders whether the software works in a laboratory. They say little about whether the people who need it can install it, use it and get help when they cannot.

A launch review should show a number for each of the three operational risks:

1. the share of users installed and signed in;
2. the share who have completed a realistic test;
3. the peak load the fallback can absorb.

If any of the three is unknown, the launch is not ready, whatever the test reports say. A system that will carry public trust should also be tested by someone other than the people who built it, and agencies should budget for that from the start. Independent testers approach a system the way real users do, without knowing its shortcuts, and they have no stake in declaring it finished.

The go or no-go decision

Someone must have the authority to delay a launch, and the criteria should be agreed before anyone is under pressure. A go or no-go meeting a few days before launch, with the three numbers on one page and a named decision-maker, turns a vague sense of readiness into a recorded decision. If the date cannot move, as with an election or a statutory deadline, the same meeting decides which fallback becomes the plan of record.

A short pre-mortem helps. The team assumes the launch has failed and lists the most likely reasons. In most organizations, that list will contain distribution, sign-in and phone capacity long before it contains the code.

Watching the launch window

On the day, the same three risks become live measures. A launch control room, even an informal one, should watch the share of sign-in attempts that succeed and the share of started submissions that are completed. It should also watch the length of the phone queue, the average wait and the share of callers who hang up. Thresholds agreed in advance turn those numbers into decisions. If sign-in success falls below an agreed level, or the queue passes an agreed length, the team switches to the fallback plan without waiting for a meeting.

The strongest objection

The strongest objection to this argument is that the code really was the root cause. Had the app reported complete data, the paper and phone backups would never have carried the full load. That is partly true. But installation and sign-in problems were sending chairs to the phone line before the reporting defect showed itself. Even a flawless app would have left a large share of precincts depending on a line that could not absorb them. The code turned a bad night into a lost night. The operational gaps made it a bad night in the first place.

A second objection is that paper alone would have been safer. Paper has a long record in civic processes, and the preference cards were what let the party stand behind its numbers. The trade-off is speed. Digital reporting promises faster results, and the public and press expect them. The answer is to keep paper as the record and treat the digital channel as a faster way of transmitting it, with a fallback that can carry the load if the faster way fails.

Working with the vendor

Most public-facing systems are built, at least in part, by outside vendors, as the Iowa app was. That creates a particular risk for launches. A vendor’s contract usually defines what the software must do, and its testing proves that the software does it. Distribution, training, help lines and fallbacks often fall into a gap between the vendor’s scope and the organization’s operations team, each assuming the other has them covered.

The fix is to name those responsibilities explicitly. The contract or statement of work should say who distributes the software and through which channel, and who trains users and how readiness is measured. It should say who staffs the help line on launch day and how the vendor’s technical staff support it. And it should list the reports the vendor will provide on sign-ins and usage in the weeks before launch. A vendor that can show those numbers is giving the organization what it needs to decide whether to go ahead. A vendor that can show only test results is answering a narrower question.

Diligence proportionate to the stakes

The size of a contract is a poor guide to the risk it carries. The Iowa app was a modest purchase, by the standards of public technology, for a system that would carry the first results of a presidential nominating season. Due diligence should scale with the consequences of failure rather than the price. That means asking for evidence of similar deployments, load testing results and the vendor’s support plan for the event itself, including who will be on call and with what access.

Government programs often formalize this. Large state systems funded with federal money, such as Medicaid eligibility and claims platforms, generally require independent verification and validation, in which a separate firm reviews the project and reports to the agency. Smaller launches rarely carry that requirement, but the principle scales down. Even a few days of testing by someone outside the vendor and the project team will find problems the builders cannot see.

Shared vendors and shared risk

The same developer had been paid by both the Iowa and Nevada parties, and Nevada dropped the app within a day of the Iowa failure. Any organization using a vendor that also serves its peers shares some of their exposure, for good and ill. A failure elsewhere is early warning. It also means the vendor’s attention may be split at the moment it is most needed, which argues for contract terms that commit named staff to the launch window.

The cost of a failed launch, in any sector

The Iowa caucus app is a vivid case because the failure happened in public, on a single night, with the national press waiting. Most launch failures are slower and less visible, but they follow the same pattern and carry real costs.

For citizens and customers, a failed launch means delays, repeated calls and lost confidence that the organization can deliver. For staff, it means a stressful period of apologizing and improvising, often blamed on them when the root cause was planning. For the organization, it means overtime, emergency vendor fees and leadership attention diverted from everything else. And for public institutions in particular, it means a loss of trust that outlasts the technical fix, because people remember how a service treated them on the day they needed it.

How the costs fall by sector

The same principles apply to a bank moving customers to a new mobile app or a hospital rolling out a new patient portal. They apply to a state introducing a new way to apply for benefits. In each case, the most important questions are not about code.

• A bank or credit union that forces customers onto a new app on a fixed date risks locking people out of their money. Customers who cannot sign in call the contact center or visit branches, and some move their accounts. Supervisors expect institutions to manage changes to critical customer services as an operational risk, with testing and contingency plans.
• A health system launching a new patient portal risks patients missing test results, appointment changes and messages from their care teams. The fallback is the clinic phone line, which is also where urgent clinical calls arrive.
• A state benefits agency risks delayed payments to people who depend on them. Its fallback is a call center and local offices that are often already stretched, and a failure becomes a matter for legislators and the press within days.

In each case, the fallback channel also carries work that has nothing to do with the launch. A surge from a failed launch therefore harms people who never used the new system at all, which is one more reason to size it before the day.

Unremarkable from the inside

A launch that is ready tends to look unremarkable from the inside. Users have installed the software weeks earlier and signed in at least once. Most have completed a realistic practice transaction. There is a help line separate from the submission channel, staffed by people who have used the system. The fallback has been sized for the case where the digital channel fails entirely, with staggering, status updates or deferred capture to spread the load. An independent tester has tried it. And leaders have seen all of those numbers before saying go.

The run-up has a recognizable rhythm. Distribution starts six weeks or more before the event, so stragglers can be found. Practice runs start a month out and repeat after any significant update. A change freeze begins a week or two before launch. The go or no-go meeting happens days before, not hours. Fallback staff rehearse their scripts with the same notices and screens the users will see.

The failures are just as recognizable: measuring readiness by features built rather than by users ready; treating training as a webinar on the calendar rather than a test each user must pass; distributing software through channels designed for developers; sending credentials too early and never checking they work; combining help and submission on one phone line; sizing the fallback for a few stragglers rather than for everyone; and publishing a backup number so widely that anyone can call it.

Readiness checks before a launch goes ahead

These five checks fit on one page and can be answered by the program office without reading any code.

1. What share of the people who need this system have already installed it and signed in successfully, and how has that number moved over the last month?
2. How many users have completed a realistic practice transaction on their own device, with their own account?
3. Is our help line separate from the channel people use to submit information?
4. If the digital system failed completely at peak, how many people would turn to the fallback at once, and how many can it handle?
5. Who outside the team that built this system has tested it?

If any answer is unknown a week before launch, the right response is to find out. The team should also be ready to delay, or to promote the fallback to the plan of record.

With hindsight

The Iowa Democratic Party’s chair resigned the following week. In announcing his resignation on February 12, he acknowledged that he had not tested the app himself. A partial recanvass of results began in the middle of the month, so the caucus results were still being reviewed after the campaign had moved on to New Hampshire.

The debacle fed questions about Iowa’s first-in-the-nation role. In February 2023, the Democratic National Committee approved a 2024 calendar that opened with South Carolina on February 3, followed by New Hampshire and Nevada, then Georgia. Iowa was no longer in the early window. A single night of operational failure thus became part of a debate that played out over years around a long-standing tradition.

The caucus also turned into shorthand for a failure mode that recurred throughout 2020. Within weeks, state unemployment systems faced their own version of the same three problems. They had new users who struggled to enroll, staff who had not been trained on new programs, and call centers overwhelmed when online systems faltered. The circumstances were different: a sudden surge of people who had lost their jobs, rather than a planned launch. The pattern was the same: digital channels that could not absorb demand, and fallbacks that collapsed when everyone turned to them at once.

Those failures drew a federal response. The American Rescue Plan Act of 2021 set aside money for the Department of Labor to help states modernize unemployment systems. In 2022, the Government Accountability Office added the unemployment insurance system to its list of high-risk federal programs. Much of that work was about the same unglamorous layers that failed in Iowa: identity checks, contact center capacity and the steps a claimant must complete before reaching a person.

The pattern returned in a federal launch three years later. The redesigned Free Application for Federal Student Aid opened in late December 2023, months later than usual, and was available only intermittently at first. Processing delays followed, and GAO later reported that most calls to the Department of Education’s call centers went unanswered in the first months of the new form. For the next cycle, the department ran a limited beta test with real applicants starting in October 2024 and opened the form to everyone in late November. That is the rehearsal this article argues for, adopted after the failure rather than before it.

One detail reported at the time deserves more attention than it got: the hotline number was posted online and the line reportedly received calls from people trying to disrupt it. A fallback that is public can be flooded deliberately as well as by accident, which is a reason to give field users a separate, unpublished path. The practical step for any organization is to ask who knows the backup number and whether the people who most need it can reach it when others are calling too.

What did not change was the appeal of speed. Organizations kept moving civic and customer processes onto apps and portals, because digital channels are faster and cheaper when they work. In the cases above, the launches that struggled did not fail because of exotic code. They failed at the layers this article describes: getting people in, preparing them, and sizing the line for the moment the digital channel stopped working.

The paper preference cards turned out to be the most valuable piece of technology in the process. They were what made a recanvass possible at all, because they gave the party something to check the app and phone reports against.

The code was fixed quickly. The operational failures were what people remembered. The parts of a launch that decide whether the public sees success or failure are often the least technical ones, and they are within a leader’s power to check. Asking how many users are ready, and what happens if everyone calls at once, is a check leaders can make before launch, while there is still time to act on the answer.