The Tiny Team Taking on a Massive Reform of Government IT | Hacker News Reader

The Tiny Team Taking on a Massive Reform of Government IT

medium.com

30 pointssteven16 comments

I have a friend who worked at a similar "elite" program in the government called the Presidential Fellows. These are a bunch of highly qualified MBAs, Programmers, and other such overachievers from the private sector who had overwhelming faith in the governments ability (and responsibility) to get things done.

My friend went to DC with a lot of optimism.

Halfway or more through the program, I met my friend at a wedding. My friend's take on the problems with government IT was that it wasn't resolvable by such a small team, because the problems were cultural, deep-grained, and protected by turf-guardians who had a lot to lose with reform.

Without the President spending significant political capital, nothing will ever get done.

The most egregious instance of wastage that could not be resolved involved an instance where a certain government department was receiving emails for archiving. Was printing out the emails. Was sending those printouts to another department by snail mail. That department was then scanning in the emails and archiving the digital images to computer storage.

The stupidity of this process was manifest to everyone without mental disability, and yet nobody could change the process due to the various contractors and their patrons, and the various government employees employed in the process.

Later, talking to other government IT workers (not Presidential Fellows) I came to the conclusion that Govt. human capital is not of the highest quality, and Govt. is perhaps the worst place to work unless you have a thick skin that helps you to resist demoralization at every turn.

FWIW, I suspect people who join the PIFs, 18f, USDS, and Nava will have potentially very different experiences. Each of those organizations has a different strategy, and I don't think anybody yet knows for sure which ones will work out.

I think USDS is doing a good job of putting "critical mass" on a limited number of high-impact projects, and ensuring there is buy-in from the top-level leadership of each agency they work with. That seems like a good strategy to me.

This is why I've always shied away from working with governments. In a previous life I was with a small, successful startup that wanted to sell to the Federal government. After researching it, we learned that getting on the approved vendor list would be a massive effort (relative to our available resources), so we ultimately decided not to tackle it.

I suspect the reason so many government web sites suck is that those contractors "core competence" is navigating the byzantine purchasing process. Being able to write good code is far down the list of qualifications.

There's some work being done in this area now: https://18f.gsa.gov/2015/06/15/agile-bpa-is-here/

It's so strange that Medium articles don't have dates on them. Is there a way to tell when an article was published? Am I missing something?

The reason that I ask, is that I could've swore this article was posted last month, but it was an actual different FastCompany article (http://www.fastcompany.com/3046756/obama-and-his-geeks).

They must want people to always feel like every Medium article is fresh.

Meanwhile in the page source:

  <meta property="article:published_time" content="2015-07-30T17:21:08.966Z">

FYI, if anybody has questions, there are several YC alums who have joined the government in some capacity (healthcare.gov, USDS, Nava, PIFs) and are on HN.

What do you see is being done to combat the issue of big contractors (Booz Allen, CGI, etc) who don't want the gov't building software with small teams because it would hurt their ability to obtain huge billion dollar contracts?

The existing contractors definitely don't like it, and on healthcare.gov, we learned to expect zero cooperation (indeed, plenty of interference) from the management of those companies. [1]

But ultimately, the people making the contracting decisions are agencies like CMS, HHS, the VA, and DHS. And with USDS, the agencies now have solid third party to provide technical advice--for example, that a consumer login system shouldn't cost $80 million to develop.

That's why you see results like the one quoted in the article, where a $200m initial healthcare.gov system was replaced with a $4m one. And if you read between the lines, you'll notice that the major federal contractor for healthcare.gov decided not to bid this year: http://www.wsj.com/articles/healthcare-gov-contractor-optum-...

Sometimes the good guys win.

[1] On the other hand, the engineers at those companies generally want to do the right thing, if they are empowered to.

Thanks, it's encouraging to hear that the contracting officers are now getting better advice from technical folks who understand the small teams approach.

To be fair, a lot of the contractors don't like to cooperate with even each other (a huge part of the cost overruns are related to this reality, same as with private sector probably, too). Historically, the government has basically done almost nothing to referee bad behavior between companies on a contract, but because so many contracts are basically winner-take-all style, much of the fighting would happen before the contract starts.

I like to think that if everyone of the contractors had their customers' interests as priority #1 that the current situation wouldn't be happening. This is why I have few hopes of much changing down the road without a massive reform. The most skilled, talented contractors tend to have trouble surviving the system despite the funding vehicles available.

Even the SETA system created to "police" contractors a bit in the government's best interest is fairly easily gamed by the reality that people form relationships and that people can easily switch companies.

I've heard from people that work in government that the tools they use are allowed to use are restricted by overly complex procurement rules. The result is that non-technical teams are forced to use ancient software as anything else (even if it's opensource) isn't kosher. How could this be reformed?

I could believe that, but my personal experience is that we were able to introduce pretty modern tools--AWS, Node, Backbone, Hipchat and Google apps for communications. Getting these approved required going through a rather complex security audit and dispelling a decent amount of FUD, but otherwise, there's no real legal barrier to using modern open source software.

I think what was probably key is to find an internal champion within the organization you're working with. If you can find a good partner on the business side, you can often get things through the bureaucracy if you're patient and diligent.

TLDR: This is another USDS submarine.

[0]: http://www.paulgraham.com/submarine.html

I wonder what their PR budget is like?

Probably zero in terms of cash, but high in terms of knowing sympathetic people in high places more-or-less everywhere in Silicon Valley.

Reply on news.ycombinator.com