Over five years, our team at IBM worked in partnership with the Disclosure and Barring Service to build a digital capability from scratch. We started with no agile experience, no digital delivery function, and a paper-based process that frustrated citizens and cost the organisation time and money.

By the end, the DBS Basic Check was recognised as a top 50 Gov.UK digital service. Customer satisfaction rose from 68% to 80%. Transactions doubled what was forecast in month one. The team won a UK Customer Service Excellence Award and became finalists for the MCA Consulting Award for Performance Improvement in the Public Sector.

Here are the five lessons I would take from that experience and apply to any government digital service build.

1. Create a real partnership by building a high-performing team

The biggest determinant of success was not the technology. It was the people and how they worked together.

We brought together professionals from different organisations, cultures, and geographies. Getting that right meant focusing on aptitude and attitude over certification. Skills can be taught. The right mindset and cultural fit cannot.

We reduced the number of requirements and instead rallied around a single, simply articulated objective that everyone could use to make decisions. When a developer, a user researcher, and a product owner all understand the same goal, you do not need layers of governance to keep things on track.

Barry Topham, the DBS Executive Director for Technology, put it well: “The IBM team integrates seamlessly with our own DBS digital colleagues so efforts are focused on productivity and progress rather than management and administration.”

2. Embrace agile, and sell it to the organisation

A user-oriented DevOps approach is the right way to build digital web services. But creating the space for agile inside an organisation that has never used it is a political challenge as much as a technical one.

We learnt to protect the agile team’s ceremonies and tooling from external governance demands, while still acknowledging the organisation’s need for visibility and control. That meant using people who understood both worlds to translate and report status for wider stakeholder groups.

Most importantly, we invested significant energy in broadcasting successes. Every sprint demo, every user research insight, every deployment was an opportunity to build confidence in the approach. Selling agile to decision-makers is crucial to the long-term success of any digital delivery capability.

3. Set up your workspace and tooling to succeed

The choice of tooling matters more than people think. Modern software engineering should embrace a secure open-source approach. It ensures the latest thinking is always available and avoids vendor lock-in.

We chose tools based on three criteria: the vendor’s ability to keep up with market changes, their commitment to meeting government security standards, and their ability to scale with the team’s ambition. Developer preference was important but secondary to these fundamentals.

A single platform to manage delivery is critical. All management information should flow through one tool. It should provide a simple, single source of truth with appropriate access for all stakeholders. The right tooling enables experimentation. It gives teams a space to collaborate, safely iterate, and transparently track changes so their impact can be measured.

4. Trust the person

This is the hardest lesson for large organisations. Delegate authority to the right decision-maker. Remove unnecessary hierarchy. Get the right leader in place and then trust them.

We learnt that empowering people at the right level creates speed and ownership. Giving a developer the authority to make a technical decision, or giving a product owner the authority to prioritise the backlog, means decisions happen where the knowledge is. It requires trust going up and down the chain, and that trust is built over time through demonstrable competence and joint endeavour.

Diversity in team makeup matters here too. When you are building citizen-facing services, having a team that reflects the diversity of the population you are serving leads to better design decisions.

5. Scale at the right time

Do not scale before you have proved the model works. Establish early wins. Teach the organisation that the approach delivers. Get buy-in. Then scale at pace.

We also learnt that joining a high-performing team is hard. When we did scale, we invested heavily in onboarding through cross-pollination of ideas, lunch-and-learns, social events, and pairing new joiners with experienced team members.

We built on the existing technology stack rather than duplicating. But we were careful about technical debt. It needs to be proportional, because it is amplified with each additional service using that codebase.

And we tried to keep hold of the bootstrap mentality throughout. Do not let perfect be the enemy of good enough.

In summary

Underpinning everything was a strong partnership founded on trust. Trust that the people involved were all sincerely working towards the same objective. That trust was built over time, through demonstrable competence, effort, and joint endeavour. The agile relationships, the management information provided by good tooling, and the open conversations between professional people empowered senior leadership to delegate authority with confidence.

Having the right people making the right decisions at the right level is what creates the winning culture needed for high-performance digital delivery.