Setting a team up to fail

No one likes to fail. Many do, but few set out to. Failure is particularly problematic in the public sector, because it can lead to fears that hardworking taxpayers’ money is being wasted.

Despite knowing all that, I set a small team up to fail this week. Their brief is to spend a month creating a prototype. The team will succeed if:

  1. The service is digital end to end and delivers a viable business process
  2. The service is so good that people prefer to use it
  3. The service supports our other projects, but is distinct from it
  4. The service, if developed further, would reduce dependence on our existing systems
  5. We learn more about what our customers need from a CRM and customer portal and the time it takes us to build a service

That’s a big ask from a small team, and with just a month to do it. That’s important. We can’t set up a whole service to fail – that would be irresponsible. But a small team working for just a month can learn, and then teach, much more than a larger team working for longer. And at lower cost and lower risk.

I told the team I expected them not to achieve all of those things. They asked if I was managing expectations. I wasn’t. In fact, it’s particularly important to me that they don’t get it all right first time. I want the team to be bold. They need to aim high and make mistakes. It’s only by learning what’s wrong, that they’ll find what’s right.

The team asked me what we’ll do with the prototype. I said we’d likely put it in the bin. Whilst my fee as a motivational speaker may have fallen significantly, it was another risk worth taking. The team has spent years working to produce ‘finished products’. We previously had a simple choice between meeting deadlines and suggesting it was good enough or missing them and waiting until the product was ‘done’. That is precisely the approach that we need to change if we are to be better able to meet the needs of our residents and the aspirations of our colleagues.

The team will be able to draw on the tactics manual that we’ve pulled together, based on the experiences of Government Digital Service, 18F and Google Ventures, amongst others. And it’s work will help us understand a user-centred, Agile methodology. So the act of doing the work will be successful, regardless of the product we create, and will teach us far more in the long run than training courses. In fact, we will win whatever the outcome.
So whilst I’ll be willing them on, mostly I’m crossing my fingers and giving them the space to try their best, be bold enough to get things wrong and brave enough to learn that, done right, an Agile approach can deliver enough failures to produce a more successful outcome.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.