In mid-November 2013, in a rented office in Columbia, Maryland, lined with screens, a group of engineers was holding one of its twice-daily stand-up meetings. From the back of the room, one of them called out that a brief outage had probably been his mistake.
Mikey Dickerson, who ran the meetings, demanded a round of applause.
Dickerson was a site reliability engineer at Google, lent to the team trying to save HealthCare.gov, the website at the center of President Obama’s health law. It had opened on October 1. By the count of the health department’s inspector general, six people managed to choose a plan that first day.
He held his first stand-up on October 24 and kept holding them every day through October and November, weekends included, at 10:00 in the morning and 6:30 in the evening. In the morning the room worked through problems fast; people went off to act, then reported back at the evening meeting. Each meeting ran about 45 minutes, “causing some of us to sit down,” Dickerson admitted to TIME. A phone line stayed open around the clock so people in other locations could join in when something broke.
He posted his rules on a wall outside the control center. Rule 1: “The war room and the meetings are for solving problems. There are plenty of other venues where people devote their creative energies to shifting blame.” Rule 2: “The ones who should be doing the talking are the people who know the most about an issue, not the ones with the highest rank.”
By the count of the White House’s technology chief, the team went from three or four releases in October to 25 in November. The stand-ups weren’t the whole rescue: hardware upgrades and a separate team cutting the error rate mattered too. But Steven Brill, who reconstructed the rescue for TIME, wrote flatly: “What saved it were Mikey Dickerson’s stand-ups.” The case has the rest.
Planning, not reporting
The stand-up is common in agile software teams, and its best-known form is Scrum’s Daily Scrum. The Scrum Guide, maintained by Ken Schwaber and Jeff Sutherland, who developed Scrum, defines it as a 15-minute event, held at the same time and place every working day. Its purpose is “to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.”
The 2017 edition offered three questions as an example of how to run it: What did I do yesterday to help meet the goal? What will I do today? Do I see any impediment? Those three became the stand-up many people know, one person after another reciting their answers.
The guide’s authors kept trying to steer away from that. In 2013 they noted that the importance of the Daily Scrum “as a planning event is reinforced. Too often it is seen as a status event.” In 2020 they removed the three questions altogether. Teams can now run it however they like, as long as it “focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.”
Dickerson’s meetings fit that description. The morning meeting worked through problems; the evening one heard what had been done about them. Rule 2 kept the meeting with the people who knew the facts, and Rule 1 kept it on the next move instead of the last mistake.
Why daily
The rhythm is the point. A blocked task that waits for the weekly meeting may go unseen for a week. A daily meeting gives it a chance to come up the next morning. Seeing it isn’t the same as fixing it, but the fixing can start sooner. When the HealthCare.gov site crashed twice in the rescue’s first week, the meetings went on, and the team kept choosing what to fix next.
The same rhythm can go wrong. A stand-up that runs long, as Dickerson’s did, can still work if the room is solving problems together. If it is a queue of status reports to a manager, the people who aren’t speaking are waiting. The guide leaves detailed problem-solving for afterward: developers “often meet throughout the day for more detailed discussions.”
The bakery
Imagine a small bakery with four staff. Every morning at 6:45, before the doors open, they spend five minutes at the counter. Not “what did you do yesterday,” but: what has to be out by 8, what are we short of, and who needs a hand. One morning the oven thermostat is acting up. Because it comes out at 6:45, someone rearranges the bake order before the first trays go in, instead of finding out at 7:40 with the croissants burned.
A stand-up for agents with no memory
Coding agents built to run for hours hit a problem a stand-up was made for, in an extreme form. Anthropic describes it as a software project “staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.”
Its fix looks a lot like a written stand-up. A first agent sets up the project, including a progress file “that keeps a log of what agents have done.” Every later session starts by reading “the git logs and progress files to get up to speed on what was recently worked on,” then picks the most important unfinished feature, makes incremental progress and leaves structured notes for the next one.
The useful part to borrow is the content more than the ritual: where the work stands against the goal, what comes next, and what is in the way. Written down, it serves a person coming back from a week off as well as an agent starting a new session.
The applause at HealthCare.gov wasn’t for the outage. It was for saying so out loud, in the meeting, in front of everyone who could help fix it.