I wrote last week that open government data was everyone's responsibility. You, me, not for profits, private sector, everybody. We, the people. But last week's Code for America Summit raised another government innovation takeaway: Government employees need to start thinking outside of their comfort zones, and, specifically, CIOs must help to bridge what I would call the gap of fear between the duties of "building data and apps," and "fixing culture and citizen engagement." In sum: fear of failure breeds failure, and that's not OK.

To wit, when something is massively scary, it's easy to think, "Oh, that's someone else's job." You know what I mean. That meeting where someone needs to lead the "too big to fail" project, and nobody steps forward. Or, in the case of what Tim O'Reilly and others have dubbed "Gov 2.0," the scary tasks of (a) facing your peers and telling them, "Actually, we're all a part of the problem of bloated and badly run government ... unless we start changing," and (b) facing the public and admitting that nobody knows with a 100% certainty how to deploy new citizen engagement tools without making mistakes. "We're going to fail forward" is not yet in the government lexicon, and it's certainly not in the expectation rulebook for 90% of the citizens that government serves.

If you're not in government, it's an interesting academic problem. Katrina. 9-11's aftermath. Afghanistan. These are all places where government made mistakes, and in some ways got crucified for it, even with the best of intentions.

If you're a government employee, these are not academic matters. These are matters that could affect your livelihood. Anyone who thinks that Apple's problems with the iOS 6 map application created customer furor has never experienced the fury of citizens over poor snow removal (the #1 reason why mayors fail re-election, according to one mayoral consultant that I spoke to at the summit), or the public vilification of government employees over matters like trash pickup, zoning, or city planning. At least the guys responsible for Apple's iOS map snafu, while on lockdown, probably don't individually have their names in the local newspapers. If they worked for local government, the probability is pretty high that they would have been. Is it any wonder that government employees are risk averse?

Government transformation through technology is coming. But it's pretty obvious that government employees who welcome it early within many governments are taking a risk. As Jen Pahlka, founder of Code for America put it in her opening remarks, "the first people through the wall generally get bloodied."

Yet, fear of failure breeds failure. When teams are clenched up with fear, dysfunction is inevitable. Lean Startup author Eric Ries, who has previously told big private organizations how to innovate like a startup, told summit attendees that "lean government" isn't a negative hack and slash type of thing; it should be all about being smarter at figuring out what government should be doing and building via the Lean Startup principles of learning, experimentation, and iteration. But this means that some degree of failure needs to be OK, and you need to build a culture tolerant of failure. As he pithily put it: "Telling someone that failure is not an option is an invitation for them to lie to you." Allow me to add that lies may not be the ideal foundation for the more perfect union as we seek to innovate in government.

Fear comes from many places. Federal CTO Todd Park thanked local government workers at the Code for America summit for all that they do in the face of dwindling resources and rising demands. It was a lovely and gracious moment. But, like a two-day hike that you take with a seven-year-old when you're running out of water, the dwindling resources and rising expectations play hell on your sense of well-being, and unavoidably create fear.

One session at the final day's "unconference" at the summit pointed out that fears about what happens when government transforms itself can be exacerbated by fear-based turf battles, too. Is it IT's role to help with government transformation and citizen engagement? Surely, but there is also a fear from business leaders in government that IT is going to somehow screw it up.

Technologists can be marginalized because business leaders in government make the mistake of thinking that responsibility for wires and infrastructure means, "doesn't understand business transformation" or "can't handle matters that need some level of diplomacy." In some cases, that may be true, especially in very small governments where the CIO is essentially an infrastructure supervisor. But in many other cases, it probably isn't true: Government CIOs who are allowed to stay in place tend to be good at delivering business value. One of my conclusions from the session: to reduce the level of "IT might screw it up," government CIOs need to avoid being marginalized. In addition to the standard credibility game that everyone plays, the language around business technology may also need to change. "Innovation" and "business technology" is a more natural bridge to transformation efforts than is "information technology."

This is important both for IT leaders and the governments they serve. As government re-invents itself--and this is coming, whether or not anybody, including government leaders, are ready--those responsible for business technology already have a natural propensity to navigate new waters. Technology implies "new ways of doing things," which means innovation. IT leaders know how to navigate changes with new ways of doing things. This is, frankly, why efforts like Code for America are leading the charge in proactive government transformation: Innovators with high emotional intelligence know how to navigate organizational change.