A Public Servant’s Perspective: Applying Digital in a Nondigital Landscape
Authors: Sechi Kailasa, Master of Public Administration, 2022
The word nondigital is used in this article. This isn’t intended to be a negative phrase but rather indicates that digital ways of working have not yet fully extended into every context.
This year was the first time we had a panel at the convening consisting solely of public servants who weren’t or hadn’t been based within digital service teams. Alongside myself, we were joined by colleagues from Madagascar and Canada to explore the following questions: What does it feel like to be a public servant interacting with digital service teams, their processes, standards, and ways of working? Do digital service teams attempt to understand such perspectives? Digital service teams tend to think about citizens as their end users. However, internal users are also a key end user group as they are responsible for driving an organization’s digital transformation, therefore it seems critical that they should take them into account.
This article is based on my experience of being a civil servant in the UK government. It offers one narrative of experiencing the services of a central digital service team, and therefore you need to be careful about what you extrapolate. However, the experience hopefully offers an opportunity to reflect on your own context. I was based in a home department in the government, in the UK this means you’re not part of the central government. I was in the IT function, on a graduate leadership program, and had two main roles. One involved functioning as an IT project manager, and the second involved contributing to the product management of the service we were building. We were a small project that fell under the threshold required for a project to undertake centralized GDS assessments. We wanted to be nimble and agile and aimed to go into private beta within 15 weeks, we hired a vendor to build the service. Importantly, while we were not a GDS project, we still needed to pass internal GDS style assessments and ensure we met GDS spend control requirements, both of which required us to meet the Service Standard (set by the central digital team GDS).
There are different ways to work with a central digital service team; we were using its “manual”
In many ways, working on the project felt like experiencing government at its very best; it involved a multidisciplinary team, collaboration between policy and implementation (no silos), and a highly trusting relationship between all team members and the vendor. However, there were certain aspects of the project that, looking back, offer some insight into potential ways that central digital teams can improve their work’s impact. The project was not an official GDS project — technically, we were trying to navigate the system simply based on the documentation that GDS issues — so their processes, protocols, and standards. Unlike some of my other fellow panelists who were working more directly with their digital service groups and were provided central team resources, we were essentially using the manual.
The journey at times felt like you had to “two” bosses
We had to follow both the GDS processes, for example, spend control and the internal protocols specific to the home department. The two processes at times felt like two very different forms of compliance. While we tended to receive a positive and receptive reception from one, the GDS, the internal IT function didn’t necessarily agree that we met all the requirements we needed. It’s important to note here that it’s not always the case that the internal IT requirements were unreasonable; for example, the IT function could have a high security threshold due to the nature of projects under its remit. However, we didn’t fall into this category because we were a small, low-risk project; the department didn’t really have a place for projects such as this within its organization structure, so we had to comply with the forms of compliance of where we were placed. This demonstrated that as far as digital teams have come, there is still a way to go in terms of creating a space for working in this way beyond the central digital teams themselves.
Digital teams often say that they’re trying to help you, but only holding this perspective tends to overlook the high burden on the public servant who is trying to meet two processes at once and trying to apply digital ways of working in a as of yet nondigital, risk-averse, culture. As a result, the digital team’s processes almost became additional hurdles we had to meet on top of everything else — which, even if we devoted time to, didn’t make the other processes easier. One strategy to overcome this could involve first thinking through and mapping out whether the two processes are complimenting each other (the central digital team’s process and the department’s), figure out where the pain points are, and determine how they can be alleviated — what needs to change, be put in place, or removed because it’s redundant.
Central digital teams should provide more tools for public servants trying to apply digital ways of working in nondigital environments
When we were trying to be an agile project, there were several tools that could have really helped us along the way if there were examples that we could draw upon, for example, an agile business case. Currently, it is difficult to build a standard business case (which requires high amounts of certainty upfront) for an agile project as you start with many unknowns. In the initial few months, a business case can be iterated as more information is discerned from user testing. However, it would have been useful to have seen a blog about this and how other projects have handled this — going beyond just the guidance currently offered on the GOV.UK website.
“Digital” is not yet pervasive, and there is still work to do
Unlike in the article below, digital culture wasn’t pervasive, and we still had to raise awareness of agile and have conversations with colleagues. This should not dissuade from the tremendous amount of progress that has been made to date — digital teams such as the GDS in the UK have changed the way the government functions, accepted ways of working, and, importantly, the expectations of internal and external users. However, there is still much work to do to translate digital ways of working and agile into the wider government. One important strategy could be to focus on improving the services offered to public servants.
Public servants must be considered as a key user group
It was clear from this experience and the panel at this year’s convening that public servants are critical consumers of digital service units, and we must think about them much more than we perhaps currently do. The following are suggestions for potential strategies that could be adopted:
● Digital service teams could ask public servants for feedback.
● Pushing “out” digital ways of working via creating service standards, working in the open, and creating digital academies aren’t the only strategies that should be employed to raise awareness. Considering the public servant’s point of view and the barriers they face when actually implementing these ways of working could be a key way to ensure digital’s impact is far-reaching.
● Digital teams could create a playbook for public servants attempting to practice digital ways of working which could include topics such as how to overcome common hurdles.
There needs to be a space and approach to hear the concerns of public servants who are using these processes, feel things aren’t going smoothly, and feel like they’re trying to navigate a as of yet nondigital culture. Digital service teams have an important role to play in creating this space and approach.
