Once Upon a Time Inside the Federal Government, You Created a Startup

Once upon a time, you had a great idea for how to make things better for America. You thought it was something that people really needed, but you knew it was very different than what was being done right now. You were afraid that if you told your idea to the people around you, they would start explaining why it wouldn't work---and you were right.

So you found one friend that you could count on. You told your idea just to that friend and asked for their moral support, because you knew startups are almost never founded by individuals, but by great teams like Jobs and Wozniak, Hewlett and Packard, Orville and Wilbur. Your friend agreed to be there for you when the going got tough.

Then you read Lean Startup by Eric Ries and Extreme Programming Explained by Kent Beck. You printed out and hung on your wall the Twelve Principles of Agile Software (http://agilemanifesto.org/principles.html) because you believed those principles applied to any change, not just software, within government.

Then you started, and that was the most important thing you ever did.

The first week, you wrote down, on a real sheet of paper in your own hand, what you wanted to learn in order to make your improvement a reality.

Then you figured out a way you could talk to real people, which you thought of as customers even though they wouldn't actually be paying you in money, but in something more valuable---their time and support. You went to them and tested your idea. You wrote down the result, and decided how you would respond next week to what you had learned.

You did that every week, without fail. Sometimes your weekly evolution was clearly rejected by your customers, and you viewed this as a success, because you had learned something valuable. You listened really, really deeply to everyone who seriously thought about your idea and ignored the people who didn't.

As your idea turned into pictures and then prototypes, you became more confident, but as you reached out to more people you encountered more resistance and more naysayers. People started to be threatened by your idea.

Eventually, someone powerful confronted you and told you to stick to your “real work”. You didn't argue with them. Instead, you let the evidence you had gathered for weeks speak for itself. Your customers, or the people who would one day be your customers, were far more convincing than you could be.

A few times you made a “transformational pivot”. Something you learned was so significant that you had to give up your original idea---because the new idea was even better. Agile methods disallow slavishly sticking to the original vision when your process shows that there is a better one.

You reached out early and periodically to security officers and legal counsel because you were set on breaking habits, not rules. You worked creatively with them to get feedback without violating the Paperwork Reduction Act. Remember that week you lugged your laptop and a story board all over DC to show people things you couldn't put on the internet? You invited people to your office where you were on a local network. Working with security and legal, you got creative in building very realistic fake data sets that could let your customers give you good feedback without risking any sensitive data being revealed. How surprised they were to learn that health care data was really about the animals in the Smithsonian's National Zoo!

At every turn, you looked for opportunities to share credit with the people who helped you, but most especially with the people who opposed you. You had a bank account, but it had no money. Praise and opinion are the coin that moves the government. Your bank account was an emotional one, and you went deeply into debt in order to fill up other people's emotional bank accounts. If you spun the truth a little to overemphasize the accomplishments of your colleagues and to point out that that idea that you two had together was mostly his or her idea, well, it was all for the good of the American people, wasn't it?

You knew that a picture is worth a thousand words and a prototype is worth a million. So every week your idea become more and more real, more polished, more supported by evidence. Rather than re-inventing the wheel, you stood on the shoulders of giants. The technical part of your product leaned on open-source tools that were easy to use and leveraged decades, and sometimes centuries, of person-labor brainpower.

Your hard work was paying off as people began to understand your vision, which, admittedly, had gotten a lot better than when you first started---how could you have been so naïve back then? In your mind, it was no longer “your idea” but “our idea”.

You were now used to working and improving every single week. Some weeks the improvement was small, sometimes it was great. But you spoke to your customers every single week without fail. You had learned to resist the institutional perfectionism that is typical of government. You had shown by experience that a small improvement this week was worth any number of promises for next month.

Eventually it was time to reach a broader audience and gain more support, so you planned and executed a big event around your idea. You called it a Hackathon or a Conference or something else that fit your idea. You invited a group of people who weren't in your circle to help you. You were well organized, and had a list of what you wanted out of the Hackathon, and that helped, but you were flabbergasted but how much help you actually got. Your event not only directly improved your product, it also gained you valuable allies.

Every good Hollywood movie has a false victory, and here is how yours played out. You eventually presented your idea to a Very Important Person. Of course, the Very Important Person said you were very smart and they liked it, and, in fact, they thought it would be a success if would you only do one little thing, which, for security reasons, we'll call the McGuffin (http://en.wikipedia.org/wiki/MacGuffin).

You were thrilled! All you had to do was the McGuffin, so you started right away on it. Of course, as you thought about it, you realized the McGuffin was maybe a little bigger than a one-week project. In fact you realized that you had just spent three weeks working on the McGuffin, and you had not gone back to your customers. You had stopped delivering continuous improvement! The McGuffin was, in fact, a trap. It wasn't set by the V.I.P. or by malice, it was set by something far more insidious: the Force of Habit. Your greatest enemy! The entire organization, and everyone in it was, in fact, ruled and controlled by the Force of Habit. Even you.

But you had good habits and good friends, because you had worked for months to develop both around your product. It was true, of course, that the McGuffin would have to be accomplished, because after all, rules are rules, and in the government the rules are sometimes laws. You were out to break habits, not rules, so you went back to the Principles of Agile Development.

You asked the thinkers, testers, programmers, security experts and lawyers with whom you had built personal relationships: “How can we divide the McGuffin up into smaller problems toward which we can make gradual, measurable progress toward every week?” Going back to basics turned the tide in your favor, because an active, satisfied, growing user base asserts its own value and sweeps away all other hurdles eventually. It took longer than you expected, but now it is clear your startup has taken on a life of its own and will survive whether you continue driving it or not.

So now, a year later, here you are. You have created a successful startup within government, despite all the people who said it couldn't be done. The American people are better off in some small way, which of course is why you are in government service in the first place. You're taking a week off, and then next week you are going to go back to basics and review the Agile methods you have sharpened through practice and taught to others by example. Then you are going to start the next project, because you know that nothing is ever really done, and everything can be improved. Even Agile Software Development Methodologies.