So, I became a policy person in charge of a digital service, and this is what I learned

The new grant funding service that I lead on successfully launched to its private beta users on May 2, and within 15 minutes the first successful transaction had been completed. So, how did we get there and what did I learn?

Luck

It would be foolish to say there wasn’t a huge element of luck to enable the service to launch. Luck that I work in a policy and delivery team that is highly digitally literate and has vast experience of successfully delivering services at scale. Luck that my line manager (Sarah Fisher) expertly supported me and always offered pragmatic and sensible guidance at every step. Luck that all the other senior leaders were so encouraging, cognisant of digital and agile delivery and always backed me and the team. Luck that the team who worked on the discovery and alpha had created such an organised handover of artefacts and were still around to provide support. And finally, luck that most of the contractors hired were so professional, diligent, and committed to launching the best version of the service in the given time frame.

Decision making

Being the service lead in a hybrid policy and product manager role, involved making decisions, and lots of them. In the 8 months between starting the role and launching the service, I had to get comfortable with making many decisions. In the final days before launch, it felt like I was making more decisions than I had ever done in the entirety of my policy career.

This experience has taught me that to lead successfully you have to be comfortable and confident in making decisions and outlining your rationale, particularly if they are seen to be controversial or don’t receive full (or even any!) team support. I also think, where possible, decisions need to be made in the team environment and only decisions that require additional approval, i.e., from senior leadership should be taken offline and made without sight of the team. This way the team will (hopefully) always feel fully involved and invested in the service and know that their input is always required and valued, if not always heeded.

Getting it wrong

I also had to become very comfortable with knowing that not every decision I made was correct, and often it felt as though there was no clear answer. On reflection, there were many decisions I could and probably should have done differently. But, as almost every piece of literature on agile working details, you must get comfortable with failing fast — by testing your assumptions and designs as quickly as possible, getting feedback on them, and then iterating. This is very different to the culture in policy, where aiming to get things right the first time is the norm.

Having difficult conversations

In the ten years I have worked in the civil service and for a non-departmental public body I have noticed that having difficult conversations, particularly with team members is a rarity. Managers often feel there is no perceived benefit and the risk of receiving a complaint or a grievance always weighs heavily. This can’t be the case when leading an agile multi-disciplinary team composed of both permanent civil servants and contractors hired through agencies. Difficult conversations need to be had, and quite often. There are often ways of working clashes between team members, which sometime require candid, but open, conversations. Additionally, not every contractor who joins the team will be the right fit, and this involves having both difficult conversations with them and their agency so they can be replaced. However, this needs to be done, because having even one underperforming team member can and will derail an entire service and blow-up even the most well thought through delivery plan. Of course, the same is true of civil servants, however managing them is a very different process and would require a whole separate blog.

Lessons learned

Throughout this process, I have learnt many different things about digital delivery and myself: from how to write simple SQL queries and understanding the use of Markdown in GOV.UK content to becoming more confident in saying no and questioning the rationale and logic of other people’s ideas and decisions, as well as having my ideas challenged! However, my main takeaway is that the service is only as good as the team designing and building it, and I’ve been very lucky (again!) that this service’s team is the best that I have ever worked with.