There's one other interesting component to the campaign's structure. And that's the presence of two big tech vendors interfacing with the various teams--Blue State Digital and NGP Van. The most obvious is the firm that Rospars, Jascha Franklin-Hodge, and Clay Johnson cofounded, Blue State Digital. They're the preeminent progressive digital agency, and a decent chunk--maybe 30 percent--of their business comes from providing technology to campaigns. Of course, BSD's biggest client was the Obama campaign and has been for some time. BSD and Obama for America were and are so deeply enmeshed, it would be difficult to say where one ended and the other began. After all, both Goff and Rospars, the company's principals, were paid staffers of the Obama campaign. And yet between 2008 and 2012, BSD was purchased by WPP, one of the largest ad agencies in the world. What had been an obviously progressive organization was now owned by a huge conglomerate and had clients that weren't other Democratic politicians.
One other thing to know about Rospars, specifically: "He's the Karl Rove of the Internet," someone who knows him very well told me. What Rove was to direct mail--the undisputed king of the medium--Rospars is to e-mail. He and Goff are the brains behind Obama's unprecedented online fundraising efforts. They know what they were doing and had proven that time and again.
The complex relationship between BSD and the Obama campaign adds another dimension to the introduction of an inside team of technologists. If all campaigns started bringing their technology in house, perhaps BSD's tech business would begin to seem less attractive, particularly if many of the tools that such an inside team created were developed as open source products.
So, perhaps the tech team was bound to butt heads with Rospars's digital squad. Slaby would note, too, that the organizational styles of the two operations were very different. "Campaigns aren't traditionally that collaborative," he said. "Departments tend to be freestanding. They are organized kind of like disaster response--siloed and super hierarchical so that things can move very quickly."
Looking at it all from the outside, both the digital and tech teams had really good, mission-oriented reasons for wanting their way to carry the day. The tech team could say, "Hey, we've done this kind of tech before at larger scale and with more stability than you've ever had. Let us do this." And the digital team could say, "Yeah, well, we elected the president and we know how to win, regardless of the technology stack. Just make what we ask for."
The way that the conflict played out was over things like the user experience on the website. Jason Kunesh was the director of UX for the tech team. He had many years of consulting under his belt for big and small companies like Microsoft and LeapFrog. He, too, from an industry perspective knew what he was doing. So, he ran some user interrupt tests on the website to determine how people were experiencing www.barackobama.com. What he found was that the website wasn't even trying to make a go at persuading voters. Rather, everyone got funneled into the fundraising "trap." When he raised that issue with Goff and Rospars, he got a response that I imagine was something like, "Duh. Now STFU," but perhaps in more words. And from the Goff/Rospars perspective, think about it: the system they'd developed could raise $3 million *from a single email.* The sorts of moves they had learned how to make had made a difference of tens, if not hundreds of millions of dollars. Why was this Kunesh guy coming around trying to tell them how to run a campaign?
From Kunesh's perspective, though, there was no reason to think that you had to run this campaign the same as you did the last one. The outsider status that the team both adopted and had applied to them gave them the right to question previous practices.
Tech sometimes had difficulty building what the Field team, a hallowed group within the campaign's world, wanted. Most of that related to the way that they launched Dashboard, the online outreach tool. If you look at Dashboard at the end of the campaign, you see a beautifully polished product that let you volunteer any way you wanted. It's secure and intuitive and had tremendously good uptime as the campaign drew to a close.
But that wasn't how the first version of Dashboard looked.
The tech team's plan was to roll out version 1 with a limited feature set, iterate, roll out version 2, iterate, and so on and so forth until the software was complete and bulletproof. Per Kunesh's telling, the Field people were used to software that looked complete but that was unreliable under the hood. It looked as if you could the things you needed to do, but the software would keep falling down and getting patched, falling down and getting patched, all the way through a campaign. The tech team did not want that. They might be slower, but they were going to build solid products.
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