Report - Belfer Center for Science and International Affairs, Harvard Kennedy School

2018 State of Digital Transformation

| October 2018


On June 12-13, 2018, digital HKS welcomed public sector digital services teams from around the world to share stories of success, talk about lessons learned, and discuss the challenges they face in transforming government. The teams convened all agreed on North Star goals of building platform services and putting users at the center; what remains much more difficult is identifying how teams in very different political and technology contexts should think about how to reach that end-state. In this report, digital HKS shares best practices we gleaned from this group, to start a broader conversation for digital services groups around the world about what comes next.

We dive into one of the big questions that frustrates digital services teams during development and strategy process: an assessment of maturity and effectiveness. The gathered teams represent the full spectrum of modern digital services, from teams that are just starting to score wins in new digital tools and upgraded services, to those that have built up full-stack platform tools that are transforming the way government and citizens interact. Teams agreed that there are three clear groupings in digital services groups: teams that are just getting started and are focused on quick wins and building relationships; teams that have built partnerships and achieved successes that enable larger and more impactful projects; and teams that have built a true platform for creating digital services and are pushing the envelope of innovation. We’ll propose a model and framework to help teams understand where they stand currently, and define which concrete steps will move them up the ladder.

We then share reflections from participants as well as concrete examples of what teams have learned in leadership development, delivery, governance, and succession. These lessons will reflect the smartest advice we heard from practitioners about their experience and the smart approaches they’ve learned over time. We’ll also share common pitfalls and struggles that teams faced along the way—and hopefully provide digital services groups with a better roadmap for long-term sustainability and success.

We don’t have all the answers, but we are excited to begin a more robust conversation around the world between digital services teams, many of whom have so much to share with one another, but frequently don’t have a chance to engage in frank discussions. We also don’t consider this effort a one-off toolkit or statement, but rather the start of a more productive conversation around the world about how we move digital services teams toward platform enablement, and how we turn the much larger and more complex ship of state toward a more user-centered, tech-smart approach.

These insights reflect the shared contributions of digital services teams from the governments of Argentina, Estonia, Mexico, New Zealand, Nova Scotia, Ontario, Peru, the United Kingdom, and the United States. The conversation followed Chatham House Rules (i.e., comments are not attributed to an individual), and we wish to express our gratitude to the whole group for their candid and thoughtful insights. Also in attendance were former White House Deputy CTO Jen Pahlka from Code for America, as well as digital HKS fellows Kathy Pham and Richard Pope. We want to give special thanks to Public Digital for helping to organize this event.


Proposing A Maturity Model for Digital Services

By David Eaves and Ben McGuire


Toward A Maturity Model for Digital Services Groups

With a growing number of public-sector digital services units and the national and state/provincial level having largely moved past the launch phase, one of the biggest questions that we hear is how to contextualize progress made and milestones yet to achieve. Trying to make progress in a completely new space is hard when units can’t define where they are relative to the progress that has been made elsewhere. Without that context, setting smart long-term goals is extremely tough—and planning how to get there is even tougher.

To date, we haven’t seen a lot of models out there to map the maturity of different digital services organizations in the public sector—but we’ve heard from units at all stages of progress that having a shared set of definitions for maturity would be very helpful. In this document, we aggregate trends and observations from units to start a new conversation on these issues. We want to especially thank Kathy Pham, Mike Bracken, Richard Pope, and Till Wirth for their perspective, thoughts, and substantial contributions to this framework.

We don’t believe there will be just one model that will work everywhere and at all times—and we fully recognize that the real value units provide isn’t checking boxes on a model, but rather delivering value to citizens. We love feedback from practitioners and observers of this space about things that resonate (or do not resonate) with you—and if your team is creating value in ways that aren’t reflected here, we would love to hear about your experience.

We’ve attempted to codify a lot of what we’ve been hearing from various units into a framework around five high-level themes:

  • Political environment
  • Institutional capacity
  • Delivery capability
  • Skills and hiring
  • User-centered design
  • Cross-government platforms.

Within these themes, we then break out what we’ve heard are the most important components of success. This doesn’t mean the number of projects completed, or the coolest application created—in fact, we heard several times to avoid those kinds of measures of maturity. Instead, what we’ve tried to lay out is a model that captures the organizational development of digital services. Here, moving from Low to Medium to High can be additive—putting something new in place—or subtractive—getting rid of a feature as we progress.

A Proposed Maturity Framework for Public-Sector Digital Services

We don’t want to pretend like this is a final or a perfect consolidation of the many lessons we learned at the convening in June; in fact, we’re pushing this out publicly now because we’re seeking your feedback on it. It’s our hope that this can become a useful benchmarking tool for digital services groups around the world.


Political Environment





Future State

Developing Executive Public Service Sponsors

Unit operates as ‘insurgent’ without formal executive sponsorship.

Digital unit has a formal relationship only with its executive sponsor.

Digital unit has formal relationship with executives in multiple other departments.

Majority of senior executives across the organization understand the importance of strategic digital transformation.

Building Political Capital

Digital services has little to no political support.

Digital services projects help create political capital for core sponsor.

Digital services provides advice and prevents challenges for core sponsor.

Digital service is a strategic partner that helps accelerate top-priority projects.

Codifying Digital Services Standards1

Digital services requirements are strictly voluntary for departments.

Digital services requirements are vocally encouraged by senior leaders.

Digital services requirements are codified through administrative act (e.g., presidential decree)

Digital services requirements are codified through legislation.

[1] E.g., Accessibility guidelines


Institutional Capacity





Future State

Budgeting for Success

Digital services budget is scraped together from funds allocated to other departments.

Digital services are reliant on continuous annual budget negotiations.

Digital services are supported by a multi-year allocation of capital expenditures.

Multi-year budgets include funding through operating as well as capital expenditures.

Building Out The Digital Services Mission

Digital units are only trusted with limited-scale projects.

Digital services mostly fire-fights through ad hoc, demand- driven projects

Digital services takes on a limited number of large, strategic projects and helps others build capacity and shift culture.

Agile units operate independently and at scale across departments, supported by centralized digital services unit.

Inflecting Public-Sector Operations

Best practices are shared with other departments when asked for.

Digital services has created government- wide standards for technology projects.

Digital services has some carrot-and-stick incentives to encourage buy-in to standards.


Delivery Capability





Future State

Access to Tools

Digital service unit may use only enterprise-approved tools.

Digital service unit receives exemptions from general requirements to use some specialized tools.

Digital unit starts to change the rules about what tools should be available across government.

Government’s capacity to adopt new tools to respond to public servants’ needs is more adaptive.

Working in the Open

Digital service unit is restricted from working in the open; messaging is heavily controlled.

Some members of the digital service unit are allowed to work in the open with minimal communications oversight.

The digital service unit and some members of the government are allowed to work in the open.

Rules about how public servants talk about their work are reshaped by ‘working in the open’ norms.

User Feedback Cycle

Digital service unit is not allowed to release beta versions and can only test internally.

Digital service unit adopts an Alpha-Beta-Live approach for launching projects.

Other government agencies adopt an Alpha-Beta-Live approach voluntarily.

Alpha-Beta-Live approaches are standard across government,


Skills and Hiring





Future State

Aligning on Role Definitions and Goals

Digital unit has little or no ability to define new government roles.

Unit has power to define key roles (e.g., Product Manager, UX Engineer) within their unit only.

Unit has power to define key roles (e.g., Product Manager, UX Engineer) across the government.

Digital roles have been aligned to peer jurisdictions and private-sector standards.

Building A Robust Talent Pipeline

Digital units are informally organized and have no power to recruit.

Digital units recruit talent mostly through established government channels.

Digital units engage in recruitment with higher education partners as well as private-sector firms.

Relationships with private-sector and higher-education partners allow easy transition into government digital service.

Making Space for Growth

Digital units conduct informal ‘show and tell’ of ongoing projects.

Digital services helps convene engaged public servants on relevant topics.

Digital unit leverages school of public service to generate space for rotational on-the-job training for public servants.

Digital units have independent, formal management training and leadership development programming in place.


User-Centered Design





Future State

Codifying User Experience (UX) Testing in Operations

UX testing is best practice within digital unit.

Digital services helps other departments conduct UX testing.

UX testing is a formal requirement for new services in at least one non-digital department.

UX testing is a government-wide expectation for rollout of new services.

Prioritizing User Perspectives

Digital units conduct UX testing during software development.

UX-testing results inform ongoing operations.

UX-testing results are core to strategy priorities in multiple departments.

UX testing is included in policy development and agency rulemaking.

Building Product Management Competencies

Staff in the digital unit think about the user’s perspective within projects.

Product manager roles are firmly established within the digital unit.

Digital unit supports an ad hoc, emerging community of practice for Product Managers across government.

Product Manager roles across government have legitimacy and clear career paths.

Shared Design Patterns

Digital service unit attempts to apply some regular design patterns across projects it touches.

Digital service unit has a single design pattern that it applies to all projects.

Departments and agencies not affiliated with digital service unit begin to adopt its design pattern voluntarily.

Some informal or formal governance mechanism around design patterns exists.


Cross-Government Platforms





Future State

Creating Public Registers of Data

Digital units are aware of platform and data register potential but have no formal plans for development.

A standard for publishing data in a structured way is available but only a few public registers of data are published

The standard for publishing data registers is used by most departments and high volume registers are published

Public data is published in a structured and API accessible way by default


Private Data Registers between Departments

Data sharing agreements are in place between a few departments but they are one-offs

A few government departments have created private data registers that they make available to other departments

Data sharing between government departments is governed by standard rules/agreements and common practice with all departments

Creating Shared Platforms

A few platforms are available in private beta to a select number of central departments.

Some of the most common needs (e.g identity, payments) are covered by shared platforms that are available to the whole public sector

All common needs are covered by shared platforms and allow for rapid deployment of new services.

Developing Platform Governance

A few platforms are available in private beta to a select number of central departments

Platform teams publish their roadmaps and performance and have established a forum for partners to influence their development

A cross-government group of departments decide jointly about the development of new platforms and influences their prioritisation



Building Better Digital Services Teams

By Matt Spector



Government digital services teams – regardless of their size and tenure – continue to face the people challenge, from recruiting the right capabilities for the right operational mandates to the increasingly pressing challenges of overwork. Each can lead to critical talent gaps, with teams failing to cycle people and talent meaningfully. And each of these growth and management challenges can put these teams at risk.

And yet, digital services teams shouldn’t underestimate their power to recruit—because finding qualified people for transformative public services isn’t a competition on salary or title, but on impact and mission. Recruitment rests on an appeal to a sense of duty, a desire to make the world better, and an opportunity to achieve change at scale. While digital services groups in the United States sometimes find themselves competing with tech firms and startups for staff, digital services teams in places like Mexico and Peru have had phenomenal success in recruiting top candidates. This suggests that there is a real appetite out there—and that if digital services groups can drive a genuine mission and real impact, they will be able to build great teams.

There’s an old adage that “civil services have very good immune systems – they are very good at isolating disruptors.” Many digital teams see part of their mission as shifting the skillset and culture of public service—to make disruptors into allies and show that resistors are the problem to be solved. New digital leaders need to purposefully wade through silos to accomplish the hard work of digital transformation, patiently and systematically promoting cultural change through collaborative methodologies and incremental change.

Build Diverse Teams Reflective of Their User Base

It’s critical to build a digital services team that reflects the diversity of the population it serves. Teams that do can leverage broader perspectives and experiences in design processes. The will be far better-equipped to focus on and identify user needs. They will have more credibility with the public service and the public. While hiring standards for this kind of diversity can created a challenge, the best digital services teams practice what they preach. Many leaders will even not attend events or initiatives which do not practice meaningful diversity and inclusion.

Supplement Technical Skillsets: Hire for Consultative and Management Skills

Ontario’s team additionally underscored the need for recruiting digital services team members that have enablement and consultative skills alongside product capability, particularly in building beyond the digital service unit’s delivery capacity to create programs that align with agencies’ interests. These consultative and enablement skills help bridge a critical gap, building actionable plans that allow for operational handoff and the discipline of managing and owning outputs and deliverables over time. In cultivating teams of “kickass product owners,” digital services leaders discussed the dual need for team members who understand the complexities and nuances of policy alongside excellence in product delivery.

Elevate Digital Competencies and Roles within Ministries

Certain jurisdictions, including New Zealand’s national government, have begun to elevate digital competencies as critical roles within ministries. New Zealand stressed the importance of articulating decision rights – clear accountability for the agency’s outcomes across all projects and programs. The risks of decision rights, however, make the digital services team or the agency in question ultimately responsible in case of a product or program failure, and leaders must navigate this divide carefully with each engagement. The team articulated cross-agency initiatives that build beyond silos and created lasting pools of funding for change. New Zealand’s advocacy helped establish a service innovation fund within the government that is contestable by agencies, and is executing the first multiagency life event program. These proof points and aligned incentives helped show civil servants and ministers the value of digital service across the broader government.

Broadcast Achievements in Culture Change

At their core, digital service teams like the digital services operation in Ontario see their mission as one of change management rather than digital achievement, and their critical contribution as “shipping culture” through prioritizing projects and environments of diversity, inclusion and belonging. Experts discussed digital service unit recruitment barriers from lagging technical and management skill to the inertia of bureaucratic hiring processes. Participants underscored the importance of performing government transformation and digital excellence functions brilliantly, reducing or virtually eliminating downtime for existing initiatives and products, and broadcasting achievements by “working out loud,” telling candid and verifiable organizational stories in the environments where they are most likely to be shared and read, to the audiences, citizens, and users who most need to engage.


Digital services leaders face a “people pivot point” in the shift from startup to scale, including overcoming challenges in team growth and operational sustainability. Whether teams are established, each digital services leader underscored the importance of norms and expectations for digital services teams throughout their respective bureaucracies, creating clear lines of accountability, speaking with language that engages potential hires and internal stakeholders, and proves the potential of the digital operation.

The bigger challenge that digital services teams face moving forward is how we go from scale within the team—i.e., building from a small to a large centralized group—from scale across government. If digital services successfully inflects the culture of other departments, many of them might be managing and deploying their own independent agile digital services teams—requiring different-in-kind practices for recruitment, training, and management. We don’t yet know how to operate in that environment—but that’s exactly where some of the most exciting teamwork will be happening over the next decade.



Finding the Path to Digital Services at Scale

By Ben McGuire



One of the biggest debates across digital services teams has nothing to do with technology or platform services, but rather focuses on the best strategy to build from launch to scale. The deceptively simple choice is between going ‘big’ (i.e., focusing on exciting, high-profile projects with strong political backing) or going ‘small’ (i.e., building incremental political capital through quiet but useful projects). Both approaches have worked in different contexts, and the best approach reflects careful attention to local conditions. This piece frames some of the most important tradeoffs to think about in the big versus small conversation—and highlights two strategies that practitioners recommend no matter what choice you make.

Going Big—Using Public, Exciting Goals to Build Strength Fast

One of the biggest recommendations from the digital services team in Mexico was connecting the digital services program to big, bold, public goals. It can be tempting for new digital teams to keep a low profile as they build relationships and notch small internal victories. But the strength of the organization and its sustainability in the long term will partially depend on its ability to create excitement and political wins. Make digital transformation aspirational, not just a collection of workaday best practices, and you can capture the imagination of public servants as well as citizens. In Mexico, the digital services group set an aggressive timeline for growth in a time of rapid change—internet use and smartphone penetration doubled during the same period when the government was rolling out to serve as a digital services hub for all agencies. The shared vision of a new, connected, and digitally-enabled Mexican citizenry inspired action and engagement. When crisis struck during a 2017 earthquake, volunteers from Mexican civil society built open-data tools to connect loved ones and map damage, all pushed at the top of A public calendar helped keep the digital team accountable to its goals; perhaps even more importantly, it helped acculturate external partners to future progress and sustained momentum as activity grew.

Going big might be exciting—but it can also carry significant risks. If the digital team sets very high expectations on a public-facing project, delay or failure could rupture trust with not only the public, but with executive sponsors who advocated on behalf of the digital services approach. When going big fails, it can have ripple effects into the future, and make it difficult for digital teams to build political capital for years. Practitioners argued that going big might require strong executive sponsorship—perhaps even legislative or executive mandates—to be successful.

Going Small

On the other hand, many teams that did not gain the early support of a cabinet member or national executive had to take a very different approach so that they could gain trust and legitimacy within the public sector before moving services to the general public. Digital teams like the UK’s GDS started out relatively small, and focused on delivering high-value, ‘quiet’ projects to strategic partners across the government to build incremental political capital. Being small means a team can be nimble and quickly take advantage of new opportunities. It also allows teams to be more experimental; it’s much easier and safer to fail and learn from failure when the consequences of a missed deadline do not imperil all of digital services.

But going small has downsides. If failure is less risky, success is also less powerful; a successful project won’t provide significant political value for partners or build public trust. Small teams need to work much harder to define what their value is and try to move as quickly as possible to become indispensable.

Tactics for Big and Small Teams—Find External Champions And Go Where the Work Is

Regardless of whether a team goes big or small, achieving buy-in for digital services projects requires demonstrated success at helping agencies create value for citizens and agencies. However, moving forward a project successfully also demands enthusiastic participation from those same government partners. This start-up tension can keep digital services teams sidelined from major work for years, as very small software upgrades and web redesigns build incremental political capital. Teams that successfully made the transition to more strategic and value-creating work recommended two major tactics for teams in the launch phase; identify and cultivated champions outside the digital team, and home in your efforts on where work is already happening.

Identify and Cultivate Champions Outside the Digital Team

Public goals are more than a signal to citizens; they can also help to build confidence with external leaders that can support the digital team in the long term. One of the most important early moves for a digital services team is finding (and creating) champions for digital government outside of the digital group. Some teams are lucky enough to launch alongside an executive sponsor at the cabinet level who is already invested in digital transformation, while others must build these relationships from scratch. Allies don’t need to have a technical background to be helpful—in fact, non-technical sponsors might be even more effective at understanding and communicating the non-technical outcomes and goals that digital services are helping to provide.

Teams in Mexico found that mandates from above—like the 2015 Presidential decree to create a single, national web portal for the country—were helpful in establishing digital services as a priority. However, mandates are only as durable as the political administration that creates them. Sustainable champions will be able to clearly see the benefits that digital service groups create for them and for their department—and will want to make partnership with digital teams a priority for their successors.

The United States Digital Service has also found that sponsors need not be necessarily executive-level to be effective partners. They work to cultivate ‘sleeper agents’ in other government agencies who are interested in streamlining and scaling up services through digital tools—and nurture these relationships through constant, if informal communication.

Go Where Work Is Already Happening to Find Quick Wins and Build Trust

Getting strong champions is not only valuable because it provides political capital for funding and project momentum—it also helps shine a light on work happening across the government and unmet needs where digital services can provide support. In Mexico, the team chose projects using a framework that prioritized high-demand and high-use services (e.g., as measured through website visits) as well as priority programs for the national administration. Going to where there was already work happening allowed teams from both Mexico and the United States to leverage the urgency driving action on other teams into an argument for digital transformation.

In Mexico, this included big projects affecting millions of citizens once in a while—like automating interstate travel documentation—and more esoteric work with high impact for a few—like creating a single portal for new drone licenses. In the long term, teams need to work toward transformational projects like shared platforms which might not have ongoing work or a natural current ally. Leveraging the urgency and agency of other teams in the short-to-medium term, and building credibility by helping others achieve their goals, is the best way to build the foundation that enables that long-term vision.

Delivery at pace isn’t easy. All digital teams around the world have learned hard lessons about striking the right balance between picking low-hanging fruit that makes people happy, and finding the kinds of transformative projects that take far more time and energy but can create major impact. Teams from Mexico and the United States faced very different political and technological landscapes when they got off the ground, but both found that a combination of finding strong external champions, leveraging existing work, and establishing bold, public goals helped them move forward. As more national and subnational entities take on the exciting work of digital government transformation, they should think about how to replicate these successes and build delivery at pace into the fabric of their own organizations.



Sustainability and Political Succession

By Emily Middleton



Picture this: you’re a new digital team in a national government, and recently launched your first alpha. You’re small—around ten people. But your office was established by the PM, so you have political cover from above. And as each week passes, you’re gathering supporters and getting stuff done. So far so good.

And then suddenly, the President and Prime Minister—the politician who created your team in the first place—resign. You’ve been in existence for eighteen months. Your new political overlords have a different political agenda. What now?

This was the situation the Peru Innovation Unit found themselves. Two factors helped them survive this sudden political succession: fast delivery, and using bureaucracy to their advantage. First, they had already launched, a government-wide publishing platform—and it was attracting more than 600,000 monthly unique users with no marketing. That success was hard for any politician to ignore. Second, the team realized that a presidential decree for would carry significant weight. With the president’s official, written support, the team achieved a sense of security which outlasted the individual.

Every government digital group will experience political succession, though clearly the circumstances range from the favorable (well-established digital team, pre-election statements of support from all parties, predictable electoral timelines) to potentially disastrous (very new team, shock resignations/elections, no transition period and lots of unknowns). It’s critical that the digital team’s long-term strategy is not dependent on any one public servant or political party. The digital team needs to create connections across political aisles and across the public service, so that a strong coalition can learn to see digital services as core to public value.

A real danger is that digital teams will come to see the value of their work as so self-evident that it doesn’t need to be explained or advertised—and that successfully serving a lot of users (in the public service or the public) will protect digital teams from cuts. But neither of those things is necessarily true. The best digital teams are constantly working to build political sustainability into operations—and that requires attention to smart tactics.

Time for Tactics

It’s possible to plan—even for unforeseen political crises. Attendees suggested a range of tactics—both in delivery and relationship-building:

  • Win legitimacy by rapidly delivering popular digital services. And then invest resources in improving and scaling them. and As one attendee said: “Our strategy is to make platforms so robust and useful that it would be crazy to go against them.”
  • Start building relationships with parties on both sides of the aisle, well ahead of an election actually being called. If possible, get a commitment to continue or expand your digital team’s work in the manifesto of every major political party.
  • Win friends in the broader tech ecosystem. Universities, the civic tech community and startups all wield soft power. Having them onside can help shore up a digital team’s position during a political transition. Indeed, if you are political appointees, you might need friendly intermediaries or external influencers to advocate to other parties on your behalf.
  • Design for continuity. In the scenario that you—the digital team leadership—gets replaced, leave behind a set of standards based on “common-sense usefulness” for digital service design. Ensure that non-partisan civil servants in the team retain the knowledge, skills and culture and to navigate any period of transition.

Not everyone agreed with these approaches. Is it possible—or even desirable—to develop interoperable platforms that are “too big to fail”? How much time should a young digital team spend on networking, at the (possible) expense of delivering? The right approach will depend on a team’s particular circumstances.

Gaining and maintaining political attention

So how do you go about gaining and maintaining the attention of less digitally-minded ministers?

Attendees shared three pre-tested tactics:

  • Show the thing: Ministers are invariably more excited by a live demo of a service, rather than a proposed product or a screengrab.
  • Show the (personalized) thing: Even better is to demo a product or service that addresses an issue the politician cares about.
  • Show the (relevant) data: aside from user numbers, one digital service team is careful to present numbers that relate to a ministry’s core goals (such as number of passports applied for digitally, number of appointments booked online).

Attendees agreed that showing a minister how your work aids the goals of their ministry, or addresses the needs of their constituents, helps to gain political attention. Continuing to grow the number and satisfaction of users helps to maintain it.

Working on digital projects means teams can often show ministers a tool much faster than they are used to—and there’s political value in that fast value. But there’s a risk to this kind of tactical approach—being a team that shows ministers a new small, shiny thing they want now can mean that deep, transformative work goes to the backburner and stays there. Teams must work to ensure that short-term projects building incremental capital can also play a role in long-term strategic development.

Strategies for established teams

But these tactics might be less effective for more established digital teams that have had more time to build a track record – but also to attract both supporters and detractors. These teams may be concerned about suffering a significant budget cut, or having their influence or remit eroded. Such events may be less dramatic than a sudden closure, but might contribute to the same outcome, via a slow decline.

Such teams may need to adjust their strategies and communications more fundamentally, if they are to survive a new administration.

For instance, there is increased pressure to cut costs and improve efficiency in both the US and UK governments, since their general elections in 2016 and 2017 respectively. Service improvement and cost-savings are by no means mutually exclusive. But in such situations, digital teams may do well to focus their rhetoric, and to an extent their resources, on projects that can deliver clear, quantifiable cost savings in the short term. That may help to buy them time and trust with the new administration. Teams may also want to invest time in quantifying and communicating the financial benefits of their work.

This appears to be the strategy of the United States Digital Service’s leader Matt Cutts, who spoke to WIRED magazine in May, emphasizing a $100 million saving his team had secured, rather than its work to improve asylum seekers’ interactions with government. Similarly, the UK Government Digital Service has been emphasizing its resource-saving credentials in recent months.

It’s not yet clear if this approach will be enough. And it can have unwanted consequences. For instance, a major reprioritization risks alienating employees and would-be recruits from the tech sector, who may be more motivated by transforming service delivery than cutting costs.


Many attendees were facing possible political successions in the next year. Navigating them will not be straightforward, and uncertainties remain. But we hope that with preparation, a clear track record, and some of the tactics above, digital service teams around the world will be able to survive these transitions and thrive afterwards.



Power in Convening: Why Bringing Digital Groups Together Creates Effective Conversations

By David Eaves and Ben McGuire



From June 12-13, 2018, digital HKS and Public Digital convened public sector digital services teams from around the world at the Harvard Kennedy School of Government. Teams and experts from nine nations shared stories of success, talked about lessons learned, and discussed the challenges they face in transforming government.

Across the next few weeks, digital HKS will be sharing the most important takeaways from the convening through our blog—and we will also publish the collected learnings as a physical text later this year. We started with an introduction post explaining the full framework; in this post, we discuss what it was like when a roomful of expert practitioners shared a case.

Teaching A Case with Expert Practitioners

One exciting moment at this summer’s convening was a session where participants discussed a “case” on how California’s Child Welfare Services (CWS) team disrupted traditional technology procurement rules. This particular case, which we wrote here at Harvard and teach within the digital government curriculum, is used regularly in classrooms. Students read it in advance and then come to class and debate the decisions and actions of the protagonists and argue over the correct course of action. It is a powerful way and engaging way to teach new ideas and to force students to contemplate real scenarios in which they may be decision makers in the future.

The case itself is the story of a somewhat radical proposal to overhaul the backend technology system that CWS used to manage the hundreds of thousands of abuse and neglect cases it encountered annually. The infrastructure had basic functionality, but was way behind the times—social workers were still transcribing handwritten notes into the system and had no way to access information remotely. Between 2012 and 2015, state departments collaborated on a large RFP that called for a traditional waterfall procurement (i.e., linear and fully planned in advance). Just a few weeks before the RFP was set for release, a group of third party reviewers (including staff from Code for America and the former United States CTO) identified big risks in the plan and suggested an ‘agile’ procurement in component parts, incorporating iteration and testing. California officials were looking for an alternative approach to the traditional waterfall procurement and had an existing relationship with Code for America from their work on CalFresh. And so they decided to take a big risk, and launched a modular procurement to support an agile approach for iterative and continuous product delivery for a big, high-risk, and highly-political investment.

I’ve taught this case many times for many audiences—but there’s a real joy and energy in talking through this story with a high-knowledge, high-profile group of digital teams who have faced this kind of decision in their own nations. Their subject-matter expertise and skillsets push the case to its limits—while more sympathetic to agile than some audience might be, they are also highly competent, asking tough questions about assumptions the team made, choices in technology purchases, and granular team dynamics and organizational structures. But even with a group like this, there’s a great deal of learning that happens because we can share experiences with each other. One thing that everyone agreed upon was that taking a $500 million procurement and making it agile at-scale for the first time took tremendous leadership. While the risks of succeeding were likely higher (or at worst the same) as adopting the traditional approach, doing something different than the status quo involved real reputational risk for the protagonists.

The CWS digital transformation is still in progress—and thanks to some participants who had journeyed from the California team, we were able to talk through some big benefits that have already emerged from their willingness to take a leap of faith. But a great feature of a convening of this kind of group is that we can create a space where it’s possible to discuss not only good outcomes that make it into the newspaper, but also the kinds of complicated issues that arise that other teams need to be aware of and can learn from. Too often, our stories about digital transformation (or really any story told and communal gatherings) are only about the former—the really exciting wins and successes that we want to share. But if we can’t create a really safe space where teams can be critical of themselves and each other, we won’t succeed in digital transformation in the long term—and I worry we won’t succeed at governing, period.

A Conversation That Continues

One of the most fascinating debates in the room that emerged was about the virtues and dangers of digital transformation at scale. A lot of teams looked at the CWS story and believed that it was too big and too risky of a starting point for Agile in the public sector. After all, when we think about Agile, we usually think small—short sprints, small scrums. If we get our first big step wrong in digital transformation, a lot of us worry that we’ll poison the well of innovation for a long time.

But an interesting trend emerged from other teams in the room that had tried something big and failed; the scale of the effort created visibility that let teams across government see that another way was possible. Even without an unvarnished success, there are tons of teams all across government who recognize that over-bureaucratic structures are holding back their service provision. The real danger of focusing on small projects and small successes is that you’ll never cross the chasm to scale—because everyone will look at the limited project you did and say ‘That doesn’t apply to me.’ Big projects (like or the CWS procurement) are big and complicated—and we should absolutely think about the consequences if things go wrong. But one of the lessons that came out of the convening was that if you go big, there can be success even when we don’t hit all of our goals right away.

We might think about it on a simple spectrum—we can have projects on a scale of small to big, and we can think about projects on an increasing scale of risk (with very big projects being very risky). We see a lot of teams going with small projects in the bottom two squares, hoping that small wins will add up in the right column, wary of the risks of going big and striking out. We don’t think there’s just one simple answer to this question, but one of the really powerful stories that emerged when we had teams altogether was that being ambitious and taking risks can pay off in ways that aren’t always reflected in a simple ‘did we hit the deadline’ post-mortem.

Rethinking the Approach to Scale and Risk in Digital Transformation

Increasing project size vs. project risk graphic

This isn’t a conversation that ends here—we still have a lot of debate and experience that will inform how we approach the scale question. But if we can continue to convene groups like the one that gathered in Cambridge this summer, I’m very optimistic that the future of digital transformation will be bright.



The Future of Governance for Digital Platforms

By Ben McGuire



The largest remaining hurdle to successfully reaching the platform digital services North Star is not in technology; the underlying technical structure for shared digital services integration, testing, and continuous deployment are mostly well-understood. In contrast, we have yet to really address a larger social and scale challenge: models for oversight, accountability, and management of shared digital platforms. Early adopters have identified some new benefits as well as risks around governance, and pinpointed best practices of which digital services teams should be aware. But big questions remain ahead for digital service teams as they work out systems of control, access, and management—and begin to tackle the implications of platform services for democratic processes and the organization of government.

Governance Lessons from the Field

Platforms change the nature of new service investments, which helps agencies be faster and more user-centered, and also makes it easier to sunset programs that are no longer necessary. At the same time, putting cross-government services on shared platforms also changes the nature of risk. A single point of failure concentrates all political risk on the platform manager, and also raises the impact of a cybersecurity breach or attack which could immobilize services across the government.

The benefits of platforms derive mainly from their ability to more quickly and easily build and iterate services that meet the needs of users. By creating a shared digital infrastructure that all agencies can leverage rather than having departments constantly build from scratch, a platform approach can dramatically reduce software spending and maintenance costs (e.g., it could be cheaper to develop security protections once for a platform than deal with myriad department-level approaches). But reduced cost and time to build means that platform services also change the incentives for creating and sunsetting programs. New tools can be designed and rolled out much faster, slowly changing the orientation of agencies to be more user-focused. Thanks to a common payments platform in the United Kingdom, creating a new service to collect consumer payments takes just a few minutes—doing the same job five years ago might have taken weeks. At the same time, services that are spun up faster are also easier to sunset, because they don’t involve the same investments of time, energy, and people. In Estonia, the digital services team is finding that conversations about turning services off and reform are getting much easier and productive, because agencies are less worried about making up sunk cost investments.

New risks accompany these new benefits. If the value of consolidation and a shared-service infrastructure is efficiency, the process also creates a single point of failure for all kinds of programs and agencies across government. Whichever team is responsible for managing the platform now bears all of the political risk for disruptions to services which could affect millions of citizens. The political consequences from the botched rollout of in the United States would pale in comparison to what would happen from downtime in a platform that supports services across a nation. There is also potentially higher danger associated with a cyber security incident that affects a platform shared across many departments. Platforms might contain many types of sensitive data about citizens, making the platform itself a tantalizing target. In addition, a disruption to the platform will also be very costly for government, making security investments a priority.

We’re still in the early days of platform government digital services, but early adopters can share some advice on governance from their successes as well as mistakes.

Make It Easy for Departments to Use

One of the most important lessons that teams in the UK during the development of notification and payments platform services was that in order to get other groups interested in using a shared service, it had to be extremely easy for them to use. In the payments platform, spinning up a new government url with a payment link takes less than five minutes with the appropriate authorizations—which means that getting payments through the platform will almost always be faster and easier than building or buying a department-specific tool.

Become A ‘Sales’ Organization

Once a platform exists, scalability will remain only theoretical until departments are willing to link up—and that means digital teams need to develop a competency in ‘sales’ to drive adoption. Leadership in Estonia and the UK have had to re-orient their departments to identify teams that might benefit (i.e., through lower costs or improved outcomes) from switching over to new platform tools. They then proactively go out to meet with those units, explain the services that exist, and pitch the benefits. Most departments will see little upside in changing the way they operate without active explanation and translation—and digital teams will need to develop sales skills to move those conversations forward.

Work Toward Resilience and Sustainability

Great digital services teams which are successful in building platform services launched their work with a focus on sustainability and long-term staying power. When hardware and software refresh dates were identified in other departments, they looked for opportunities to shift projects to a shared platform service. New fiscal years and agency leadership turnovers became chances to codify platform migration as a shared goal and priority for the next chunk of time. In Estonia, digital leaders also have fought to move platform software out of the capital expenditure budget (where investments can be subject to political headwinds or changing budget priorities) into the operating expenditure budget (where perennial spending and critical functions are housed). The capital-to-operating budget shift helps to demonstrate the importance of platform tools for other stakeholders—and also makes that spending much harder to kill for political convenience.

Four Hurdles in the Future of Platform Governance

Teams were excited to share these lessons, but stressed that there’s still a lot that they have to learn. For example, one of the biggest challenges facing platform tools is what to do about cross-border and international data sharing. All of the struggles over data management, formatting, and technology that happen inside a country’s borders are replicated at huge scale when two nations need to be able to integrate information.

More importantly, we’re still coming to terms with how to make sure that platform services remain responsive to democratic processes. Incorporating user-centeredness helps ensure that citizens are constantly considered as part of service development, but who should own and manage platforms—as well as rules about access and control—are still open questions. The first nation to truly embrace and invest in platform digital governance will have a huge opportunity to deliver services at scale, cheaply. The challenge has four key components:

  1. The future may break the social contract between government and citizens: At the moment in the Western world, many people are comfortable sharing with government on the implicit understanding that government is too legally restricted, organizationally siloed, or inefficient to link data together to learn about them. What happens when government services can efficiently link data across agencies is anyone’s guess. If security services can get access to healthcare records and track down undocumented immigrants in the hospital, will marginalized populations still be willing to participate in life-saving services?
  2. Whoever controls the servers will control the government: Agencies that own core APIs for cross-government services may be able to control access to tools and microservices. If one agency (or one central leader) didn’t like how an agency was carrying out its mission, might it be possible to deny access and arbitrarily control the shape of future development?
  3. Whoever owns services shapes the future: Bureaucrats that sit atop canonical servers and services will set policy – controlling the guidelines for product roadmaps, integration, and allowable features. Those who build the system will have the ability to constrain the actions and opportunities of all who come after them.
  4. Which services and datasets should be shared? Aadhaar services in India can authenticate phone and banking services, which simplifies things for consumers and companies but also hands a lot of control to government. Those who push for efficiency and shared services today might worry if the balance of power shifts to a set of actors that don’t share their approach to governance.

The question we face is how to build new public works matched to the problems and opportunities of the 21st century. It requires new governance models, lots of public buy-in, and a new commitment to responsible use of shared digital platforms that we haven’t yet begun to tackle.



Practitioner Reflections



Winning the Uphill Battle

By Tom Loosemore

Loosemore photo

It’s been a couple of weeks since we returned from the Digital Services Convening event at Harvard, put together jointly with DigitalHKS. I’ve been reflecting on what I learned during those two days.

Here’s a short list of the thoughts that keep coming back to me.

You can move faster with strong political cover

The whole point of the event was to gather together digital government professionals from all over the world, and give them a chance to talk to one another. The result was 2 days of liberating honesty.

We heard from teams who are moving with staggering speed. Some of them are moving a hell of a lot faster than we did during the early days of the UK’s Government Digital Service (GDS), and with fewer people to boot.

The pace shown by the digital teams from Mexico, Argentina and Peru left me with my mouth hanging open in astonishment. They’re that good.

Much of this is because those teams have strong ministerial support. They have their Francis Maude-equivalents, people with both political clout and earned respect from their peers. People who can say “This is what should happen,” and it happens.

You can move faster if you’re based in the centre

It’s not enough to have a powerful person behind you, though. You also need a powerful institution.

Those high-performing teams have another shared characteristic: they’re based within strong central departments. Finance departments or treasuries or offices of the president. They’re strong because they’re already perceived to have a horizontal mandate across the rest of government. Existing financial and organisational levers can be used to encourage other departments and agencies to move similarly boldly.

It’s an unfortunate reality that most government departments in most countries see themselves as units of power to be wielded, or control to be protected. They are always very keen to operate in their own interests, and very reluctant to operate in the interests of other departments. It’s all very “us and them”. To some extent, because mandates, budgets and the governing political structure reinforce this behaviour. As Mike Bracken said in a recent interview: “Whitehall isn’t built to share, it’s built on straight lines and silos.”

That’s why you need that horizontal mandate, and the perception that it’s already something that matters. Department leaders know it, understand it, and respect it. They will respond to it.

Smart teams plan ahead for political change

There’s a flip side to what I’ve just written above: if your mandate comes from specific individuals, it can literally disappear overnight when there’s an election. So smart teams plan ahead for that.

In Ontario, for example, the CDO Hillary Hartley published a Digital Action Plan which was explicit in its ambition to scale their citizen-centric service design work across government and over time. This paid off after the recent change in political administration, after which Hillary was given a much broader mandate, including running Service Ontario, the home to many of the largest public services.

Political leaders are starting to get it

Several teams I met at Harvard said a similar thing: their political masters (not just the mandate-providers) are beginning to grasp the potential for internet-era delivery in government.

They’re starting to understand that it doesn’t just mean new technologies and new user-centred services. It also means a lot of new ways of working (new for government, at least) and new ways of governing. More leaders are thinking about funding teams not projects, about working iteratively, and about shifting away from rigid hierarchies towards networks of multi-disciplinary teams.

This is the thing that excites me most, I think. Changing senior minds to not just understand the impact of the internet era, but also to accept it and embrace it, is a long, slow uphill battle.

But that change is happening. It’s slow, but it’s happening. Imagine what things will be like in a few years, when there are people leading departments (and perhaps people leading countries) who have embraced that idea and fully support it. Imagine what supportive mandates from people like that will help us achieve.



Leading from the Front: on Single Domains, Spending Controls and Service Standards

By Emma Gawen describes itself as “the best place to find government services and information” in the UK. It has won awards, has been viewed more than 14 billion times since going live, and has influenced governments from Israel to Peru to Kazakhstan.

It’s the original, classic example of what we call a “single domain”—one website that represents and embodies all of government, from the user’s perspective, in one place.

If you’re looking for a whole-government, greenfield project which will build momentum, Internet-era skills and teams, then there is often no better place to start than a single domain.

But: creating a single domain is also hard, and contentious.

You only need to take a look at Australia’s fallen GOV.AU beta and the cancelled initiative to see some of the pitfalls. And for every fan of GOV.UK I’ve met, I meet another that says ‘that’s definitely not for us’.

When we met in Harvard, we used a spectrogram exercise to ask the group if a single domain should be central to delivery of digital transformation in government. We asked the group to physically place themselves on an axis across the room, where one end of the line represents ‘strongly agree’ and the other ‘strongly disagree’. And we got views back right across the spectrum. People had strong views about both ends.

For those of us that are already on the journey, most notably GOV.UK and GOB.MX, the benefits are easy to see. We’ve been able to make life simpler for citizens, and at the same time turn other things off. By creating platforms for departments to use, they are able to focus their teams on their core services: welfare, education, unemployment, health.

In some places, the timing and political context isn’t right. The political capital is simply better spent elsewhere.

Others say that websites and government information aren’t the problem at all, that we should be focusing on services, building APIs to connect them, and tackling legacy systems.

It’s true that these are much harder problems to solve. However, that’s also why they are a bad place to start: before long you’ve spent a year negotiating requirements with 5 suppliers with a decade long contract and time on their hands.

The strongest counter argument was that you can go far with a mandate to challenge cross government technology spending (in the UK, we called this spend controls), a service standard and assessments and a good digital team to support them.

What these two strategies (single domain and spend controls) have in common is that they allow a team to lead and gather momentum from the centre. They also both require a high level of political will. In the UK, we were lucky enough to implement both.

Single domains help build interdepartmental relationships, at scale.

You’ll need the expertise, help and support of leadership and delivery teams across government. You need to get agreement on how government information and services are presented; from how it’s ordered, how it’s written, to how big and prominent the pictures of your politicians are.

Even with a hard mandate, you need to get the relationships right to build good will, and learn what levers and incentives different teams respond to.

You’ll also need a governance structure and network of decision makers across government to make sure you have joint ownership and keep departments and agencies engaged.

Single domains test political will (in a good way).

As the examples of Canada and Australia show, initial political fanfare for your work does not mean it will survive the next political battle.

Departments and agencies, used to having control over their own brand and messaging, will not relinquish it lightly. While the delivery team can do a lot build support across government, the ultimate test is when a minister pushes for an exemption or for special treatment. If any exceptions are made or too many supporters lost, a single domain becomes too neutered to fulfil its purpose.

Delivering services fit for the Internet-era requires a level of cooperation and collaboration across departmental boundaries that has to have consistent, informed political support.

If you have trouble working across government to get consistency with words and branding, you’re going to have a lot more trouble with services.

Build an empowered multidisciplinary team, and learn how to grow it.

To deliver well, you’ll need a empowered, multi-disciplinary team. This means bringing in skills that most governments are not used to recruiting for: designers, user researchers, delivery managers, data scientists, developers. This will test how you find, hire and keep new people.

In the UK, the lessons learned from building the initial GOV.UK team were scaled to help departments build their own digital teams over time: moving on from small content teams that worked to deliver GOV.UK, to service teams like the digital team at the Ministry of Justice who are making public services better from the inside.

Put users first; put a team in charge of doing that.

What citizens want is access to the service they need, from a government they trust. Departments shouldn’t be building their own data centres, nor should they be worrying about websites anymore either. Taking a platform approach is more efficient, more secure and better for users.

Spend controls and service assessments are a strong and viable alternative way to lead digital transformation from the centre. In the best of all worlds, you’ll have both.

That’s not to say that a small digital team working on something specific like welfare can’t and shouldn’t deliver brilliant, Internet-era services for citizens. They can, they should, and they have the best domain knowledge to do so.

But if you want a whole government approach to digital transformation, you have to lead from the front.



Product Management in Government

By Kathy Pham

Senior Fellow and Adjunct Lecturer, Product Management, Harvard Kennedy School
Former Founding Product and Engineering Team Member, United States Digital Service; Product Manager, Google


During the June 2018 Digital Services convening of global digital service teams at the Kennedy School, many common themes emerged from our diverse experiences. We discussed how to find political cover, whether we should base teams out of a central or high-influence part of government, the benefits of a government wide single domain, the power and difficulty of planning for political change, putting users first, and how to empower multi-disciplinary teams. One very practical, team and delivery-focused theme was the need for more product managers in government.

What are product managers? In the private sector, product managers are at the intersection of business, tech, and user experience. They help manage legal, marketing, data, sales, finance, support, research, and almost every aspect of the business involved in getting a product or service to customers. They lead cross-functional teams for the success of a product, making sure what is built actually serves users and solves the problem it was intended to solve. But product management goes well beyond just keeping a project on track. It ensures that every piece of the product building lifecycle works together to build something that works, with outcomes that do not fail the users.

In government, the “Business” is serving all people who require government services, and the “Business” sometimes also involves trying to build a product to fit a policy. Our “customers” include people who either have already paid for services with taxes, as well as people who have no choice but to interact with the government for a service. They might be looking to file taxes, learn about colleges, understand their social security benefits, sponsor a relative into the United States or gain citizenship themselves, apply for healthcare or Veterans benefits, move around the military, and so much more. The software and digital products of the government deeply affect people’s lives and wellbeing. Failed services in the public sector can have dangerous consequences for human rights, social justice, and our ethical responsibilities as public servants.

There are many ways that digital products fail in government. One common reason is that government technologies rarely have one person who sees the creation of a product end to end, fiercely advocating and fighting for the people that the product will serve, and making sure all the people who are involved are building a product that works. As Kelly O’Connor and Chris Johnston write1, there are many project managers, people who are focused on managing schedule, budget, risk, policy compliance, and reporting status to stakeholders. Their success is to deliver on time and on budget. There are many cases where they can deliver software that does not work but deliver it on time and on budget. But what is still lacking in virtually all government departments is recognition that having project managers isn’t enough–we need product managers.

The government has a history of creating innovations and solutions that have been adopted by the private sector—the first electronic health records, countless NASA ideas, memory foam, scratch-less lenses, infant formula, and more. There is so much that the private sector can learn from government. However, when it comes to software development, the government has fallen behind. We need to change and adapt to respond to user needs, reflect the myriad ways people interact with their governments online and in person, and continuously build, test, and iterate with real people to ensure what we build works for all. Too often, the development process means a list of requirements is written by someone in one government agency and a separate team of contractors is deployed to build it. They might build it across 3-5 years without considering user feedback at all during the process and at the end of the project, the service could completely fail to work for people.

We need roles in government for people who think beyond just building to a list of initial requirements. We need product managers and leaders with a product mindset to make sure we keep iterating on requirements, find gaps in our knowledge, and continually improve. To this end, there’s some good news to share. Health and Human Services has taken a great first step by hiring its first ever Chief Product Officer in 2018. The United States Digital Service has full-time product managers deployed across the federal government. At the Harvard Kennedy School, we now offer a class for Product Management and Society that is teaching the next generation of government, public service, non-profit, and civic tech leaders about the importance of a product management perspective. This class complements many other product management courses, programs, and boot camps offered around the world. The class teaches product management fundamentals while weaving in broader societal topics like legal and regulatory considerations, human rights, accessibility, ethics, social responsibility, inequality, race, navigating with technology in public sector spaces, and procurement in government.

These are all small moves in the right direction, but they are not enough. We need more government agencies across the world to hire product managers, to build product thinking into other roles in government, and to hire product leaders and leaders with product mindsets to connect the technology with the people, the policy, and all the stakeholders involved to build technology services that work.

Many thanks to Hannah Masuga, Product Management and Society Course Assistant, and Ben McGuire, digital HKS Research Assistant, for their contributions and edits.

[1] Johnston, Chris. O’Connor, Kelly. (August 23, 2018)…



Digital Services Collaboration Creates Shared Value

By Yolanda Martínez Mancilla

National Digital Strategy Coordinator, Mexico


Participating at Harvard Digital Services Convening was an amazing experience. As a public servant, I always encourage the participation and international collaboration with other digital service teams, and having the opportunity to collaborate, learned and share with other government officials, young academics and researchers was very fulfilling. From the National Digital Strategy of Mexico, the digitalization of services has changed the way citizens interact with their government, we look forward to continue with this effort and this Harvard reunion gave us the certainty that we are going in the right path.



The End of the Beginning of Digital Service Units

By David Eaves


We are at an interesting time for digital service units. One the one hand, the novelty and newness of these teams has worn off; on the other hand, there is growing acceptance by many governments that these teams are useful tool in driving new practices, particularly agile development processes and user centric design. Less clear, but still a possibility, is the key question of whether these units can enable the deeper digital transformation that will prompt a fundamental rethink in how technology could re-shape governments for the 21st century.

At the project level we’ve seen some very promising successes. While at the enterprise level—trying to answer the key question about deeper digital transformation— there are few dramatic results. So, on the whole, no unqualified successes, but given the magnitude of the task and the size of the governments this is a tall ask. And, to counter, few failures and lots of tactical wins.

Equally important, a lot has been learned. So much so that we now stand at the end of the beginning for digital services units. The end of the beginning, because a rough consensus around a “north star” and general tactics has emerged. And not the end, as we are both far from the end of the journey and have earned ample license to carry on.

Some background

Since the founding of the UK Government Digital Service in 2011, the number of digital service groups—teams of digital experts, often drawn from the commercial tech industry and combined with in house government talent, and tasked with “digitizing” government—has exploded. Today Peru, Argentina, United States, Mexico, Canada, Italy and Australia are just a few of the countries with such units, joining the ranks of long-evolving government technology programs in pioneers like Estonia, Israel and Singapore. In addition, a growing number of sub-national actors, such California, Ontario and Georgia also boast these teams. In the US, the United States Digital Service (USDS) has led projects across federal bureaucracies and produced public resources like the Digital Services Playbook, College Scorecard, and TechFAR Handbook. It is now training a new generation of digitally oriented procurement officers on technology procurement practices.

Where we are today

In short, as a form of both organizations and a theory of driving change, digital service groups are a relatively mature. Maybe not a mature practice, but certainly a mature experiment by this time.

We’re no longer in a development phase when digital services has to prove its need to exist in the first place; in most jurisdictions political awareness of the need to improve the delivery of online services is real. And in some (but hardly all) jurisdictions, public servants see the value in improved technology infrastructure and access. The model of digital service units has, for both good and ill, earned enough political capital to be given some runway and to continue the work that they do.

Equally important, two key pieces of the puzzle seem to have become clear. The first is a “North Star” to guide digital service teams on their journey. Specifically, whether they can build them today or not, creating or acquiring a core government platform (e.g., single sign on, payments, identity) is the end game most digital teams know they need to get to. Some digital service groups are able to work on these already. Others are too busy with specific projects, putting out fires, and or building credibility or capacity to engage in this work. However, creating common platforms to power governments services is key to digital transformation over the long term. If groups cannot work on it today, there is an emerging consensus that they should create the political capital and conditions, to enable them to steer towards this outcome.

The second piece of the puzzle has been validation that using an agile process to start with, and focus on, users is the among the most effective tactics for achieving short term success. Whether it is rolling out a new digital application for health care at Veterans Affairs or making it easier to assign power of attorney in the UK, user-centered projects yield real and tangible benefits for users and huge political value for elected officials. Focusing on users also serves as a way to cleave through bureaucracy and force divergent interests to adhere to a common goal.

This emerging consensus—steer towards building common platforms tools while using the focus on user needs to power you through projects on the way there—is helpful. It gives people a shared roadmap and common language and frameworks that transcend jurisdictions.


Interestingly, these two trends mentioned above can be in competition. Focusing on the user’s satisfaction against all other goals can turn digital services groups into web design shops that roll out functional and pretty websites—but accomplish little in the way of deeper transformation, particularly in underlying legacy systems. On the opposite end of the spectrum, focusing exclusively on building platform services can be hard to pull off without real needs and users to validate against. More importantly, not working on complete services cause units to not demonstrate short-term tangible benefits to citizens (and therefore their elected officials).

The other common challenge among many digital units we talk to is in how they negotiate for buy-in within their own bureaucratic context. Some have been granted (or grabbed) as much power and authority as possible to control digital projects across government. In some cases, this paid off. It can enforce standards and practices and prevent large, poorly designed projects that confuse and frustrate users, and prevent digital services from getting off the ground in the first place. It also often creates major political challenges. Those whose projects are killed or whose practices must adapt can become competitors and even opponents within the government.

Other teams focus on gently cajoling government partners and organizations to go along; they upsell the potential savings of a website redesign, trumpet the happiness of core users when they interact with new tools, and home in on how shared services allow more differentiated value. Building consensus can be great, but it can also take time, and without enforcement mechanisms may ultimately prove to weak to prompt an enterprise-wide shift.

And of course, while digital service groups may be mature experiments, surviving transitions in government is always a critical challenge. Ensuring there is multi-party support and that there is continuity even as administrations change—like the work of most public servants—is essential.

If This is the End of the Beginning, What’s Next?

The exciting part about being at the end of the beginning is that the model of digital service units has been sufficiently validated that more and more governments will likely experiment with them over the coming 5 years. In addition, these new groups will benefit from a clearer roadmap and lessons learned from those who came before.

In addition, I suspect that expectations have been more appropriately calibrated. For better or for worse, political masters now expect incremental wins on a project by project basis—not enterprise transformation.

So what’s next? In the short term the north star and tactics outlined above answer that question. Continue to deliver value on projects, drive agile methodologies and user focused approaches while nudging towards platform services. The key is to maintain or build political capital—or what my colleague Mark Moore refers to as capacity for authority—to prepare for the next phase.

Because, as hard as it is to believe, today is likely the easiest part of the journey. Behind us is the hard part of starting up. Today is about building capital and capacity. What’s next in the mid term…? A long, slow battle over what the structure and shape of government will look like. And making progress on that I fear will be infinitely more difficult and painful than improving services on a project by project basis.

For more information on this publication: Please contact the Belfer Communications Office
For Academic Citation: Eaves, David and Ben McGuire. “2018 State of Digital Transformation.” Belfer Center for Science and International Affairs, Harvard Kennedy School, October 2018.