Reed's team began to trickle into Chicago beginning in May 2011. They promised, over-optimistically, that they would release a version of Dashboard just a few months after the team arrived. The first version was not impressive. "Aug. 29, 2011, my birthday, we were supposed to have a prototype out of Dashboard, that was going to be the public launch," Kunesh told me. "It was freaking horrible, you couldn't show it to anyone. But I'd only been there 13 weeks and most of the team had been there half that time."
As the tech team struggled to translate what people wanted into usable software, trust in the tech team--already shaky--kept eroding. By Februrary 2012, Kunesh started to get word that people on both the digital and field teams had agitated to pull the plug on Dashboard and replace the tech team with somebody, anybody, else.
"A lot of the software is kind of late. It's looking ugly and I go out on this field call," Kunesh remembered. "And people are like, 'Man, we should fire your bosses man.... We gotta get the guys from the DNC. They don't know what the hell you're doing.' I'm sitting there going, 'I'm gonna get another margarita.' "
While the responsibility for their early struggles certainly falls to the tech team, there were mitigating factors. For one, no one had ever done what they were attempting to do. Narwhal had to connect to a bunch of different vendors' software, some of which turned out to be surprisingly arcane and difficult. Not only that, but there were differences in the way field offices in some states did things and how campaign HQ thought they did things. Tech wasted time building things that it turned out people didn't need or want.
"In the movie version of the campaign, there's probably a meeting where I'm about to get fired and I throw myself on the table," Slaby told me. But in reality, what actually happened was Obama campaign chief Jim Messina would come by Slaby's desk and tell him, "Dude, this has to work." And Slaby would respond, "I know. It will," and then go back to work.
In fact, some shake-ups were necessary. Reed and Slaby sent some product managers packing and brought in more traditional ones like former Microsoft PM Carol Davidsen. "You very much have to understand the campaign's hiring strategy: 'We'll hire these product managers who have campaign experience, then hire engineers who have technical experience--and these two worlds will magically come together.' That failed," Davidsen said. "Those two groups of people couldn't talk to each other."
Then, in the late spring, all the products that the tech team had been promising started to show up. Dashboard got solid. You didn't have to log in a bunch of times if you wanted to do different things on the website. Other smaller products rolled out. "The stuff we told you about for a year is actually happening," Kunesh recalled telling the field team. "You're going to have one log-in and have all these tools, and it's all just gonna work."
Perhaps most important, Narwhal really got on track, thanks no doubt to Davidsen's efforts as well as Josh Thayer's, the lead engineer who arrived in April. What Narwhal fixed was a problem that's long plagued campaigns. You have all this data coming in from all these places -- the voter file, various field offices, the analytics people, the website, mobile stuff. In 2008, and all previous races, the numbers changed once a day. It wasn't real-time. And the people looking to hit their numbers in various ways out in the field offices--number of volunteers and dollars raised and voters persuaded--were used to seeing that update happen like that.
But from an infrastructure level, how much better would it be if you could sync that data in real time across the entire campaign? That's what Narwhal was supposed to do. Davidsen, in true product-manager form, broke down precisely how it all worked. First, she said, Narwhal wasn't really one thing, but several. Narwhal was just an initially helpful brand for the bundle of software.
In reality, it had three components. "One is vendor integration: BSD, NGP, VAN [the latter two companies merged in 2010]. Just getting all of that data into the system and getting it in real time as soon as it goes in one system to another," she said. "The second part is an API portion. You don't want a million consumers getting data via SQL." The API allowed people to access parts of the data without letting them get at the SQL database on the backend. It provided a safe way for Dashboard, the Call Tool (which helped people make calls), and the Twitter Blaster to pull data. And the last part was the presentation of the data that was in the system. While the dream had been for all applications to run through Narwhal in real time, it turned out that couldn't work. So, they split things into real-time applications like the Call Tool or things on the web. And then they provided a separate way for the Analytics people, who had very specific needs, to get the data in a different form. Then, whatever they came up with was fed back into Narwhal.
Leave A Comment