Which side are you on, vendors?
I am often asked how Code for America intends to deal with the government technology contracting ecosystem that has a lot invested in the status quo. “I love what you’re doing, but at some point, the Beltway Bandits are just going to find a way to take you down, aren’t they?” I usually answer with a story, one in which the names have been omitted to protect the innocent. It’s not the story you’re expecting.
A while ago, we worked with a government to rewrite a very traditional RFP for a large system (and by traditional I mean multi-hundreds of millions of dollars, monolithic, waterfall, driven by extensive requirements with little to no insight into user needs). Instead of one big RFP, this government issued a number of smaller RFPs for a set of services that could be highly focused on user needs, developed through agile processes, and work together. It was an enormous change in process for literally hundreds of public servants, and we expected revolt. Instead, they embraced the change with enthusiasm and courage. It was also a huge shock to the vendor ecosystem, and we braced for retaliation.
Several months later I saw one of the people at the center of this project at a party, and he pulled me aside to talk privately for a moment. He wanted to tell me about a meeting he had had the previous week with a vendor. This vendor had worked with his department for many years and hadn’t qualified for the recent contracts under the new agile procurement terms, and my contact was naturally worried that this was going to be a tense meeting. (If you haven’t worked in the public sector, you may not understand what a vendor can do to a client who has said no. Most government procurement rules provide robust options for protesting awards, which can delay projects, sometimes for years. There are other tactics vendors use as well.)
But this vendor wasn’t there to protest, or threaten, or any of the things this public servant expected. Instead, he said “We didn’t qualify for this award because we’ve trained our people over the years to do what government contracts required. Now they need to be trained in human-centered design and agile development. And that’s the right thing. The old system wasn’t good for anyone. My staff knew we weren’t building what was right for government, for taxpayers, or for the people we were serving. We’re excited to retrain everyone. And we’re going to come back next year and qualify again. Proudly. Thank you for changing the rules.”’
Obviously, this is a slightly fictionalized version of what this person said, because I wasn’t there in the room. But this was, as I understand it, the gist of his comments, and those words are EXACTLY what every government contractor should say in that situation. They are exactly what every American who cares about the state of country and our ability to function effectively through government should say. And I suspect that privately, a lot more vendors than we realize are saying something like that. Many of the biggest names in government contracting are very publicly embracing the user-centered, data-driven, iterative approach that Code for America has long promoted and USDS, 18F, states and others have adopted. They are making a big deal about their human-centered design labs and their new agile practice teams. It’s true that some of this is just marketing. The number of “agile” contracts being awarded that amount to a coat of agile paint on a giant waterfall (I do love broken metaphors!) is upsetting. But a lot of this trend is real and should be celebrated. Privately, I believe a lot of the vendors were sick to death of the old system. For one, they knew they would never be able to attract qualified talent in the old model, and eventually their jobs would amount to defending what they knew to be shameful work in a world where others were doing valuable, meaningful work. Who wants that life?
Well, recently we found out unequivocally who still wants that life: Oracle. The Trump Administration requested feedback on how best to modernize government IT, and allowed any interested party to submit comments on Github. Mike Masnick at TechDirt spotted Oracle’s submission, which is jawdroppingly disingenuous, misleading, and — I hesitate to use this word but really I think it’s merited — unAmerican. I could go into great detail, but really, just read Mike’s post, which nails it. I can’t decide which irks me more, the assertion that the government can never have any digital competence in-house or the characterization of USDS and 18F as blindly applying Silicon Valley practices without any regard to the unique nature of government. Happily, neither of those subtleties matter much. When TechDirt thinks your points vary between “laughable” and “hilarious,” we don’t need to debate my pet peeves.
I am surprised by the bald protectionism and lack of sophistication in Oracle’s stance here, but I shouldn’t be. It’s not just that the company is famous for debacles like the $240M Cover Oregon site that never produced a functional exchange. It’s also that I’ve spent the last seven years talking with cities, counties, states, and federal agencies about their use of technology, and I have yet to meet a happy Oracle customer. I have met Oracle customers who have explained to me with complete conviction that there simply are no alternatives to Oracle. At one point a few years ago, there were so many state and local governments who simply could not afford to upgrade to the newest version of Oracle software that the company was forced to continue supporting an older version they had slated for retirement. That may sound like a nightmare customer base, but let me say a bit more about why so many local governments couldn’t pony up.
A mayor once begged me for advice on negotiating with Oracle, desperate for a way out of a deal that she felt was killing her city. This request was outside my area of expertise, so I called another friend who I know had negotiated with Oracle on behalf of a city government, someone with a long history in technology who really knew his stuff. “I once started a negotiation with Oracle where their opening bid was $17M and mine was $1M,” he told me. “Where did you end up?” I asked. “$1.5M.”
Most cities aren’t ending up at that $1.5M. They’re ending up at the $17M or more, and that’s millions of dollars that aren’t going to critical services for their people. It’s not just that they’re spending millions more than they need to because the contracts are so complex, the services and licenses so opaque, and the business practices so aggressive. It’s what they spend on people, and what they simply don’t get done, because they don’t have the right tools for the job. In one city, the communications staff has been compelled by the IT department to use Oracle Site Builder for the city’s website for years. That city’s website is consequently a thin layer of mobile-unfriendly web pages sitting in front of 34,000 PDF documents. That’s not what any member of the public would recognize as a functional website, and it holds the city back significantly in its ability to provide any of its services to its people online. It affects low-income residents of the city most, since those households increasingly access the web from mobile phones. Good luck getting any answers about city government services when they’re all in PDFs you have to download and try to read on a mobile phone with a limited data plan.
It’s not just complex contracts, opaque terms and aggressive business practices that so cripple governments in their negotiation with Oracle. There’s a reason one of three “false narratives” Oracle outlines in its White House commentary is “In-house government IT development know-how is critical for IT modernization.” Oracle’s success depends not on having a great product their customers love, but on their government clients having little to no technology background, and little ammunition against their aggressive negotiation. If Oracle is coming out strong against in-house technology talent, it’s simply because so many more talented technologists with higher expectations for the technology they build or buy are coming into government, many of them through Code for America’s fellowship program or talent initiative, and ending in up places like city halls, 18F and USDS. They’re having a positive impact there on behalf of taxpayers and everyone who needs to interact with government, and Oracle doesn’t like it.
The government tech world is changing for the better. Clearly, Oracle has made their choice about how to react. As Mike says on TechDirt “This is an old, legacy company trying to cling desperately to old, obsolete, legacy ways.” This is the wrong choice, and while not dismissing the power this company has in the market and their ability to hold on, this choice will cost them their position. In the long run, they will lose.
The other vendors have a choice as well. Most of them have read the writing on the wall, and are choosing correctly. Some of them will be talking out of both sides of their mouths for a few years to come, with some divisions trying to protect their legacy contracts and methodologies while other (mostly newer) divisions offer what’s actually needed today. The reality is that the government market is incredibly diverse and fragmented (think 30,000 municipalities, 50 states, dozens of federal agencies, thousands of other authorities), and will come along to the new ways of doing tech very unevenly. While there is already an established and fast-growing cohort of early adopters, the tail of trailing adopters will be very long. But it is largely a matter of time.
It’s probably enough time, and a long enough tail, that some of the executives of companies who serve government will be happily retired before this change really hurts their legacy business practices. Those who are satisfied to oversee the boiling of their frogs have nothing to fear but a nagging feeling they have been on the wrong side of history as they head out for their 18 holes of golf. Oracle’s gonna Oracle. But there are hundreds more who have the opportunity to be the vendor my friend told me about, to embrace the future because it’s the right thing for their company. And because it’s the right thing for America, and for all Americans who need our government to work for them.
And by the way….
If you work at one of those companies that’s made the right choice, then mark your calendar for the next Code for America Summit, May 30- June 1, 2018. The vendor ecosystem of the future will be gathered there along with hundreds of government customers, the civic-minded technology and design community, and other stakeholders who are making the same choice. Together, we can boil some frogs faster, and make government work for all Americans sooner.
