Conditions for success

Public Digital asked me to contribute to their periodical Signals and I’m reposting here. It’s about how to create the conditions for teams to successfully deliver modern, digital services.

Signals-summer-2019

Designing and operating modern, internet-era services is different from what you might be used to, but it’s not rocket science. It’s the application of a few simple principles, a simple flow of work and some tweaked behaviours.  If you’re a leader thinking of doing service design for the first time, these are some of the things you can do to increase your chances of success.

Empower teams by giving them problems to solve

Resist the temptation to jump to guessed solutions. It’s important to openly acknowledge that understanding the problems to solve, especially those of the user, is the place to start. By better understanding challenges, opportunities and the needs of users you increase the chances of delivering the right thing.

Set up a small, 100% dedicated, cross-disciplinary team with the relevant expertise to explore a problem space for 3-5 weeks. Direct their efforts on an area of opportunity that has potential to deliver on your strategy, but where the edges are unclear.

Investing in discovery activities like this saves wasted effort later on and creates the beginnings of an inspired, empowered team, committed to solving a problem with a habit for learning.

Test your riskiest assumptions by building working prototypes

Explore the art of the possible by building a working prototype (an ‘alpha’) and testing it with potential users. It is a quick and effective way to test your riskiest assumptions and better understand the needs of the user. The value of learning is in reducing the risk of prematurely committing resources to delivering the wrong thing or making incorrect assumptions that prove costly.

Don’t build an app, build a team

Empower a team to meet the needs of the user.  Make sure they can do this free from the imposition of political constraints to avoid building a product or service that suboptimally reflects the shape or behaviours of the current organisation.

Trust the team to own their process and choose the tools they wish to work with. Support them to shape their working environment in ways they want. There is no simpler, more powerful way for a leader to signal empowerment than by allowing a team to break some long-standing but innocuous rules.

During an alpha it is important the team can demonstrate they work well together and that they’ve understood and sufficiently explored complex areas of the service (e.g. security, legal, identity) – not just a shiny new interface.

Embed the change where you want to see it happen

An essential measure of success is landing new ways of working into the organisation. You can vastly increase the chances of that happening by co-locating a 100% dedicated, cross-disciplinary team where you want to see the change happen.

By the end of an alpha, the team will need to generate sufficient political momentum to surmount the internal barriers to the service going live (usually as ‘beta’).

Quickly put a real service live in front of real users

Everyone should expect the ‘beta’ service to be put in front of users quickly – say within a month or so. It won’t be complete but it will be the beginning, a thin slice, of a real service with real users. For organisations not used to working this way this is an important psychological hurdle to overcome, and a condition for success for delivering modern, internet-era services.

Deliver incrementally and iteratively

Ensure the approach to delivering the service remains incremental and iterative, driven by desired outcomes rather than a fixed plan. Allow the team to experiment with both the service design and how the service is operated.

It doesn’t matter how big or complex the imagined future service is, break it down into smaller parts and build in short, timely feedback loops.  Learning this habit and way of working will help you build a service that better meets the needs of end users and front line workers who provide the service.

Start small and grow organically

Sponsors should understand it’s better to start small and grow organically. The organisation must resist the temptation to impose programme structure on a beta team, or believe that by adding more people, workstreams or management layers it will deliver faster – it won’t.

Over engineered programme-level hierarchies or overbearing governance produce noise; noise slows down self-organising, motivated teams. Your role as a leader should be to support the team to figure this out as they go.

Commit to challenging the status quo

Provide the top cover, including committing day-to-day leadership from within the organisation – someone who is trusted and capable of navigating and challenging the status quo.

In fact, it should be understood that the beta will be outside the norms of programme management and governance. Part of the beta will be to explore how both need to adapt.

Go and see delivery for yourself

You’ll know this approach is working and whether you’ve nurtured a good team if they can demonstrate they can regularly deploy and iterate the service based on real user feedback.

Encourage all stakeholders to commit to going to see what and how the team is delivering and to listen to how users are responding. They will see the service coming to life and continuously improving week by week.

This is a far more effective way of assessing true progress and providing timely challenge than by reading and responding to an emailed report sent from afar. Get out of the meeting room and go to see delivery for yourself.

Outcomes, goals and objectives

in

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:

A goal describes the broad direction to achieve an outcome

e.g. “Cater for a memorable birthday party”

An outcome succinctly describes the desired change or impact.

e.g. “Happy memories; full stomachs”

An objective makes goals specific, measurable and time-bound

e.g. “Sandwiches for 20 party people that everyone can enjoy”

A deliverable is a defined output that (may) achieve an objective or goal

e.g. “Party sandwiches”

Update: I co-created a workshop with the wonderful Emily Webber called Five Questions to Measure Success. It’s a tool for teams and leaders wanting to describe and measure outcomes.



Governance - there is a better way

in

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 what matters - 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. 🙏