Summary: Code for America
On May 12th, 2021 I joined my fellow presenters at the Code for America Summit to share how the City of New York has partnered with community-based talent to support COVID-19 response. This blog post outlines the three recommendations I made on how to collaborate with community groups in order to force-multiply digital service initiatives.
Outline rules: Use organizing principles, standards, and plays to support rapid response.
Don’t mistake words, ceremonies and practices of digital-era ways of working as buzzwords. These words are actually organizing principles for managing and coordinating teams.
When we say teams are “empowered”, we mean that product teams have the permission to make decisions about their product without endless rounds of sign-off. This is done to support velocity in sprints, and avoid product decisions swayed by the Highest-Paid Person’s Opinion (HiPPO), rather than evidence-based decisions around user needs. “Dedicated” teams isn’t referring to teams who are committed to their work; it means that each team is singularly focused (or dedicated) to one product at a time. Agile teams do this for the same reason that Henry Ford did; it enables efficient high-quality delivery. For a moment, imagine if Henry Ford had been trying to assemble cars, while simultaneously baking cupcakes, and also printing a daily newspapers; work would be shambolic and full of errors. It isn’t a way to manage an effective factory, or a digital product team; these common-sense management approaches are well documented, and all too often forgotten in organizations unfamiliar with managing high-performing digital teams.
Teams who are agile (or Agile) refer to practices related to the Agile Manifesto. This is a product and software development approach that is different from Waterfall ways of working, which are better suited for the construction of physical objects that cannot easily be iterated upon. For instance, a rocketship that has been launched into space cannot be easily updated, but a tech company will continuously improve its digital service for years after its release. “Multidisciplinary” teams means that all the skills needed, from policy, to development, to design, are made available on the team, while also being no larger than can be fed by two-pizzas. Finally, teams must be user-centered; as I will explain in detail below, this is a measurable set of practices that include conducting ongoing user research, and making clear how product trade off decisions are made to reflect the feedback from the target audience as the product is being conceptualized, developed, and improved.
Too often, people make the mistake of thinking that rules slow innovation and speed. In fact, organizing principles, including things like Playbooks, or Digital Service Standards are important because they enable teams to move quickly, consistently and coherently; take for example the California Crisis Standard, a set of guidelines for digital that enabled rapid-response in the early parts of the COVID-19 pandemic. Similarly, the NYC[x] Innovation Fellows program, an initiative by the NYC CTO in partnership with the U.S. Digital Response, brought together groups of complete strangers who organized and shipped work in 10 weeks. They were able to do this because the program adopted the well-established “plays”, principles and standards — practices that mirror common tech industry ways of working. By sharing these consistent, transparent and familiar ways of working, we enabled people to hit the ground running.
2. Ship product and culture in equal measure.
When it comes to digital transformation,“digital” is a tricky word, because it makes people get overly focused on the technology, when technology is rarely the hardest part. A great example of this is the UK, where their famous “Digital Service Standard” is now just the “Service Standard”, in recognition of the fact that in the 21st century, “digital services” and really just “services”. If we define digital as applying the culture, processes, business models and technologies of the internet era to respond to people’s raised expectations, then we see that much of this work is about people, and changing the culture of the working environment.
This work is challenging because the act of creation (of anything, including art, products, apps and websites) is unavoidably political; it involves power, decision making, and collaboration between diverse groups. Take the aforementioned user-centered design process. Asking basic questions, “How are you prioritizing your backlog?” or “When there is a trade off between two product features, how will you make that decision?” reveals that product design in government is fraught with tension because it spotlights how a Command and Control default position government decision making bumps up against a more “bottom-up” model of decision-making and leadership, which is more closely aligned to organizing principles of those “empowered” product teams described above. We say this is unavoidable because teams cannot maintain the status quo and also have effective product management or innovation culture in an organization.
Creating user-centered products is often disruptive to how product decisions have historically been made. This is because in user-centered design, you are engaging with real users every sprint, providing rich feedback on the likes and dislikes of your target users on your in-development work. When you engage with users, and watch them use early prototypes of your product, one quickly discovers areas of conflict between what the user wants, and what has been outlined as part of a product vision. This is part of the process, but resolving this tension is hard, complicated, messy work.
Often what makes transformation difficult for organizations who aren’t digital-by-default (aka were not founded or started as 21st century digital organizations, but rather, have a longer history) is that generally speaking, nobody actually asked for “culture change,” — they might think their culture is working just fine. What they asked for was a solution; “fix the website” or “build an app”. What is often overlooked in the smallprint of this exchange is that building great products people love to use means changing the way of building those products. It requires adopting the organizing principles mentioned earlier, and reorienting decision making around user need, which may not be how an organization has historically been making decisions.
When trying to ship product and culture, there are clear tactics used to help facilitate this way of working; holding ceremonies like Show & Tells or Demos or work-in-progress is one tremendously impactful approach, whether you are trying to save $15M on procurement project, or align a team around a new product vision. As we heard from the NYC[x] Innovation Fellows, cultivating feelings of psychological safety is critical for this type of work to be successful. These practices are codified through things like celebrating work early and often, and documenting team values in our Community Agreement (for Fellows), or Partnership Agreements/Scope of Work (for partners). While cultural factors are often seen as secondary to the more tangible work of product development, it has larger ramifications for the future of change initiatives.
3. Path to scale: Why community-based initiatives are uniquely well positioned to help scale digital service efforts.
One of the most fascinating things about digital government work is that digital teams are often both seen as “new” (the new team, the non-veterans, the disruptors) while working on old problem spaces that have had previous attempts at improvement. Similar to Whong’s Law, in my previous role, I worked on a high-profile project where there had been several previous attempts preceding our work. It is only natural, then, to ask “what makes one initiative succeed and another fail?”, or more specifically, how will we know this time is going to be different?
It is important to point out that the conceptualization of “failure” is different in public service than technology, which is where much of the community-based talents comes from. In tech, a failed startup might be considered a badge of honour, or earning your stripes. This framing is different in a government where fear of failure is an extension of fear of risk, and risk aversion is well-documented challenge for government innovation projects. In this model, change is exceptionally difficult because the culture of risk avoidance is so entrenched that getting someone to even consider new approaches means that we first must help people feel safe and open to trying new things.
But, here is some good news. One of the things you will notice about community-based talent, about programs like the NYC[x] Innovation Fellows, is that it jolts energy into existing processes. Community-based talent projects are uniquely well positioned to get people excited, to think differently, to act differently, to engage in new ways of working. These collaborations promote feelings of psychological safety, participation, openness to experimentation. These cultural dimensions aren’t “nice-to-haves” or an added bonus; they are a necessary precondition to creating a receptive environment to change. Cultivating this environment is critical when scaling from one-time initiatives to more sustained transformation.
The theme of this year’s Code for America Summit was “designing an equitable government together.” Through participation and collaboration between government teams and community-based talent, we are creating a movement of people who are invested in trying new ways of work, an important step as teams look to scale from on-off digital transformation initiatives to broader digital transformation.
Katherine Benjamin is the Deputy CTO for Digital Services at the New York City Mayor’s Office of the Chief Technology Officer. Together with Honey Danacay (Executive Director for Benefits Delivery Modernization, Government of Canada) and Jessica Cole (Chief Operating Officer, U.S. Digital Response), they spoke at the Code for America Summit on May 12th, 2021.
