Of all the GDS governance principles for service delivery, the one I probably repeat most often is “Trust and verify”. As written it’s directed at managers—it’s to ensure they give the team more freedom (“trust”), but to also to let them know they can still have some assurance (“verify”). Yet despite the positioning towards managers there is also an important underlying responsibility for the team, which they (the team) need to acknowledge.

The responsibility for those in the team is this: in order to justify the trust we need to be verifiable. In other words, we need to be set ourselves up so that those on the outside are able to verify what we do.

I’ve known a small number of teams in the past who use the concept of trust, or the introduction of Agile, to hide their activity. If someone asked them for insight into what they were doing, or how they reached certain decisions, they would respond with an innocent-sounding, but threatening, “Don’t you trust us?”

But being verifiable is not just a passive act, and it’s not just about being transparent—it’s not something we just sit back and allow. Often we need to take active steps to be verifiable. Here are some examples:

• Recording our decisions, and making those meeting minutes or notes accessible.
• Making our architecture clear, so that others can verify its strategic fit or security implications.
• Being clear about the work we’ve planned and the work we’ve achieved, and making that progress visible and meaningful.
• Opening up our code, so that others can scrutinise it freely.
• Taking regular time to demonstrate our progress, and making sure the right people are there.
• Taking time to answer questions from stakeholders, and providing answers in a way that’s relevant to them.

Trust is something that can be given; but if we want it to be built and sustained then we must ensure our work is verifiable.

Photo by Lars Plougmann