Beyond the service manual: leadership without governance

by Duncan Brown and Sarah Fisher

Congratulations! You, a Deputy Director in a Government department, have become responsible for a digital delivery project that is big, complicated, risky and potentially transformative. You don’t understand exactly how it works, but you know that it is important. And you’re well-versed in the political and policy landscape in which this service operates.

This project will materially affect outcomes for the public good in your area—outcomes for which you are accountable. It will generate data which could change the Department’s understanding of the issues. And if it fails it will probably attract headlines.

How will you lead?

It is tempting to envelop the project in a scaffold of governance. You might establish a new Project or Programme Board to oversee key decisions and discuss impending risks.

We have bad news

Boards are not an effective way to lead delivery teams.

Boards have the wrong cadence. Delivery teams make decisions constantly, and most decisions have a short shelf life. If you choke off all major decision making to a board meeting once a month, one of two things will happen. Your product could wither because the team is waiting for you to decide. Or more likely, the team will happily make decisions without you.

Boards are unlikely to provide appropriate oversight. Say your team needs to decide whether to go live with an important feature. They have a month-long window during which all the service users will be logging in and updating their content. But deadlines are tight and they might not make it. Perhaps they could collect the information some other way—but the trade-offs will have deep roots in the technology of your service. Who is best placed to make this decision?

Boards have insufficient bandwidth. If you are used to making decisions on the basis of a verbal update and a statistical summary, the difference in depth of context when working with a digital service is the difference between a puddle and a lake. Digital teams have continuous quantitative and quantitative feedback loops running through user research, data and analytics. Asking boards to acquire this context is unfeasible and unfair.

Finally, boards are liable to become governance theatre — rubber stamps on decisions that have already been made. This matters because that role is made possible by a host of other processes that do the actual checking and deciding and understanding. The way your service team works is not guaranteed to be compatible with many of those processes. The existence of a board will not change that. In fact, this veneer of governance might ensure your service gets no oversight at all.

More governance = less oversight

If they feel that you’re not able to make a proper decision, your team will manage upwards, creating a narrative that discourages interference and shows them in a favourable light.

Boards are the perfect forum for this. They enable and incentivise teams to construct a version of themselves that is palatable to the rest of the organisation. With a sprinkle of glamorous technical complexity, they will happily present as risk-light, super-effective and offering excellent value for money. But the real work of the team will lie beyond the board’s control.

And from the perspective of a team which is inclined to work in a silo—perhaps they lack the skills to properly engage with policy, or perhaps they simply don’t see the value in existing governance structures—a board presents a good opportunity to appear collegiate.

These perverse incentives mean that unless you actively engage with the team on what oversight is proportionate and appropriate, you could end up with a board that is in nobody’s best interests, simply because each of you wrongly believes it’s the other’s preference.

What else could we do

The service manual contains a lot of well-intentioned advice about governance, such as “Going to see for yourself, and looking at data that delivery teams are already using to manage delivery, should give you the information you need to govern… Governance should be simple and supportive”.

In the face of embedded organisational structures, this advice is hopelessly facile.

For inspiration for how governance can work in practice, we suggest looking at smaller-scale processes that teams use and value. For example, compare the above account of a board-led process with a typical incident management process, where team members first assemble at short notice to fix a service that has gone down, and later gather to reflect on lessons learned.

Incident management is ad hoc – it happens when it needs to. In the form of incident retros, it provides actual oversight from people who understand the issues and can make concrete recommendations. The scope of incident meetings is well defined, and the expectations are clear. They have actionable outcomes in the form of remedial actions and monitoring, and their documentation is useful for future incidents.

It would be absurd to determine an incident’s next steps from a board report, because decisions made by people with more expertise and more context are better decisions.

The logical conclusion is that if you want to be making decisions, you need to be a member of the team.

But there’s only one of you

You are responsible for multiple teams.

Asking for a different approach to governance can sound like special pleading for digital teams. And it’s true that when you are continually releasing code, reporting to a project board is uniquely placed to slow you down. But much of the above can and should apply to policy teams as well.

Still, your response might well be that you still need boards. You won’t have time to understand the detail. Your leadership team will have to present you with the information you ask them for, and then you will have to make your decisions as best you can.

We invite you to reimagine your role.

Your rank means that you can range across multiple services. In many cases you will be the key—indeed, the only—point for co-ordination between them.

And insofar as you help your teams manage risk and make major policy decisions (“When do we turn off this legacy service?” “Do we want to push through this reform?” “Do we push forward with this service or do we abandon it?”), you are not their manager. You are their colleague.

There’s a lot of context to gain, but as a leader you have the right to demand help from your teams when it comes to helping you understand their work. Be in the same places as them, on the same slack channels, and in the same office when you can. Go to their meetings from time to time. Ask questions about their data.

And if you don’t know what “the API” is, have them explain it to you until you understand.