Healthcare.gov Lessons Learned
By Aaron Rudger | October 10, 2014
A year ago on Oct. 12, 2013, Mikey Dickerson got the call that changed his career and his perspective on how to build and troubleshoot massive websites.
The call to Dickerson, an engineering manager at Google, came from the Obama administration asking him if he could help fix the Healthcare.gov website that was supposed to launch Oct. 1 to help Americans sign up for health insurance under the Affordable Care Act. As you know, it did not go well.
He agreed to consult, but on a conference call on Oct. 13, the moderator – who turned out to be Todd Park, the CTO of the United States– said of Dickerson, “He’s going to fix Healthcare.gov and everything’s going to be okay.” No pressure there, right?
Dickerson related his story of how he came to be Healthcare.gov’s savior at the Velocity New York conference last month. His story rings true for us at Keynote as a case study in the fundamentals of Web site testing, deployment, project management and performance analytics to ensure a new site works.
Once in Washington, he held twice-a-day “war room” meetings with as many as 100 people dealing with the crisis, including representatives of 55 different federal contractors working on the site. “Zero of those people was clearly in charge of the other 54 companies,” he discovered.
Even more astonishing was that there was no way to monitor site performance.
“There was no place to look to find out if the site was up or not, except CNN,” Dickerson said.
Dickerson identified a bureaucratic lethargy when he learned that nearly all government websites encounter problems after they launch but given the media attention on Healthcare.gov, this was a big deal.
Eventually the problems were addressed and the site was running by Dec. 1, but the story teaches us about how teams must work together to ensure a site works on Day One. And if the one-year anniversary of the HealthCare.org site debacle isn’t reminder enough, history appears to have repeated in the U.K.!
Lessons to live by
- Site monitoring is essential. Without it, you’re driving a car without the speedometer, tachometer or fuel gauge. It’s fundamental for an organization to deploy a solution, such as Dynatrace Synthetic Monitoring, to see from a dashboard how quickly pages load, whether customers can complete important transactions or how other metrics measure up.
- Prioritize site performance. An attitude that all sites are glitchy at the start ignores the importance not only of site performance to the top line, but to the enterprise’s reputation.
- It takes a team. Making the site work depends on people working together in a way that fosters communication, transcends fiefdoms, and gets everyone on the same page.
While these lessons may seem like no-brainers, putting them into practice is easier said than done. One of the best ways to make it happen is running a web load test. I like to compare the process to joint military exercises between divisions of the U.S. military or between the U.S. and its allies who train together in England, Germany or Japan. These “war games” force people who might not regularly work together into the same room, under a common purpose, continuously monitoring progress in the field. They simulate a realistic scenario and involve the same equipment as used in live combat. In tech, teams performance testing a website in production create their own War Rooms with multiple stakeholders on-call to diagnose and fix problems as they arise. In website delivery, as in combat, it’s important for everyone to get into the foxhole together.
Dickerson’s experience marshaling the troops in Washington to fix Healthcare.gov, gave him a new perspective on his career. This year, he became head of the U.S. Digital Service, a new executive branch agency tasked with maintaining Healthcare.gov full time.