The government should take a field trip to Silicon Valley instead
May 16, 2017
Recently, VB published an article encouraging entrepreneurs to come to DC and do a “Tour of Duty” — to see how the government functions. Granted, most developers would never be interested. The ones who do are probably only interested in catching that new wave of “GovTech” funding, if such wave exists. By the time the article came out, I was already on such a tour, consulting with a large government agency with an obscene annual budget, for a project spanning a decade and costs billions. Frankly, what I saw there terrified me to the point that I would often lose sleep. As an entrepreneur from SF, I never appreciated how effecient our ecosystem functions until now. However, not all hope is lost. Like all things in life, usually the solution to any problem is establishing a mutual understanding of both sides. In this piece, I will attempt to break down my understanding of how government IT works for my peers in SV.
A little history about SV’s presence in DC
Since the healthcare fiasco, and how SV allegedly “saved” healthcare in 3 months, quite a few new initiatives were created under the White House’s banner. Most notably was a group called USDS and its sister organization 18F under GSA. A lot of guys from tech giants like Google were recruited. For USDS, the goal was to send its staff to agencies — to investigate, understand the pain points, and fix them quickly. USDS people usually have considerable power, who can skip most of the bureaucracy and get shit done quickly. 18F was another approach to tech innovation in government, whose model fits more closely with the how government IT traditionally functions. Even though these organizations are still imperfect and slow by SV’s standard, they have truly changed the way government worked in the past few years. To a tech guy, this is extremely encouraging. For the first time, I was excited by the thought of working for our government.
Government IT 101: Role of Money
The fundamental difference between working in government and working in startups is our relationship with money. In the valley, we often hear conversations about the difficulties of raising funds. Raising a certain amount of money (supposedly) happens after proven traction/revenue. Companies would try to minimize spending, automate as much as possible, and be as scrappy as possible in order to survive the current round. In government, the problem is somewhat reversed. To CIOs, spending is not only natural, but also a necessity. “Improved efficiency” is simply a nice phrase to put in presentations. Really it’s about how to spend more than last year, so they can ask for a bigger budget next year. Bigger budget = how important an agency is. What keep them up at night is how to justify that spending.
Government IT 102: Legacy Systems
GAO recently published a report detailing the legacy systems and maintance costs. The numbers are staggering. For 2017, the projected budget spending on IT will be ~$89B. The government spends 3/4 of its money maintaining software, most of which goes to IBM. It also spends less and less money each year on modernization. Some of the biggest projects still use legacy systems built in the 50s. If we go to SOMA in SF today and ask tech bros speed walking to BART what COBOL or z10 are, most will give you a blank stare. To me, it’s absurd that in a budget category for technology, only a tiny portion is allocated for modernization.
So you ask, how the fuck did we get here? How come nothing had been done for the past.. 50 years? Why is it so hard to innovate and modernize?
Government IT 103: Intra-agency Politics
When it comes to changing how things are done in government, anything trivial suddenly becomes a very complicated topic, mainly because so many people’s interests are intertwined and at stake. In a startup environment, people wear multiple hats, have lots of responsibilities, but also enough freedom to operate. Teams are usually small, fast-moving, agile, and self-managed. Now, imagine a place where a typical engineer’s job is split into multiple pieces, and they have the same responsibility of that one engineer. What happens then? Lots of finger pointing, bureaucracy, disagreements, which lead to more and more meetings. There’s an abundance of humans doing the exact same things, and too many layers of managers passing messages to each other with no real purpose. I think it’s important for the government to understand that very often, larger teams actually harm productivity. On top of that, software development process is also very much outdated. You can spot tons of positions that have been obsolete for many years now.
Government IT 104: State vs. Federal Politics
In the United States, we have this weird state vs. federal dynamics. States get funding from the central government every year, government has some influence, and does some check/balance. Suppose Veteran Affairs builds a brand new time-tracking system in Go to replace the legacy system in COBOL. It runs super fast in the cloud, everything should just adopt it and life is great right? Wrong. Turns out, the states don’t want to switch to this new system. Firstly, states may require a training budget along with other bs switching cost for all employees. More importantly, states do not want to lose its budget to maintain the legacy system. Budget cut is NOT ok no matter what. It becomes the federal government’s job to pitch this system, demonstrate how awesome it is, and play all sorts of sales games and political games, in order to get a simple time-tracking system deployed. In most cases, the federal government actually has no say. They cannot enforce anything, because they will be blamed for it if ANYTHING bad happens in the future. Perhaps a distinguished veteran who didn’t get his treatment in time died, will be used to tell a story about this new budget cut destroying American lives. Nobody cares to understand that perhaps a new system can actually cut the average wait time of a VA application from 18 months to 12 months. The Congress will always side with the American people.
Let’s say the CIO of VA is somehow determined enough to make a change. The process may take years. The reason is simple: we have 50+ states in this country, all running similar but also totally different software. Imagine you are running a B2B business, and to get any new product out, you have to pitch 50 different clients with different needs and requirements. Do you try and convince all of them to get onboard with some new protocol? Do you build 50+ new custom software?
Government IT 105: Problems with hiring
Today, hiring is broken in general. In government, of course, the problem is magnified. Government loves to contract its IT work. A huge portion of the government’s spending actually goes to a small set of companies — a handful of contracting companies big enough to even bid. Majority of these contracts are multi-year, in the hundreds of millions to billions, and hence require a “solid” track record. That means there will be some artificial barrier of entry, say 100 million in existing awards with the government, to even bid on this shiny new contract of $2 billion.
It’s quite logical, really. The government can’t possible review thousands of proposals from small businesses, the government’s got better things to do! So what happens is, companies like Lockeed, Booz, Accenture, Northrop become the only options year over year. After some formality to determine eligibility, usually all of these companies get a slice of the pie. These companies are called Prime contractors. They are the gatekeepers. There are also these things called the contract vehicles. Primes’ function is essentially aligning themselves with as many of these vehicles as possible. Long story short, small businesses have close to zero chance of interacting with the government directly. It’s very normal to have many layers of subcontractors if you decide to work for the government as an engineer from the valley.
The problem with this structure is you almost never find talent, or even mediocre people who barely qualify. For a Prime, the goal is simply to fill positions with bodies. For example, it’s very normal to have COBOL people or manual QAs to get reassigned as an engineer to write Java. There’s very little standard when it comes to hiring, little process to evaluate. As a result, we get horror stories like how certain agencies wasted hundreds of millions in a few years, got an unusable system, and the project has to be scrapped and redone.
A better relationship between SV and DC
Ultimately, as a tech nerd, I strongly believe that the Obama administration is very forward looking when it recognized the importance of Silicon Valley in this country’s future. Besides USDS, lots of agencies had set up satellite offices in the Bay Area — most notably, DIUx for Defense, and investments from In-Q-Tel. Though, the disconnect still exists since it’s largely unidirectional. Bringing talent into the government may not be the only solution. Perhaps sending more decision makers to the valley, and have them experience the startup culture first hand, can also be very helpful.