The tips and ‘cheat codes’ I’ve discovered leading a Policy Lab.
I’ve often described myself as a career chameleon. I’ve worked in operations, policy, data and digital — and so far the golden threads that have connected my career have been openness, community and justice. I’ve had the privilege of seeing how different roles solve a problem from the place in the system they occupy, and its one of the many reasons I’ve always been passionate about building empathy across professions. It’s also one of the reasons why I applied to lead my department’s User Centred Policy Design (UCPD) team, which I’ve been doing since May 2019.
There are some excellent spaces to learn how Labs and policy design are evolving in Government, from the long-established blog space of the original Policy Lab, through to the recently established Public Policy Design community. There’s fantastic research published from leading academics, such as Dr Anna Wicher and her report on design research and policy in the UK; as well as our own cross-government report on Policymaker perspectives on reform. Plus there are helpful lessons learnt from the folks of Denmark’s Mind Lab, such as Thomas Prehn & Christian Bason sharing the story of why the world’s first innovation lab ended, and Jesper Christiansen’s blog post about how ‘running a lab is all about the trade offs’.
What I’ll share is probably obvious and/or it’s probably already been said, but it’s another voice in a moment to listen to if it’s helpful now, or to look back on to learn lessons from the past in the future to come.
So here are the things I’ve learnt over the years. As I’m publishing these on my own Medium account, they won’t be Department specific, nor will they discuss the policy challenges I’ve worked on — they will be my personal tips and ‘cheat codes*’.
Everyone’s favourite tip: start small
Most Policy Labs are situated as part of the DDAT (or equivalent) profession and then work to/with the Policy profession. Your ideal ‘starting team’ should include a Product Manager, User Researcher, Service Designer and Delivery Manager. I’ve tried combinations without those four core roles and we muddle through, but it doesn’t really work well. As you prove the value of the approach and mature your team, you can add more roles to that configuration – for example, my team also includes Content Designers, Developers and Business Analysts. Some Policy Labs hire ‘Policy Designers’ from the outset — its not an approach I’ve taken but am watching how that evolves with great interest.
If a typical discovery is 4–8 weeks, I’d recommend initial policy design projects as being 8–12 weeks. You need time to help folks understand the approach you’ll be taking and why and build your understanding of the policy space. At the beginning if you can benchmark a policy team’s understanding of user-centred design (and then re-measure at the end of your engagement) then do it! That insight is gold dust.
It can be much harder to keep to that magic 8–12 week number as you work on trickier, cross-systems work. When you do get to that stage, make sure you’ve got something to clearly anchor to — define your outcomes up front and keep checking in on them — and regular points (we use the typical discovery-alpha-beta-live phases) built in to review. Check you haven’t slipped into outputs/solutions. And make sure you have buy-in for whole system (digital) end-to-end transformation, not ‘just’ digital delivery.
Think carefully about if you want to cross-charge your expertise to the teams you’re partnering with, as it can incentivise the wrong types of working. I’ve charged at the ‘point of delivery’, when we’re actually committed to building a digital service, product, tool, creating/updating content, etc.
Labs won’t be able to reach everyone at once and you’ll probably have limited number of ways to make an impact. So go where you can flow. You’ll want to create meaningful relationships with sponsors across your organisation. Don’t keep knocking on closed and bolted-shut doors. We know there are higher rates of burnout in ‘change agents’, so protect your energy and keep things focused.
Language (still) matters
To quote the wise Carrie Bishop, ‘no one cares about your double diamond’.
There are times when it’s helpful to talk through the digital/design methods we use, but the language that’s always made it easier for us to describe why we take these approaches is to frame things around risk (such as policy, financial, reputational) and how we can minimise it.
We believe that in the future all complex policy will be designed with users, tested, and continually iterated in order to reduce the risk of failure.
Keep going back to the problem we’re trying to solve and who we’re trying to solve it for. I’ve observed this strange perspective that only Digital teams think like this but it isn’t true. The Policy teams and Analytical teams I’ve been part of are brilliant problem solvers and absolutely see it as a key part of their role. The problem should always be our basis for any scoping and kick-off of new work.
The Service Standard still doesn’t feel relevant to Policy teams because they can either view delivery differently (eg: seeing delivery as the consultation they undertake or white paper they publish) or don’t feel as connected to implementation as that’s often the responsibility of operations or digital/technology. The concept of ‘Discovery-Alpha-Beta-Live’ doesn’t always translate, and I usually compare the approach to pilots I’ve run in my policymaker days to help teams understand the difference and the value working in that way will bring them.
Jeffrey Allen has a charming story about the phases – told as though you are navigating a journey in a boat – which I’m really hoping he’ll publish shortly (or better yet, record the story as it really is just lovely to listen to). Together we’re trialling the concept of a standard for Policy Design which we’re testing through one of our projects and will share more in the future.
Another framing I’ve used to help teams understand the concepts of user-centred design and co-design is the Participatory policy design ladder, adapted by Policy Lab from Sherry Arnstein’s work on ‘a ladder of citizen participation’. When training/coaching teams I’ll often get folks to place themselves and their current project(s) on the ladder, and discuss what enabling conditions need to be in place to increase that participation.
Another consideration around language is the privilege you have in the voices you choose to amplify to teach folks about the various concepts of design. Continuously review and evolve your materials, and keep testing how representative they are of society.
Make your Lab’s service offer clear
I’ve been mistaken for (the fantastic) Design102 a bunch of times. Some folks have contacted me to help them format slide-decks or create infographics; see if I can help them procure a license they’re trying to obtain… the list goes on.
Articulating what you do, and what you don’t do, is essential. So here’s my tips for your service offer:
- Make sure you have a clear mission, vision and strategy of how you plan to achieve that. (Want to know more about strategy? I always point folks to Sophie Dennis and her slides)
- I always try to stick to three things** in my strategy, otherwise I risk doing too much and not particularly well; stepping on the toes of folks who should be doing it as part of their offer; or not being able to develop repeatable patterns and specialise. For example, our 3-fold Lab strategy is  Providing hands-on expertise to high value projects  Increase awareness of UCD  Testing, validating and developing digital solutions to policy problems.
- Consider the ‘light to intense’ options for folks collaborating with you and understanding more about your work. For example, do you provide 30–60min introductory sessions, 3hour+ workshops, half/full day training options? Do you have an ad-hoc coaching offer to support teams where you can’t commit to a full team 8–12+ week engagement, etc?
- Understand how folks discover your Lab exists, perhaps by mapping out typical journeys from awareness through to first contact, how folks discussing potential projects with you, etc.
- Get beyond ‘just’ delivering insights. Labs can often be seen as source of user research for decision making documents — its essential we go beyond that to prototyping and testing ideas. Consider making that an upfront element of your service offer.
- Have a clear criteria for your prioritisation process. We have a three-stage criteria for accepting, prioritising and starting projects. Have a plan for when you’re unable to prioritise and work on a project with someone, such as offering coaching support, signposting them to other teams in your organisation who can help, etc.
- Standards are your friend, align to them! For example, user centred design is called out as a skill in the Policy Profession Standards (see 3.5 Policy delivery — User Centred Design, Digital and Behavioural Insights).
Build empathy between professions, and above all be generous.
When hiring or developing the people in your Lab, having folks who have experience of the very thing you’re trying to support or change is essential. For example, our Lab is about bringing new methods to policy, so our Lab has ‘ex-policymakers’*** in it. I can see people’s expressions changing when I tell them I’ve been a policymaker and the challenging spaces I’ve worked in because they know I have some understanding of their daily experience. It goes towards building the foundation of psychological safety with the teams you work with.
As part of defining your service offer, understand similar service offers in your organisation. Whether its an implementation unit, an experimentation hub or an organisational design function, your organisation is bound to have another team similar to yours — either in vision, mindset or approach. Take the time to understand each other, form alliances and signpost folks to each other when appropriate.
Understand the organisational design within which you operate. Can you easily form multi-disciplinary teams and operate ‘as one’? Or do you need to focus on improving the interactions (and hand-offs) between different professions? Be conscious of the nuance that can exist between different roles — for example, sometimes it isn’t clear the difference between (typically digital-led) user research and (typically data/analysis-led) social research. There’s still missed opportunities to bring those communities closer together.
Understanding your organisational design is also essential for the vision you’ve articulated — is achieving that possible in the as-is state, or does it need re-imagining? What’s within your gift to change?
We run a 60min session at every policy induction to introduce folks to UCPD/UCD. This training is often the tip of the iceberg and there are still capability gaps, such as problem structuring masterclasses or facilitation that we fill. As well as upskilling policy teams in UCD, consider if there is a need in your organisation to upskill digital teams in policy making. [That topic is a whole blog post in itself, so for now I’d point folks to Policy Labs’ Government as a System (formerly known as styles of intervention), Kate Tarling’s blog post on Ways that Policy is carried out and Paul Maltby’s blog posts on What digital and policy can learn from each other and A short guide to policy for government digital professionals]
Above all, to quote the exceptional Sam Villis — ‘be generous’.
Measuring this stuff is hard, but not impossible.
The work that Labs do can be a real mix of ‘upstream stuff’, such as early stage problem analysis, developing user-focused recommendations, policy design itself and/or ‘downstream’ (digital) delivery. I’ve found that having a balanced portfolio is beneficial as the first is trickier to measure the impact of, or it takes longer to demonstrate the impact of.
Putting that aside, you’ll still need project and organisational level measures for that early stage work — particularly if it never becomes a service that you can eventually demonstrate the performance of.
Things to consider capturing here are (replace the [x] with the space you work in!):
- [policy] teams understand the user-centred design approach and its benefits
- [policy] teams actively seek out user-centred design capability/expertise
- [policy] teams actively choose a user-centred design approach as their way of working
- insightful data was gathered quickly and frequently to steer the future of the [policy/service]
- [users] issues or challenges are fully understood before solutions are committed to
- ease of translating insights into action
- [the policy] is sustainable and can be continuously improved/iterated
When thinking about your measures, consider if you want to focus on relevance, efficiency, efficacy, impact, sustainability or something else entirely.
Your mandate can be fragile and your role can be isolating.
These are probably the hardest lessons, especially if you’re someone who loves your work and can easily take it into your heart.
Leading a Lab, much like many leadership roles, is actually quite isolating. It’s something leaders don’t talk about enough. I don’t think it’s because we’re afraid to be authentic, but because we know the weight of our words when we’ve felt them from our previous leaders. I really love Sally Lait’s blog post on Leadership through a personal crisis.
There are days when I dream of being a hands on Product Manager or Delivery Manager, where I really want to get stuck into doing the work, where I long for the rituals to feel connected and a sense of belonging. There’s no daily stand up for Leaders. We’re lucky to have a fantastic community of Labs leaders that get together monthly and are so supportive of each other, but you just can’t beat those morning stand-ups where you check-in and make progress together. Last year I was doing very hands on delivery during the pandemic and that comradery truly carried us through.
Something that’s not unique to leading a Lab, but for those working in Labs generally is that you tend to feel stuck in this weird middle land. You feel your approach is too ‘out there’ to some, but is falling behind the curve to others. Remember this is okay – we are often a bridge between worlds.
We focus so much on achieving the perfect model, and we should always keep adapting, learning and optimising, but that perfect Lab can be a red herring. What was, and will always be important, is the mandate you have.
Finally, it seems the three biggest blockers are always the same
Permission. Time. Capability. In that order.
I hope you’ve enjoyed reading this blog post and I’d love to know what you think, or if there are any themes I’ve missed that you’d like me to include.
You can also find me on Twitter at ayymanduh.
*I think of ‘cheat codes’ as the quick wins to accelerate organisational culture change, for example: language to use (or avoid!) to help folks understand concepts; techniques to shift mindsets and apply new ways of working.
**The lasting influence of working with Jeni T — I always think of things in 3s or 5s now. (I’m even annoyed at myself this isn’t asterisk number 3 of this blog post)
***Does anyone ever really become an ex-policymaker? I still feel like one years on from my last policy role.