Not just the government’s playbook

The 13 principles in the U.S. CIO's Digital Services Playbook are applicable for everyone.


Whenever I hear someone say that “government should be run like a business,” my first reaction is “do you know how badly most businesses are run?” Seriously. I do not want my government to run like a business — whether it’s like the local restaurants that pop up and die like wildflowers, or megacorporations that sell broken products, whether financial, automotive, or otherwise.

If you read some elements of the press, it’s easy to think that is the first time that a website failed. And it’s easy to forget that a large non-government website was failing, in surprisingly similar ways, at roughly the same time. I’m talking about the Common App site, the site high school seniors use to apply to most colleges in the US. There were problems with pasting in essays, problems with accepting payments, problems with the app mysteriously hanging for hours, and more.

I don’t mean to pick on Common App; you’ve no doubt had your own experience with woefully bad online services: insurance companies, Internet providers, even online shopping. I’ve seen my doctor swear at the Epic electronic medical records application when it crashed repeatedly during an appointment. So, yes, the government builds bad software. So does private enterprise. All the time. According to TechRepublic, 68% of all software projects fail. We can debate why, and we can even debate the numbers, but there’s clearly a lot of software #fail out there — in industry, in non-profits, and yes, in government.

With that in mind, it’s worth looking at the U.S. CIO’s Digital Services Playbook. It’s not ideal, and in many respects, its flaws reveal its origins. But it’s pretty good, and should certainly serve as a model, not just for the government, but for any organization, small or large, that is building an online presence.

The playbook consists of 13 principles (called “plays”) that drive modern software development:

  • Understand what people need
  • Address the whole experience, from start to finish
  • Make it simple and intuitive
  • Build the service using agile and iterative practices
  • Structure budgets and contracts to support delivery
  • Assign one leader and hold that person accountable
  • Bring in experienced teams
  • Choose a modern technology stack
  • Deploy in a flexible hosting environment
  • Automate testing and deployments
  • Manage security and privacy through reusable processes
  • Use data to drive decisions
  • Default to open

These aren’t abstract principles: most of them should be familiar to anyone who has read about agile software development, attended one of our Velocity conferences, one of the many DevOps Days, or a similar event. All of the principles are worth reading (it’s not a long document). I’m going to call out two for special attention.

First, “Understand what people need”: It’s all too common, both in government and in industry, to run into sites that are defined by what the site’s owner needs. Whether the owner needs you to make a purchase, look at an advertisement, or sign up for insurance, the user’s time on the site is defined by the owner’s agenda. That’s not how people work. People don’t visit sites for the sake of the site: they visit the site to accomplish something. They have their own goals and agenda. That might be relatively simple (buying a book) or relatively complex (planning a trip) — but whatever the case, it’s the user’s agenda and convenience that counts.

The playbook stresses the importance of spending time with current and prospective users of the service. And I’m reminded of a story Gregory Brown, curator of Practicing Ruby, tells about building software for a dental practice. The receptionists hated the software they were currently using. Greg actually sat down with them to observe what they were doing and understand their job. The solution (as I remember the story) wasn’t difficult: one page listed a bunch of insurance codes, and another page required the receptionist to type in the appropriate codes, but it wasn’t possible to click on a code or copy and paste it within the application. You had to remember it or write it down. Easy to fix, but it’s the kind of problem that I see frequently: different parts of the application were written by different people, possibly in different departments. They probably never talked to each other, let alone their users.

Don’t think you’re exempt from the problems that plagued — you aren’t.

Second, “Address the whole experience”: This principle is really an extension of the first. Whether we’re designing software, hardware, network-enabled devices, or something else, we need to realize that we’re designing an experience. And it’s the total experience that matters: not just the good parts. As Kathy Sierra says, how do you make users feel awesome? How do you make them better at what they intend to accomplish?

Together, the first two principles encapsulate the idea of empathy, which is at the core of DevOps. We shouldn’t build applications to make the owner more awesome; we build them to help the user accomplish what he or she needs. That requires understanding the user’s goals; communicating to understand what their pain points are; and thinking about their entire experience, from beginning to end. And realize that the user’s experience isn’t just the experience of the application itself. If you’re building a camera, it’s the experience of taking photos; if you’re building, it’s the experience of visiting the doctor without anxiety about payment; if you’re building a bookstore, it’s about reading books you enjoy.

Read the entire document: it’s short, it’s pithy, and it’s well worth it. And while you’re at it, read the even shorter UK’s Government Digital Service Design Principles, a somewhat older document on which the playbook was based. I hope that our government can implement the principles that are described in the playbook. A lot was learned from the failure of, but learning from failure is one thing, and changing systems that have festered for years is another. But even more, I hope that our private sector reads and implements those same principles. Don’t think that, because you’re in private enterprise, you’re somehow exempt from the problems that plagued the launch of You aren’t.

As part of the release of the Digital Services Playbook, the White House announced that Mikey Dickerson, an engineer from Google who was part of the team that helped fix, will serve as the new Administrator of the U.S. Digital Service and Deputy Federal Chief Information Officer. He is also a keynote speaker at the O’Reilly Velocity conference in September.

Image on home and category pages by Fielding Yost on Wikimedia Commons.

tags: , , ,

Get the O’Reilly Web Platform Newsletter

Stay informed. Receive weekly insight from industry insiders—plus exclusive content and offers.

  • ThatSteveGuy

    It seems like the entire point of this article is provide an excuse for the terrible job the U.S. government did in handling a high profile technology venture.. i.e. it’s not about technology, it’s about partisan politics. Shame on O’Reilly Radar. The “principals” are simplistic and well known, and the excuses given are poor. A business operates within a budget, which the U.S. government rarely seems to do. This means that in business, a $400mil website had better produce $400+ in value or the endeavor will fail and be replaced, if needed. I would rather see THAT model within the departments of the U.S. Government.

    • DavidS

      Sorry, but this is pretty far off the mark. There is even less accountability at Fortune 500 companies than there is in government.

      The reason you don’t hear about $400 million mistakes in the business world — and they happen all the time — is because:
      1) they are covered up
      2) outside vendors are blamed
      3) or they are portrayed as a success by internal PR and the responsible executive(s) are promoted

  • DavidS

    Very good analysis.

    However, most large organizations, private sector and public sector alike, are bureaucracies that are structured completely differently than Google — which is an unusually flat organization even by Silicon Valley standards — and these recommendations would be very controversial in these environments.

    For example, agile development is impossible to do in a culture where software is developed for internal stakeholders (i.e. the big boss who makes all the decisions) , not for the user/customer.

    Yes, some lip service will almost invariably get paid to “doing the right thing” for the user on moral or ethical grounds but as an operating principle, the user is just an abstraction in these cultures — there is a big boss who you must persuade to sign on the dotted line before you can get your paycheck or before the developers will be willing to work.

    Similarly, no one actually uses data to drive decision-making except in organizations that have a strong engineering culture — read as run by engineers — and/or are native internet companies like Tesla, Google, or Facebook.

    In practice, data is almost always used to justify the decision that the big boss has already made. Otherwise this makes the boss look weak. This will almost certainly never change until it is too late — you can’t introduce a new decision-making culture unless you’re the ceo — and these organizations finally go under.

    (p.s. I am a product manager who has worked in many different management cultures in the last 15 years so this opinion probably reflects a lot of my own biases when it comes to software development!)

  • John Scott

    my comments:

    Government get your Sh** Together

    Commenting on the ‘new’ government digital service and TechFAR.

    Great article here: New US Digital Service Looks to Avoid IT Catastrophes

    Discussion by Gunner: US Digital Service is Born

    Steve Kelman, FCW: The REAL regulatory challenge of agile development

    This simply isn’t bold enough. This effort simply try’s to fix whats broken instead of looking more deeply at why its broken and how to ‘reformat’ the way IT services are built and most importantly used by the government and citizens.

    The Service and TechFAR is akin to what the military seems to plan for: planning and building systems to fix yesterdays battles instead of really and deeply thunking for the future.

    UK: the UK gov digital service worked because its much, much smaller than our government (think California), two the UK gov is setup very differently than our government bureaucracy. The UK digital service reports directly to the PM and as I understand it, really could walk into any UK Agency (save MoD) and demand changes + take over projects. Also in a Parliamentary system, what the PM says goes, no discussing with Parliament, arguing over budgets, etc. a number of projects get killed pretty fast when there is a gov changeover.

    The US has neither.

    GSA is a pretty widely ignored Agency (for a number of historical reasons), maybe this time it will be different, I’m sure they can help web pages load faster. But the Digital service is going to report a few levels down from POTUS and the head of GSA, both of which have many other things on their plate.

    Also US Agencies have two masters they play pretty well off each other, Congress and the Pres. Scale: the gov is friggin huge. Also some government systems have very unique and multiple functions for only one customer (the Gov + citizens). Fixing FAA and SSA isn’t a few agile sprints over pizza and Dew.

    Instead of fixing past problems, we need deeper thinking about HOW and WHY the government should provide services.


    – The government no longer runs motor pools, it outsources the entire job to companies with specific service levels and agreements (SLA).

    – Failed example: SABRE (the airline reservation company) came to DoD and pitched the idea that they would take care of all military travel for something like $60 a ticket. Some govvies pitched they could do it cheaper, they tried and build a disaster of a service ++ Defense Travel continues to eat funds way above and beyond. And continues to frustrate and strand military travelers overseas.

    There are many more, but the basic take away is this: the government must not recreate services the private sector does cheaper, better and faster unless its part of its’ core mission.

    Bombs, check – part of core military mission.

    HR? (outside of the military and CIA), the government should license or buy as a service HR capabilities.

    Websites? I’m having a tough time with this. If the government could come up with a list of requirements and define a serious set of SLAs, they are any number of companies who would gladly offer website as a service, with the government managing the input.

    IRS systems: parts of it could defiantly be outsourced, especially all of fraud monitoring.

    One last point:

    YAR – yet another review, I don’t see how another YAR by the Digital Service is going to add to government agility and flexibility. Make no mistake, the gov is setup with a number of very expensive and time consuming YARs already, each which must be planned for and dumbed down to senior management.

    TechFAR inculcates YAR + yet another ref doc to read, that won’t apply to any Agency that doesn’t adopt it.

    Many of these suggestions sound good for a few projects, but crumple and slow down system creation when scaled to 1000s of project in an $80 billion portfolio.

    Some question to ask as the Gov builds systems:

    1. Is the thing your Agency needs to develop a core competency?

    2. if not, define how to buy it as a fixed price service offering w/ a tight SLA

    3. if yes, first start developing small + draft off of any existing efforts (open source software, or other state, local, international gov’s) ++ be open to the outside


    stop fixing current problems with past thinking

    stop telling industry how to suck the egg (i.e., stop dictating to industry what methods to use to develop technologies, CMMI was great for adding bodies – thanks for the revenue, is Agile really the endpoint of development methods? Lets not hard code something (again) into how the gov does procurement)

    automate eixsting jobs, rethink how the work gets done (IRS a body shop)

    automate existing process and rethink if you need them at all

    Start to collapse Agencies and processes. Does every Dept and Agency really need a CIO and associated staff?

    What things could Agencies outsource to each other (like paychecks that Dept of Ag does for smaller Agencies)

  • pintughosh

    Send your warm wishes in the form of classic Gifts to your loved ones on their special days through walking to our online website and
    Send Gifts to Chennai. This will make your dear ones happy and smiling.

  • Unsubscribe

    This idiot reflects poorly on you oreilly.

  • kaithor

    Agreed, the problems of large tech rollouts are not the province of government alone. Pretty much all of us who’ve worked in corporate America have dozens of eye-rolling stories of waste and mismanagement, but since it’s private sector and covered by NDAs, those skeletons mostly stay in the closet.

    I’m convinced the real problem is not public vs. private, but organizational size. Small companies, and small government shops, tend to get real more quickly. One of the best outfits in action I’ve seen is a 3 man Forest Service station – zero BS, all git ‘r done. Whereas once an org gets to a certain size, roughly 500 to 1000 people or more, it gets very easy to just shrug about the millions and billions being shuffled around. Historically most of the really big organizations have been in government (national scale), but private mega corps are closing that gap in recent decades.