Outcomes, goals and objectives

In my experience the best leaders are crystal clear about outcomes and focus their energies on achieving them. They’ll communicate goals and objectives to steer and inspire their teams but they don’t sweat the deliverables.

This is how I think about them.

goals-outcomes-objectives-deliverable.jpeg

Governance - there is a better way

Teams using lean and agile ways of working often rub up against traditional modes of governance which can slow them down or demoralise them.  Governance can become a blocker.  I drew this picture describing how that can feel..

Hierarchies and imposed structures, designed to simplify and streamline management become process overhead that disempower teams.  The forums used to make decisions become distant, far removed from the reality of delivery.  Teams often feel the pressure of delivering to please their sponsors rather than their users. Governance becomes an industry and the currency of success becomes dates, deliverables and documents.

Instead, organisations wishing to embrace lean and agile ways of working should promote governance structures and behaviours that:

  • Focus on outcomes, not deliverables - because truly understanding and driving towards an outcome (e.g. something starting/stopping/continuing, people feeling different, changes of behaviour) is much more valuable than focusing on the delivery of a thing (an artefact, a feature, a system) that might, you guess, produce an outcome.  Focus on the change you desire, not on delivery of the bet you’ve placed. Unlearn the muscle-memory of caring most about dates and deliverables.

  • Measure the right things at the right time - agree how you’ll measure an outcome but also recognise that there’s a context for what’s meaningful to measure at any given time.  That a new product can successfully meet the core needs of 10 users is very meaningful in the beginning and that should be an organisation’s initial focus; be patient before you pile on the pressure to measure % uplift in sales or efficiency.  Be careful what you pick to measure and when to avoid unintended behaviours.

  • Ensure teams are the units of delivery - trust in multidisciplinary teams and let them get on with it.  Build a team, not a big up front plan. If you’ve communicated the right problem to solve to a team that are invested in solving it, with the right support around them, you will all have a higher chance of succeeding.  Good teams, with the right mix of skills and experience, figure it out.  Good teams fail when you give them a solution, a date, the name for the thing… and tell them how to do it.  People over process.

  • Establish networks of teams not hierarchies - because as soon as an organisation pre-determines a structure to deliver a thing they've exercised an upfront bias towards a particular solution.  Over engineered programme-level hierarchies produce noise; noise slows down self-organising, motivated teams.  By all means design and promote the glue between teams but do it organically, with teams not to them. Think about designing a supportive network, not inflicting unnecessary hierarchy and decision makers or forums.

  • Make quality everyone’s responsibility - because everyone involved needs to understand what good looks like and is responsible for delivering that. Don’t make quality assurance a ‘gate’, title or a role. Make it part of what a teams does every day.  Bake it into the way a team works and thinks.

  • Assure as you go - because using iterative ways of working and effective feedback loops gives an organisation regular opportunities to check that the right work is being done in the right way.  Try to avoid making assurance activity scary, lumpy or as a bolt on.

  • Remember that behaviours matter more than documents - because by regularly observing team behaviours (e.g. how they collaborate, communicate, validate their assumptions, seek feedback, measure impact, deliver, learn — is way more valuable than warm-fuzzies and false certainty of documented proof.  Go see delivery.  Witness running code and listen to feedback from actual users.

Fieldnote:

When I share this list with senior people their normal response is “it makes sense; it’s kinda what we do anyway”.  That’s always good to hear but I’ve learned that’s rarely the case.  For example, when I hear these things I know there’s a whiff:

“When’s the  x delivered?”

“This team sits in the x programme in the y work stream”

“We need to get Programme/Strategy/Ops/Security/Data board to sign it off”

etc.

In and of themselves each of these are innocent enough but they can add up to something significant.  They are the tells of how an organisation thinks about agility, risk, org structure (read: silos) and team empowerment. Maybe there’s another blog post in that.

*thank you to Ella and Amy who helped me structure my thoughts in the original, longer version of this post on Co-op’s blog.  I didn’t say that in that post so it worth saying here. 🙏

On leaving the Civil Service

Last week I left Government Digital Service and I'm now no longer a Civil Servant.  I had great fun so I thought I'd capture my highlights and share some pictures that sum it up for me.

Here's the things I enjoyed most:

1). Building and being part of the team that launched GOV.UK - from a blank sheet of paper through to 1 billion visits and a £60m saving for UK tax payers each year. I had so much fun disrupting the status quo, helping to establish an agile service delivery culture across government. Agile is now the new normal for service delivery in government and that's a little bit to do with starting the alpha version of GOV.UK, forming an incredible team that showed the art of the possible and which exemplified a culture of delivery.

2). I'm proud of the part I played helping reset Universal Credit, the UK's welfare reform programme. It's a sensible policy, with cross-party buy-in but it was in a bit of pickle in 2012/13. I helped form the cross departmental, multi-disciplinary team that will deliver a future welfare system, designed to be fairer, a little more human, a lot more agile and responsive to feedback from users. That's totally a win for the Civil Service and the UK - against many odds.

3). Getting to work on briefs like this - and I'm paraphrasing: "Imagine it's 10 years from now...  Without messing with democracy ('cos we like that), how would you build a natively digital state ('cos the current system is mostly 19th Century!) and make services so simple..?". Such fun was had, working with some of the most incredible minds. I learned so much and once seen it cannot be unseen.

4). At times I was shocked at the sheer bonkers-ness of it all but also there were many moments of awe. Seeing the system of government up close was fascinating and never again will the news headlines read the same. There's things I'd change but there is a lot to be thankful about our system of government and its administration. I loved walking into my local pub and playing up the jibes about paperclips and civil servants, but the truth is it is packed with talented, public spirited, hard working people. Properly talented. We are lucky people, us Britishers.