Government For The People, By The People, In the 21st Century


Published on

My joint keynote with Jennifer Pahlka of Code for America at the Accela Engage conference in San Diego on August 5, 2014. We talk about current advances in technology, and how they call for anyone developing services to put their users at the center. In particular, we talk about how these lessons apply to government. Making government work by the people and for the people in a 21st century way is central to restoring faith in government.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I like to start my talks with a quote, to get everyone thinking. And this time, I want to start with William Gibson, the science fiction writer, who once said: “The future is here. It’s just not evenly distributed yet.” Maury talked about this the other day when explaining how Amazon sets consumer expectations for their interactions with government. There is so much happening in the every day experience of citizens with technology that shapes those expectations!
    So I’m going to talk a bit about some key technology trends that are affecting us all -- what we can learn by looking at a couple of industry-transformational applications and services - and then Jen Pahlka, the founder and executive director of Code for America, is going to talk about why it is so important that we apply these lessons to government - the one institution whose job it is to work for all of us.
  • I’m going to start with Uber. This is perhaps a controversial choice, but it shows so many of the key principles that are driving the latest generation of consumer apps - and therefore driving consumer expectations.
    How many of you have used Uber? If you have, you know how transformational it is to be able to know just how long it will take for a car to pick you up - to summon one whenever you need one, with the confidence that it will actually show up when and where you want it.
  • And if it’s delayed at all, you can find out exactly where it is. You can even contact the driver, by phone or text message.
  • And when you arrive at your destination, there’s no fumbling for the right change or waiting for a receipt. You simply say “Thank you, and get out.”
    That’s a transformational experience.
  • There are a couple of key lessons here.
    First, we are at the start of a hardware revolution. The “Internet of Things” is upon us. It’s important not just to think about the “mobile revolution”, as if it were just a matter of putting web content onto smaller screens. There’s a whole new set of capabilities inherent in today’s hardware. GPS and other sensors locate us. Uber is only possible because both the passenger and the driver carry devices that report their location in real time.
  • When you think about Uber, it’s easy to see that it isn’t just a smartphone app. It’s an entire system, with different apps for passenger and driver, and a big data backend that does dispatch and billing. Many of the components of the system, such as anonymized communications between you and the driver by text message or voice, or cashless billing, are made possible by third party providers (in this case Twilio and Braintree) The internet really is becoming an “operating system”, as I first claimed nearly fifteen years ago. Use its capabilities! Mapping, identity, payment are only a few of the many things that we can now take for granted when building online services. But Uber is a great example of how to assemble these into more than the sum of their parts.
    Don’t build everything from scratch. There are so many useful services available by API.
  • One way to think about Uber is that it is using data to “close the loop.” You no longer call a cab, and just hope. Drivers no longer just cruise the streets looking for passengers. Information bridges the gap, and makes the whole system more efficient. Uber closes the loop and takes the uncertainty out of the experience.
  • I picked up this framing from investor Chris Sacca, who who was an early investor in Uber, and before that used to run special projects for Google. He once remarked “What I learned...”
  • Think about what Google did with advertising, figuring out how to predict what ads people would click on. They close the loop in a million small ways, measuring what people link to, what they click on, how long it is before they come back to the search (were they satisfied?) in order to deliver better search results.
    We will want to return to this topic when we start thinking about government services. How many times do citizen requests to government go into a black hole? How could things be better?
  • You can also see all these principles at work in a service like Google Maps, especially on mobile. Not only does it give you routes, it tells you how long it will take to get where you’re going RIGHT NOW, based on real time traffic. And with services like Google Now, you get alerts telling you when to leave for your next appointment based on traffic conditions. In this case, you can see that traffic is really backed up on the bridge. Google shows us an alternate route using public transit, but that’s quite a bit longer.
  • Anohter day, though, when traffic was particularly bad on the approach to the bridge rather than the bridge itself
  • Google automatically re-routed us to another route that is longer in miles but shorter in time. Google Maps is constantly learning from everyone who uses the service. We already knew about this shortcut, but usually don’t know when to take it. Now we do.
    Jen had an even more remarkable experience when driving recently in Texas. She was using navigation, in an unfamiliar environment. She was told to get on a freeway and drive 9 miles. A mile into the route, Google navigation told her to get off at the next exit. She did, and saw from the exit ramp an accident up ahead. Google had re-routed her in real time.
    A huge part of “closing the loop” is learning from your users, paying attention to what they do and responding to it. I’ve often said that one of the key competencies of web applications has got to be “harnessing collective intelligence.” Sensors let Google and Uber do this in real time, but there are lots of other ways you can do this.
  • One way that Uber harnesses the collective intelligence of its users is by building up a system of reputation. Every time you ride on Uber, you are required to rate your driver. And your driver rates you! Uber keeps this confidential, but someone recently posted a javascript hack to get your passenger rating, and I retrieved mine...
  • Drivers who don’t do well are eliminated from the service, and passengers who don’t do well might just find themselves the last in line on a busy day.
    That leads me to an interesting question. This actually can lead to better results than a system that licenses drivers up front. It creates a culture of service.
    On the other hand, there is a risk in data driven regulatory systems of what we could call “digital redlining”.
  • Maybe a practical way to restate this “close the loop” principle would simply be to say “measure and respond.” It’s amazing how often sites and services fail to do this.
  • One recent example that shows Uber doing this was their recent 25% price cut, formally expressed as a 3-month experiment. If prices were lower, would more people ride Uber, abandoning their cars and increasing utilization of the service, thus making more money for Uber and its drivers even as passengers pay less?
  • This is an example of the kind of thinking that is expressed so well in books like The Lean Startup by Eric Ries.
  • One of the key ideas of the Lean Startup is of the “Minimum Viable Product”, which Eric Ries defines as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” And it really is at the core of most modern startups, who view their product as an ongoing series of experiments. These products are really produced through what is called “continuous deployment”, in which a series of minimum viable products are deployed in sequence.
  • That leads me to my next lesson: Do Less.
    I mean this not just in the sense of “minimum viable product” but in the sense of … [next slide] simplification.
  • Sensors are leading to a UI revolution. When the device already knows things, we can build applications that do less, because they know more. The phone knows where you are (you can override with a specific address if necessary, but you don’t usually have to.) The driver’s phone reports where he or she is, so you can see how long it will be before you get picked up. The phone tracks exactly where the driver went and how long it took. And the app already has your payment info. So when you’re building a 21st century service, DON’T ASK THINGS THAT YOU ALREADY KNOW!
    You don’t have to be doing cutting edge mobile apps to apply this principle. So many times app designers simply reproduce existing processes, asking the same questions as they would on the web, or even on paper, when they already know the answers.
  • This leads to a really important mandate: “rethink workflows and experiences.”
  • Aaron Levie of summarized this rule perfectly in a tweet: “Uber is a $3.5 billion lesson in
    building for how the world *should* work instead of optimizing for how the world *does* work.”
    I believe Uber’s current valuation is now $17 billion, not $3.5, but you get the idea.
    Once “things” become smart, you can reinvent the whole business process.
  • It was best expressed to me by an IT executive at Fidelity Investments, after a talk I gave there in 2008.
    I’ve been thinking about it ever since.
  • I started thinking about it again because of what I learned about the rescue effort.
    It was a miserable failure, but also an object lesson in how to transform a government service!
  • Steven Brill wrote a fabulous Time Magazine cover story about the rescue. And I’ve spent time talking to many of the people who appeared on that cover about just what they did.
    A team of engineers…
    My point here is that the problems that led to the failure of weren’t just technical, they were managerial and cultural.
  • A good example is Mikey Dickerson. Mikey spent 18 hour days, for a 100 days straight. And a huge part of his work was standup meetings…
    Mikey was practicing a discipline that is now called “DevOps”, which is ultimately a management methodology for digital services that are developed iteratively, and that need to be operated rather than just delivered once, as in the old days of software products. It encapsulates both technology and culture.
  • As a development methodology, it’s the complete opposite of the specification-driven way in which most government services are developed.
    The problems with were made worse by contractors who charged hundreds of millions of dollars for a site that many of us in Silicon Valley think could have been done for a few million at most. But the problem started here, with a 900+ page “specification” (the Affordable Care Act) plus tens of thousands of pages of additional regulations that had to be followed to the letter. (By contrast, the Interstate Highway Act of 1956 was only 29 pages long.) Imagine that Google, or Facebook,or the iPhone, had started with a huge specification written by a committee of hundreds of lawyers (and lobbyists) and you realize where the real problem lies. Policy people at the top, implementors at the bottom. Completely the inverse of the way it works in Silicon Valley.
    (Lots of people say Obamacare was 2400 pages long. This is incorrect. For details on the page count of Obamacare, see and )
  • If you want to understand more about the cultural revolution in building modern services, this book is a great read - a novelized version of how DevOps was brought to a failed IT project in a big manufacturing company.
    It mirrors the rescue very closely.
  • But there’s an even more important point to be made about what has now come to be called DevOps - the native cultural and business practices of the cloud era. As Jeff Sussna wrote in a recent post....
    Jeff is talking about empathy between developers who are building software and the operations engineers who are going to have to deploy and run the service.
    I’ve been thinking a lot lately about how the same issue of empathy comes into user-centered design, and the kinds of transformative services that customers love. Sites like Google, Amazon, and Uber put their users first. They test relentlessly to understand what parts of the service people actually use, and they constantly change things to make them better, designing with data. It’s easy to think about this as an impersonal process, but part of what we’ve learned is that the best developers have a unique kind of empathy, able to get into their customers shoes.
    In a lot of ways, the secret of success is to figure out how to put the people back into our technology, both inside the development process, and outside, in how we put ourselves into the shoes of our users.
    With that, let me hand the mike over to Jen Pahlka, founder and executive director of Code for America.
  • Jen: Tim started out talking about what many people would call a “disruptive service” and ended up talking about empathy. I’m basically going to do the same thing, tracking a little closer to the world of government technology. I’d like to start with why I think Uber qualifies as disruptive, and it’s not because of its high market valuation. It’s that they may just be getting people to give up their cars. If that happens, it truly changes the shape of our cities in a way that’s really interesting to think about.
  • But what is this trendy word: disruption? Is disruption just what happens when the conditions exist for dramatic, swift change? A convergence of technology, design and economics? And to what extent do those conditions exist in government? And more importantly, should they? As another “disruptive” entrepreneur once said, “disruption is valueless.” As many of you who work in government and hear from those BEING disrupted know very well, disruption generally doesn’t care what it takes down in it’s wake. In contrast, government is not valueless. Successful governments reflect the values of their citizens, but also inherent in the idea of government is that it benefits all of us, not just some of us.
  • We think those values are represented pretty well in the mission statement that serves as our sort of North Star, our guiding light, at Code for America. I’d like to pull this a part a bit for you as a way to talk about applying some of Tim’s lessons and the lessons of the Code for America fellows and volunteers to the services built on the Accela platform.
  • For the people by the people isn’t just a dusty line from the Gettysburg address (and an incomplete one at that). Most of the people I met who work in government went into public service in the first place because of what this line represents: they wanted to serve the public. But there’s another way to say this…
  • For the people also really means FOR PEOPLE
  • And those words, FOR PEOPLE, really hit home to me last year when Jake Solomon, one of the Code for America Fellows, wrote an amazing piece, entitled People, Not Data. He talked about government services sometimes show disdain for their users instead of focusing on “USER NEEDS. An empathetic service would ground itself in the concrete needs of real people. It’s not about innovation, big data, government-as-a-platform, transparency, crowd-funding, open data, or civic tech. It’s about people.” How did Jake come to write this passionate, insightful blog post and dedicate his career to making great government services?
  • Jake was part of a Code for America Fellows team who worked with the Human Services Agency in San Francisco last year. The problem they chose to tackle was churn in the SNAP program. A very high percentage of people who applied for nutrition assistance would subsequently fall out of the program, not because they no longer qualified, but because of these….
  • As Jake and his team found out, because they signed up for the program and got these messages themselves, the communications you get from a program like SNAP are incredibly confusing.
    Shall I read this to you? I won’t read the whole thing, but after reading this, do you think you would have understood that you no longer qualify for the program?
  • The Fellows built a simple Text messaging system telling people to call the office when they were out of compliance.
    We built a similar system in Louisville KY to remind people of court dates.
  • So instead of this….. You get this. And this small intervention reduced churn in the program by 40%.
  • Speaking of food stamps, Tim and I heard an eye opening segment on the radio show Marketplace. Do you know that a huge proportion of food stamp dollars are spent at stores like Walmart between midnight and 1 am on the one night that people’s SNAP cards are electronically refilled? Who goes food shopping at midnight? People who haven’t eaten for a few days, that’s who.
    So it really matters when you show up at the front of the line, and suddenly your SNAP card doesn’t work. And that’s what Jake and his team found happens A LOT when we communicate to real people in legalese. Jake became passionate about fixing this problem because he talked with so many real people who had to leave the grocery store both hungry and humiliated because they didn’t know they’d been dropped from the program before they went to the store. Those people didn’t feed their families that night, or maybe that week.
  • The problems the fellows on that team saw are not highly visible in the media or among the middle class. But a similar problem became highly visible this year when launched on October 1st, and didn’t work.
  • Now Tim spoke just spoke about and how a devops-style culture of empathy on the team could have avoided the troubles for the ACA back in October. But when he first wrote about, it was to connect the dot between that effort and promptly, and between the risk of failure of implementation and the failure of the policy it is supposed to implement.
  • His post quoted Ezra Klein, writing in the Washington Post, to the effect that all the furor over the failure of hides a far deeper problem. Ezra wrote: “One privilege…”
    Which is why projects like Promptly are important, or the jail dashboard that Cfa fellows built in Louisville, KY
  • Or blightstatus from Civic Insight, a great Accela partnership that started at CfA
  • Civic Insight lets you track properties, receive alerts, and speaking to Tim’s earlier point, analyze trends and take action, closing the loop, but all in the service of helping neighbors and cities reduce blight.
    But I want to connect the dots here back to where we started with Uber.
  • Uber, like many “disruptive” apps, is designed relentlessly around user needs. At the end of the day, the service has grown because users LOVE it. They fight for it when it’s threatened, and advocate for it where it isn’t allowed. Building for user needs is the same thing as building for people, which is how Jake and his team built promptly and how he hopes all digital services will be built, whether they are helping deliver nutrition assistance or a fishing license.
  • So though disruption itself may be valueless, they ways in which some of the disruptions in our society are taking place mean that Uber and government actually share a value. I think it’s quite clear that there are many values they DON”T share, so don’t misunderstand what I’m saying here, but for govt to retain the trust and faith of the public we must be open to learning from unlikely sources.
  • Because when services like Uber set the bar (and no longer just for the rich), the inconveniences that government too often foists on it’s “users” become increasingly hard to understand and forgive and hard to bear.
  • But consumer startups don’t have any sort of lock on user-centered services. Governments operate in a far more constrained environment than startups do (for the most part) but they also create services for citizens that work as well as an Uber. There are a LOT of places around government that this is happening, and many of you in the audience are doing this, but I’m going to talk about one place they are doing it exceptionally well, and that’s at the UK’s government digital service, where they put Start with needs right up front, as their first design principle.
  • But since we all start any IT project with needs…. Often under the guise of “requirements”….the GDS folks decided to be clear: Start with USER needs, not government needs. And this one principle, above all the others, is responsible for so much of the success of the group.
  • The success of this effort, by the way, is pretty remarkable. They are spending about a sixth of what they were before to have more visitors, and more importantly, HAPPIER visitors.
  • Their flagship effort is a single domain for all government information that has replaced something like 1700 distinct government web sites, each of which previously had its own look and feel, its own CMS, and its own way of speaking to citizens. You might say that each of these individual sites was meeting a government need to express itself, not a user need, such as a citizen or business needing to find a particular piece of information or complete a particular task.
  • What do I mean when I say government need? Well I spent a lot of time working with government needs during the year I just completed in the White House. One of my jobs in the second half of my year there was to work with federal agencies who were going to be on the hook for implementing the President’s biggest policy priorities.
  • This will make more sense to you if you understand that I worked for the US CTO, Todd Park, who disappeared into the rescue of at the beginning of October, along with the other folks pictured on the cover of Time here. The initial failure of, and its subsequent success in enrolling 8M people by the following April, meant that the administration wanted to make sure that other major priorities weren’t threatened if the digital teams couldn’t implement them successfully.
  • So with their eyes on the prospect of immigration reform, the White House wanted to make sure that the systems at USCIS would scale to meet higher loads. We started with a program for employers that is administered almost entirely through digital channels and is currently a voluntary program, but would become mandatory should immigration reform pass. I believe the policy folks who asked me to work on this were really just hoping to avoid….
  • This. Which of course had surpassed the Twitter Fail Whale as the most famous error message in the US. Policy folks who are not technical still know that if a website gets a lot of traffic, it can crash, and I believe that the initial thought was something along the lines of “go make sure they have enough servers.”
    But it was much more complicated than that of course.
  • Part way through working with this agency we decided to make a list of the stakeholders who would need to weigh in on any changes in the service. There were of course the usual, the program staff, the IT teams (who report up through separate chains of command), the security teams, the relevant policy folks, several leadership councils. On top of that, there were the other federal agencies whose data feeds the service, various offices of general counsel, the office of civil rights. We came up with about 22 stakeholders. But if you think about it, that’s 22 different entities, and even more individuals, who are expressing “government needs” primarily for compliance with rules, before the need of the user is considered. That can result in a confusing user experience.
  • So the current users of this system are mostly large corporations. But remember that at some point, every business in the country may have to use this system if it becomes mandated by law. I’m going to walk you through the process quite critically to make a point, but I first want to say that the team at this agency was really top notch, and making enormous important longterm changes at that agency, so I offer this critique with the deepest respect. Here is the homepage for the program OK. That looks like a good place to start!
  • So that takes us here, so maybe we’ll click on the orange button
  • Oh no, this looks scary!
  • Then when I check, I agree, it gets worse!
    Maybe I’ll try something else!
  • Let me go back a few pages and try this link instead!
  • Nothing happens. I’m just on the same page. Does that link really just lead back to the same page? Yep!
  • OK. How about this one!
  • Yet another place, with more overlapping, confusing options. But it looks like I need to do something about a memorandum of understanding so I’m going to click here
  • Then I’m supposed to choose which kind of user I am…. Not sure… but I’ll click here
  • And now I’m at a legal document, which turns out to be 17 pages long. Now I’m not saying this is unnecessary, but this is definitely meeting a government need, not a user need. And now imagine that every taco truck, dry cleaner and nail salon in the country has to use this system, and has to comply within a certain time frame. You see the problem isn’t really load on the website, its going to be calls to the call center asking for help because the user experience is both confusing and scary, and possibly calls to congressional representatives asking why this has been mandated.
  • That’s why one of the UK GDS design principles is “Do the hard work to make it simple.”
  • So we’ve talked about some examples of interfaces to government that work for the people, but that’s only part of the values we discussed at the beginning.
  • Part of the DNA of our country is the active involvement of citizens, and we’re at a moment in time where the costs of technologies of coordination have fallen so low that by the people is suddenly a lot easier and is blossoming in new, very 21st century ways.
  • A great example, a few years old now, of a project that took the GDS Design Principles of working for users, or For the People, and showed how they could be used BY THE PEOPLE.
    In honolulu in 2012, a CfA fellowship team was asked to find a way to improve the city’s website.
  • With only three fellows, they couldn’t take on the task of rebuilding the content for the entire website. So what they did instead was to build a site that better conformed to the way people look for information. They’re usually looking for quick answers or steps for action they need to take and a site that looks like this is really frustrating to navigate. How often have you come to a government website like this, full of press releases (meeting government needs, not citizen needs).
  • So they built Honolulu Answers, a super-simple and elegant search interface that allows citizens to enter keywords or questions and get quick answers. It was based on the design of Gov.Uk at the time.
  • They applied another one of the GDS design principles, to design with data.
    They mined the visitor logs of the existing site and the city’s call center to find out what people are really looking for,
    instead of what government departments want to say about themselves. And one of the things that they found was that
    driver’s license information was one of the top searches. (In Hawaii, the city manages this for the state.)
  • Take a look at the city’s existing start page of driver’s license information, complete with such “need to know” information as the fact that the driver’s licensing stations have a new statewide computer/camera licensing system! We even have a link to a picture of a driver’s license. But the information about how to get one is hard to find. That’s what citizens really want.
    This is the kind of thing that breaks trust with government.
  • And get back plain language answers that direct a user toward action.
    The site itself was easy enough to build. But the team was faced with the challenge of how to populate all the content. It would have taken the three of them a very long time, especially considering none of them were from Honolulu.
    So they did something that’s actually pretty radical when you think about how government is used to working.
  • So they asked citizens to write the content. You’ve probably all heard of a hackathon. Well, they held a writeathon. Members of the community suggested topics, picked from among the most popular questions, and wrote the answers to them. This led to some questions government doesn’t usually try to answer, like this one about wild pigs.Over the course of a Saturday afternoon they had created almost all of the content for the site. But more importantly than that, they created a new way for citizens to participate in—to build—their government.
  • Open source
    In June 2013, on the National Day of Civic Hacking, in Oakland (where I live) the Oakland Brigade held their own writeathon for Oakland Answers. The Code for America Oakland team took the code base from Honolulu Answers and redeployed it (everything is on GitHub )
  • When Tim and I participated in the Oakland write-a-thon, he wrote this answer to the question about hazardous waste disposal. He knew what needed to be said, because he’d discovered a few months before that there was a limit on how much you could bring in. He found this out when he was turned away because he had too much in his truck. The information about limits was in the footnote on a form that you normally fill out on site, but once you’re on site you’ve already brought more than you should. Now Oaklanders will know this before they load up for the dump.
  • And not to be outdone, I wrote answers to questions about keeping chickens. BTW, the answer is yes. But you can’t keep roosters, as they are very loud. I found that out by accident.
  • Now supporting and fueling that kind of DIY spirit is the goal of another Code for America program: the Brigade.
  • Brigades are local groups made up of technologists and designers, much like the cfA fellowship, but not just techies, folks with a wide range of skills come together to help make their city better using data, apps, and the people of the city themselves. There are 74 active brigades in the US and 124 around the world, and if you work in local government and don’t know the brigade in your city, I encourage you to reach out.
  • One of the organizing principles of the Brigade is that almost by definition, local gov never have all the resources they need, but the community should provide extra capacity to the government, and that’s what the best of these groups is doing, creating extra technology capacity for the city. I love to boast about the brigade in my home town of Oakland, but there’s a fantastic Brigade right here in San Diego led by Jeff Johnson. Read the language on the website: we volunteer to help San Diego govt agencies….. I hope for those of you in government this sound more useful than another group set up to complain about what’s not working.
  • These Brigades run a wide range of projects from starting and maintaining data portals to the Oakland Answers website I mentioned earlier to cataloging social services in their city, but here’s a really interesting one out of Code for Ireland, based in Dublin. They want to map the locations of the AEDs, so they’re encouraging kids and teachers to take selfies in front of the AEDs, tag them and post them on social media. This gets us back to one of the lessons that Tim derived from UBER: do less. The social media services already geotag the posts, so all the team needs to do is pull that data in.
  • This is a great example of productive engagement, which is a term Alicia Rouault is popularlizing, meaning producing data together with citizens, not just asking for input
  • Alicia is one of the CfA fellows from 2012, and one of the founders of Local Data, the company that came out of her fellowship team’s project with the City of Detroit, which makes it easy for cities and communities to capture street-level information in real-time and make it actionable quickly.
  • Local Data is one of the almost two dozen startups that have come through CfA’s programs in the past year, several of whom have relationships with Accela. We offer these programs because we believe there needs to be a growing, dynamic ecosystem of vendors to achieve our mission of government that works for the people in the 21st century.
  • It gets back to two important things that Tim has been saying for some time, both of which are highly relevant when we’re talking about the Accela platform: his notion of govt as a platform
  • And the idea that the best platforms create more value than they capture, spurring dynamic ecosystems of players who enrich the space with a wide range of possibilities. This is what the government ecosystem needs. But let me wrap up by adding to Tim’s list a few more lessons we’ve learned through working in both federal and local government in the last few years.
  • The first lesson is that lowest hanging fruit you have in making government work for people (the people) is not technology, it’s language.
  • That’s what happened with the shift from the legal notices about foodstamps to the simple language used by promptly
  • Jake, the fellow I introduced you to earlier, told me after his fellowship was complete that the most important long-term outcome of his work may not be promptly and the 40% reduction in churn that it created, but the fact that one of the women he worked with in HHS in SF wrote to tell him that she’d been assigned to run a new program and the first thing she did was enroll in the program herself so that she could see what kinds of communication she received. This is an old tech industry adage, not always easy to follow, that is known unkindly as eating your own dog food, but it makes an enormous difference to the kind of work you prioritize.
  • But one of the most important thigns I’d like to share with you about our work, and the work I’ve seen at the federal level and in the GDS in London is that NO ONE, and I mean NO ONE, gets this stuff right the first time.
  • Here is what the team at the GDS launched as their first version of
  • And this is what it looks like today. The Promptly team tried half a dozen interventions before they landed on the text message, and then tested several different messages before finding which one made a difference. When you stand up a service that citizens are supposed to use, it’s templting to think you’re done. In fact, if you want it to work for the people, you’ve just begun.
  • Which leads me to lesson 9. Its also tempting, going back to Tim’s discussion of Uber, that something is going to come along and just change everything, and we should wait for that. Years of trying to get people to use cars less in cities, and boom, Uber is going make that happen, whether it happens the way we like or not. But as I started out, change in government isn’t going to happen like that, because we are grounded in a set of inclusive values. Instead, its going to happen the long, hard, but better way.
  • As Jake says in his post Learning to prioritize people and their needs will be a long slog. It’s the kind of change that happens slowly, one person at a time. But we should start.
  • We should start because we need to repair the public’s trust in government.
    Democracies get their strength from the people’s trust. And if the interactions that people have with government don’t match how they live their lives, or are hard and unpleasant, what is that doing to the trust that underlies our democracies? Obviously, the decline of trust in government has to do
    with a lot of other factors besides technology, but the interfaces are the part that we can fix.
  • Remember that mission statement?
  • Well here’s a simpler version. We means everyone in this room.
  • And as Jake says, we should start now. There’s a great Chinese proverb that says
  • Government For The People, By The People, In the 21st Century

    1. Government For the People, By the People... In the 21st Century Jennifer Pahlka @pahlkadot Tim O’Reilly @timoreilly Accela Engage August 5, 2014
    2. @conference @timoreilly
    3. @conference @timoreilly
    4. @conference @timoreilly
    5. Lesson #1: Get creative with hardware, not just software
    6. Lesson #2: Build software “above the level of a single device”
    7. Lesson #3: Close the loop
    8. “What I learned from Google is to only invest in things that close the loop.” - Chris Sacca
    9. • Google home screen
    10. @conference @timoreilly
    11. @conference @timoreilly
    12. To what extent can reputation systems replace or augment regulation?
    13. Lesson #4: Measure and Respond
    14. The Lean Startup
    15. Minimum Viable Product “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
    16. Lesson #5: Do Less
    17. Simplification
    18. ` Lesson #6: Rethink workflows and experiences
    19. “Uber is a $3.5 billion lesson in building for how the world *should* work instead of optimizing for how the world *does* work” - Aaron Levie of
    20. But there’s one big problem
    21. “We know about all these new technologies. What we don’t know is how to organize ourselves to use them effectively.” - An IT executive at Fidelity, during Q&A after a talk I gave there in 2008
    22. The same site that failed so miserably on October 1 had, by April 15, enrolled more than 8 million people!
    23. Rescuing • A team of engineers. They came in and worked tech wizardry, right? • Maybe a bit of that, but most of the work was debugging the communications failures that led the contractors to build software components that didn’t work together.
    24. • 18 hour days • 100 days straight • Standup meetings focused on why people weren’t able to keep the promises they’d made to each other Mikey Dickerson Google Site Reliability Engineer
    25. DevOps “…it’s not about making developers and sysadmins report to the same VP. It’s not about automating all your configuration procedures. It’s not about tipping up a Jenkins server, or running your applications in the cloud, or releasing your code on Github. It’s not even about letting your developers deploy their code to a PaaS. The true essence of DevOps is empathy.” Jeff Sussna, “Empathy: The Essence of DevOps”
    26. 32
    27. 33 disruption values
    28. 34 Government can work for the people, by the people, in the 21st century, if we make it so.
    29. 35 for the people
    30. 36 for people
    31. #Accela @timoreilly ““User needs. An empathetic service would ground itself in the concrete needs of concrete people. ItUser needs. An empathetic service would ground itself in the concrete needs of concrete people. It’’s nots not about innovation, big data, government-as-a-platform, transparency, crowd-funding, open data, or civicabout innovation, big data, government-as-a-platform, transparency, crowd-funding, open data, or civic tech. Ittech. It’’s about people. Learning to prioritize people and their needs will be a long slog. Its about people. Learning to prioritize people and their needs will be a long slog. It’’s the kind ofs the kind of change that happens slowly, one person at a time. But we should start.change that happens slowly, one person at a time. But we should start.””
    32. #Accela @timoreilly
    33. 36
    34. #Accela @timoreilly
    35. #Accela @timoreilly
    36. 38
    37. 40
    38. 39 “One privilege the insured and well-off have is to excuse the terrible quality of services the government routinely delivers to the poor. Too often, the press ignores — or simply never knows — the pain and trouble of interfacing with government bureaucracies that the poor struggle with daily.” Ezra Klein, Washington Post
    39. 46
    40. 47
    41. @conference @timoreilly
    42. 49 for the people = for people = for users
    43. Government needs?
    44. Todd Park, US CTO
    45. 53
    46. 59 stakeholders
    47. 71 Government can work for the people by the people in the 21st century, if we make it so.
    48. 72 by the people
    49. @timoreilly
    50. @timoreilly
    51. @timoreilly
    52. 86
    53. 87 productive engagement
    54. 88
    55. ` Lesson #7: Rewrite for humans
    56. #Accela @timoreilly
    57. ` Lesson #7: Use the services you manage
    58. ` Lesson #8: It’s never right the first time (and it’s never finished)
    59. ` Lesson #9: There is no silver bullet
    60. #Accela @timoreilly ““User needs. An empathetic service would ground itself in the concreteUser needs. An empathetic service would ground itself in the concrete needs of concrete people. Itneeds of concrete people. It’’s not about innovation, big data,s not about innovation, big data, government-as-a-platform, transparency, crowd-funding, open data, orgovernment-as-a-platform, transparency, crowd-funding, open data, or civic tech. Itcivic tech. It’’s about people. Learning to prioritize people and their needss about people. Learning to prioritize people and their needs will be a long slog. Itwill be a long slog. It’’s the kind of change that happens slowly, ones the kind of change that happens slowly, one person at a time. But we should start.person at a time. But we should start.””
    61. 102 Government can work for the people, by the people, in the 21st century, if we make it so.
    62. 103 Government can work in the 21st century, if we make it so.
    63. ` Lesson #10: Start now
    64. 90 “The best time to have planted a tree was 20 years ago. The second best time is now.” -Chinese Proverb