It's Not About Tech: Hack The Bureaucracy
Bringing geeks into government won’t make a difference if they can’t crack the code on bureaucracies (and the politicos and government workers who run them). A hyper focus on technical problem solving by newcomers to the government space will have limited success and may actually do harm, if not matched with empathetic skills and an understanding of the sometimes perverse incentives facing the millions of U.S. career government employees.
Don’t lose heart! True innovators embrace constraints -- technical, temporal, resource, etc. Working with and within governments brings its own set of constraints. Once you understand them, innovation and technological change becomes easier, if not easy. Identifying and engaging early with the keepers of the status quo works much better than a stealth approach.
Bringing your tech ninja skills to government can be great, if you come with eyes wide open. This session will open your eyes.
Additional Supporting Materials
- How is change institutionalized in government? How can technology go with the organizational grain of government culture and increase the probability of lasting change? Remember, massively disruptive change in government is called a revolution (e.g. 1776).
- How do you align interests between proposed use of technology and the explicit and implicit interests of government employees and politicians? How do you create a compelling narrative for government employees about their work life after a proposed innovation?
- If government workers are so hard to fire, why are they so risk averse? How do government employees evaluate risk? How do (or Do) government employees distinguish uncertainty from risk?
- How does political leadership (transitory) and career government employees (static) differ? What are their respective interests and how can you align with each? How does each measure success? How can your innovations bridge between their two differing world views?
- Who are bureaucratic gate keepers and key masters and how can they determine new comers’ success or failure? Why should you respect bureaucratic walls before planning on blowing through them? Why can’t you conceptually leapfrog 1.0 to get to 2.0 AKA addressing the desire to pave the cow path? How to imbue bureaucracies with the agile development mantra of “just enough, just in time, and not, ‘just because’”?
- Richard Boly US Department of State
Richard Boly US Department of State
Show me another