This is a guest post by Robert Read, a Presidential Innovation Fellow known for his work on RFP-EZ.
- Change the game through prototypes,
- Be a samurai: a loyal hacker,
- Be fast rather than good,
- Stand on the shoulders of giants,
- Scrape, don’t bow, and
- Be prepared to work outside the system.
1: Change the game through prototypes
A picture is worth a thousand words and a working prototype is worth a million. The federal government is used to suits coming in and talking about how great a system they are proposing to build will be two years from now if they are given millions of dollars to build it.
Shatter that paradigm by showing up with a working prototype, and talk about how great it will be if you get their cooperation in polishing it.
2: Be a samurai: a loyal hacker
The federal government has outsourced its technical brain and understaffed its technical know-how. It is not uncommon for one technically savvy person to be in charge of overseeing millions of dollars of labor without a staff. In short, the contractors have the administrators outnumbered about 30 to one. This is a recipe for chaos and confusion, and the result is terrible performance of contracts in many cases.
Say to the administrators: “I am a hacker, and I have no outside interests or loyalties. I am an expert who can’t be bluffed or intimidated or deceived. I will be your bodyguard, your gallowglass, your samurai. You can rely on me for brutally honest technical advice. With me at your side you will be able to negotiate a better contract and stay more in control.”
3: Be fast rather than good
Scientists need to study what happens inside government buildings, because I’m quite sure all processes are five times slower inside the federal government. Paper falls to the ground more slowly. When you switch on a light, it takes a while for it to reach the corners of the room. Getting a computer takes six weeks. Getting an Authority to Operate takes three months.
The government needs people with superpowers who are not affected by this timespace anomaly. Things that normally take a year need to be well underway within a week and ready for evaluation within a month.
Why? Because this is the best way to reduce risk. To make sure a two-year-long project matches the needs for which it was intended one must strive utterly to get as far as possible in the first month. In order to do that, programmers must be prepared to be sloppy and lock their inner perfectionists in the bathroom for a while.
An engineer who can build a prototype in a month can change the consciousness of an entire organization faster than the government can get a contract written to do the work. The methodologies that have been developed in the last 20 years to develop software quickly really work, and they work even better within government where speed is desperately needed. These are named Agile Methodologies, Extreme Programming, Lean Startup, and so on ad nauseum. Every few years the basic concepts are tuned a little and renamed, but the principle remains the same: learning something real right now is more important than fantasizing about something big a year from now. As Kent Beck has taught us, “You go fast by taking babysteps as rapidly as you possibly can.”
Demand the same speed and transparency from contractors that you demand from yourself.
4: Stand on the shoulders of giants
America invented the “Free as in Freedom” software movement. There is a silent army of intellectuals constantly adding to freely available software. Historians a century from now will look upon it as a great gift that the USA gave to the whole world.
The continuing explosion of off-the-shelf software capabilities is so tremendous that a software engineer now must think not so much about writing programs but about joining programs together. No one person can keep up with all of these capabilities. I love programming, but it is my duty not to program but rather to spend most of my time investigating what others have programmed in order to not reinvent the wheel.
5: Scrape, don’t bow
The biosphere of government software systems is a coral reef, each system built on the grotesquely shaped skeleton of its ancestors. These systems have inertia: users, rules, regulations, entry points, touch points, system interactions. Rather than try to change them, accept that whatever you build will have to be bolted on to the existing reef with as little disturbance as possible. By scraping existing websites, or by using extract-transfer-load tools, you can make something wonderful and beautiful even if what lies beneath it is ugly.
6: Be prepared to work outside the system
The government is risk-averse and highly responsive to outside pressure. It fears embarrassment. It loves praise.
If you can find one example of an agency doing something, it is much easier to convince other agencies to follow that example. Just as entrepreneurs must be prepared to go hat-in-hand to many different potential investors, be prepared to look for champions of change outside your own circle.
Finally, when you encounter resistance, ask yourself, “If I were not a government employee, what could I do to solve this problem?” Citizens want to help. Find them and utilize them to expand the bounds of possibility.
Questions? Comments? Hit us up @codeforamerica.
Leave a Reply
You must be logged in to post a comment.