The power of open: lessons from UK government, hosted by Product People

4 valuable product and culture lessons from the UK’s government digital teams. This was a talk I gave for Product People in September 2024. Video and transcript follow.

In this article

• Introduction
• Video of the talk
• Links shared in the live chat
• Transcript
  • Government is weird
  • Overview of the 4 lessons
  • 1. Build your community of practice
  • 2. Have shared principles to guide you
  • 3. Make things open, it makes things better
  • 4. Seek to improve people, process and product continuously
  • Q&A session

Video of the talk

Links shared in the live chat

About Jock – https://jockbusuttil.com/

I Manage Products – https://imanageproducts.com/

Free weekly newsletter – https://producthead.news/

1. Build your community of practice

Definition: https://www.wenger-trayner.com/introduction-to-communities-of-practice/

Building Successful Communities Of Practice by Emily Webber – https://hellotacit.com/building-successful-communities-of-practice/

‘Start building a community of practice with the 3 minute challenge’ by Jock Busuttil – https://imanageproducts.com/84-community-of-practice-3-minute-challenge/

2. Have shared principles to guide you

10 GOV.UK design principles – https://www.gov.uk/guidance/government-design-principles

GOV.UK Service Standard – https://www.gov.uk/service-manual/service-standard

‘Many things are okay’ by Giles Turnbull – https://gilest.org/many-things-are-ok.html

Team charters – https://psychsafety.co.uk/psychological-safety-80-team-charters/

3. Make things open, it makes things better

Gov-wide services

Design system – https://design-system.service.gov.uk/
Pay – https://www.payments.service.gov.uk/
Notify – https://www.notifications.service.gov.uk/
Forms – https://www.forms.service.gov.uk/
One Login – https://www.sign-in.service.gov.uk/

Picked up and remixed by other governments

US Digital Service – https://www.usds.gov/
18F – https://18f.gsa.gov/
Australia – https://www.digital.gov.au/
New Zealand – https://www.govt.nz/

‘Show the thing’ by Jock Busuttil – https://imanageproducts.com/66-show-the-thing/

‘The show and tell: what it’s for and how to do it right’ by Mark Dalgarno – https://markdalgarno.medium.com/the-show-and-tell-what-its-for-and-how-to-do-it-right-32c2c7b3708b

‘The why of weeknotes’ by Sam Villis – https://stamanfar.medium.com/the-why-of-weeknotes-cf4d7e8ad4e5

Agile Comms Handbook by Giles Turnbull – https://agilecommshandbook.com/

‘How to open code securely’ by Anna Shipman – https://technology.blog.gov.uk/2017/09/27/dont-be-afraid-to-code-in-the-open-heres-how-to-do-it-securely/

4. Seek to improve people, process and product continuously

‘Changing the weather inside your organisation’ by Tom Loosemore – https://www.mindtheproduct.com/changing-the-weather-inside-your-organisation-by-tom-loosemore/

The Service Organization by Kate Tarling – https://www.theserviceorg.com/the-book

Transcript

[Mia]

All right, thanks everyone for sharing your answers and with that I’ll now introduce our guest for today. So I’m happy to welcome Jock, a product management and leadership coach and fractional product leader and author. So thanks so much Jock for joining us, we’re really excited to hear about your topic and now I’ll hand over to you.

[Jock]

Perfect, so can you see me? Yep, there we go, perfect, that’s great. So hello everyone, thank you very much for coming to listen to me today, I hope you’ve had good days.

I will be talking about some lessons I’ve learned from a stint I did in UK government or as we sometimes refer to it the public sector in the UK. This was kind of around about 2014 to 2016 and obviously a great deal’s happened since then but that kind of was a very transformative period for me because I learned a great deal from the people I worked with and the various different disciplines I worked with and so I really took many of those lessons with me and that really changed how I worked as a product manager, as a head of product in other organisations as well.

So I really wanted just to share with you these things. As with anything, context is really important so I never kind of encourage people to just to take literally what people are saying and just copy and paste it into your own organisation, whether it comes to strategy or anything else, but hopefully these kind of principles would be things that you can maybe encourage and whether you’re relatively junior in your organisation or whether you’re a product leader in your organisation, there should be something for all of you to take away and maybe start doing differently if you get the opportunity to do so. So I won’t really do a great deal about me, frankly, if you want to learn about me I’ll pop a couple of links into the chat on Zoom and then you can read up in your own time.

I’ll probably put in more links into the chat as we go along in Zoom and just in case you’re wondering there won’t be any major slides, there will be a couple of things I’ll pop up on the screen so do not adjust your set as they used to say. Perfect, so let’s start. In terms of government, I don’t know how many of you had a chance to work in government in your respective countries, at least in the UK it’s a little bit weird, particularly from a product management perspective if you’re used to working with commercial organisations.

Government is weird

The really obvious thing that strikes you is that when you take away the revenue generation aspect of something, so you’re creating products and services for people but they’re not designed to make money, it suddenly becomes a very different way of working. Obviously we still have a care about costs and being careful kind of users of taxpayers money but the measures of success are more about whether the thing that we’re helping people to do has happened rather than necessarily whether it’s making the organisation any money. So that’s a very odd situation to kind of step into particularly again if you’ve mostly worked in the private sector.

The other thing again that was particularly strange and a little bit difficult to deal with in the UK government at least is that each of the different departments and agencies operate as a kind of federation. So on the one hand there is kind of an overarching kind of mandate to do stuff and that’s obviously handed down by the Prime Minister and through the Cabinet but each organisation, whether it’s the Ministry of Justice, the Home Office, all these different institutions, they’re basically autonomous, they get to define how they work, they have their own budgets. So you see that at the departmental level, you also see it within organisations.

So taking the Ministry of Justice as an example, that was actually a collection of four or five organisations again, each being autonomous, each having its own budget, each setting its own direction and so what you saw was really this kind of fracturing of digital deployment. Whilst there were examples and templates set by the Government Digital Service GDS that you may have heard of, it was up to the individual organisations as to how much of that if any they decided to adopt and so it was very much about collaboration rather than telling people what to do. So I had two stints in government, one was as Head of Product for the Ministry of Justice and the other one was the Head of Product and Service Community for Government Digital Service, which meant that really I was kind of working with lots of different organisations and maybe two or three hundred products people distributed around UK government.

So it’s kind of an interesting and challenging situation. The other thing that’s worth thinking about as context for this is that there’s obviously a lot of politics with a capital P and a lot of sort of office politics if you like with a small p and so to get things to actually happen again because everything is autonomous and everything is federated, you really have to show the benefits of what you’re doing to get people to adopt it. There’s only so much you can get done by telling people what to do even if you’ve got top level support but equally if you can demonstrate the benefits, you can show the ways of working, you can see why it delivers a better result, then that tends to have more success as a guiding approach.

Overview of the 4 lessons

So with that in mind, that context, the four lessons that I want to share with you today. The first one is about building your community of practice and so specifically I’ll be talking about the product management community of practice. I’ll be talking about why it’s so important to have shared principles to guide your approach, your team’s approach, your community’s approach.

I’ll be talking about something that was really fundamental to the way the digital teams worked in government, which was this principle about making things open because it makes things better. And we’ll talk a little bit about kind of what that means and how you can do it. And then the fourth piece, which will I think hopefully tie into the poll that you’ve just done on Slido, will be to about seeking to improve people, process and products continuously.

So those are the four things. So let’s dive into the first bit. So building your community of practice.

1. Build your community of practice

So a community of practice, if you’re not aware what it is, it’s a group of people who share a concern or passion for something they do and learn how to do it better as they interact with each other regularly. So that kind of definition, it’s really aside from line management responsibilities and that kind of thing, but it’s really about people doing the same thing and helping each other to do it better together. And it can be a very powerful thing, particularly when you have large product organisations.

As I mentioned, across government, there are 200, 300 plus product people. And one of the things that I found particularly strange, even in individual departments, was that the product managers, the product people were so busy that they were kind of isolated and lonely and working on their own. So product management as a role can be lonely.

And so really what we wanted to do was we wanted to help those product people have a support network, have an opportunity for them to talk shop with like-minded people, to do something that will benefit the way they do product management. It helps to multiply the learning from product person to product person. The other thing that was really important was the ability to cut across organisational silos.

So as I described, there were lots of autonomous separate organisations at a high level, but also within organisations, there were separate groups within those. And product people from one bit of an organisation didn’t necessarily know about or talk to or interact with other product people from that organisation. And so it wasn’t just that they were lonely, it’s just like the knowledge wasn’t being shared across the organisation.

So what we wanted to do was to make sure that people saw their counterparts in other organisation as allies, not competitors, and to kind of humanize those reactions. Because as soon as you start setting up those cross-organisational interactions, then suddenly it becomes a lot easier to do things that rely on the interaction between those departments. So if you think about things like getting a driving license, you need to apply to the Department of Transport, you need to go potentially to check your identification with the home office, you might need to do different steps which involve different parts of government.

And they don’t necessarily all talk to each other as much as they should do. So this was kind of one way to help work that through a bit better. So that’s kind of what and why it’s important.

How can you start doing this? Well, it depends on where you are in your organisation. So if you are just, you know, you’re not product leaders, you’re just individual contributors, you’re doing stuff, you’re working together, you can start by coming together as a group, meeting regularly, and start talking to each other, start sharing the kind of things you’re working on and seeking help from each other as a group.

If you’re on the product leadership side of things, you can help support and encourage that, you can provide a safe space for them to be able to get together and talk in private, give them time out of their busy schedules to actually take the time to meet up with each other. So one of the things I found particularly challenging, and this might be the case for if you’re working in a large group type organisation, was simply finding where these people were. And so one of the things was figuring out where these people were and then facilitating communication.

And for us, we had to use the lowest common denominator, which was an email list to begin with, simply because it was not possible at a time at least to have a Slack channel or Slack instance that everyone across government could join. That happened later. So we went for the lowest common denominator, an email list, and that allowed us to at least get the conversation going.

It allowed us to let people communicate with each other, talk about things they were doing, but also gave us the ability to coordinate across all of these different groups of people. Then once we had that, we started to bring them together. And at the time, it meant quite a lot of in-person meetings, you know, on conferences, meetups, talks, that kind of thing, lunch and learns.

Obviously, post-pandemic, social interaction has changed a little bit, and so meetups tend to be maybe a little lower intensity, smaller gatherings, less formal. But whatever works best for your organisation, start getting together, carve out a little bit of time every couple of weeks if you can, more frequently if you’ve got smaller teams perhaps. Now, once you’ve got everyone meeting up periodically, encourage the community to start uncovering and meeting their own needs.

Start thinking of the community as a product. What does it need? How can we improve it?

What are we, you know, the members of the community or the users, how can we meet the users’ needs within that community? So, one particular exercise I found useful was something called the three-minute challenge, and I’ll pop up a link to this in a second, but basically it’s very simple. Every person in the group had a few minutes, and in their time, they answered three questions, which might be familiar if you’ve done stand-ups or anything like that.

What have I learned since the last time that’s worth sharing? What’s the next big thing that’s coming up for me? And can anyone help me with this particular problem, obstacle, or annoyance?

Yeah, so very simple. It got everyone talking. It got people collaborating.

We minimized venting, so we didn’t want people ranting about stuff because that’s not particularly productive and not particularly interesting because there’s nothing we can really do about it, but by that sort of basic starting point, it starts to set the ball rolling, and then subsequently in community meetups and community events, we can start doing more interesting things like having people come in to give talks or getting external people to maybe provide a bit of training or whatever it might be.

So, that’s kind of the kernel of getting the meetups going. If you’re a product leader, what kind of things can you do? So, provide safe space to meet, maybe provide a bit of budget for talks, meetups, and provide the time, but do remember to keep separate that concept of line management, which is about people’s salary and promotion prospects and that kind of thing, from the people looking after the community.

Keep separate kind of their performance reviews from their personal development, and keep the community as a standalone thing rather than being part of the day-to-day work of delivering products or projects. But ultimately, listen to what the community needs and help them through facilitation where best you can. That kind of really the best thing you can do as a leader.

It’s not your job to tell the community what to do. So, let me just pop those in there. There’s a couple of useful things in there in the chat, one of which is a lovely book by a lady called Emily Weber, who was instrumental in building the first community of practice within the government digital service.

Okay, so, that’s about the importance of building community practice.

2. Have shared principles to guide you

The next thing I want to talk about is about the shared principles that we use in government. Shared principles are super valuable, and you can use them in so many different ways.

The fact that you’ve published something you can point to, to keep yourselves accountable and honest, but also to easily show other people, this is how we work, this is how we hold ourselves to account. And it kind of manifested in different ways. So, first of all, really early on in the digital teams in government, so way back in sort of 2011, 2012, one of the very first things they did was to come up with 10 design principles.

And so, if you give me a second, I will just bring them up to show you what they are. So, this is published on the gov.uk website, and everyone is able to read through them. The 10 design principles are hopefully relatively self-explanatory.

Start with user needs, do less, design with data, do the hard work to make things simple. And if you see at the bottom, point 10, make things open, it makes things better. This is kind of really enshrined in how they work and how they go about doing things.

So, as you can see, it was published back in April 2012, but it’s been updated since to provide clarification of what is meant by that. Those principles have essentially stayed the same for the last 12 years or so, and with good reason. So, then building on that, the next set of kind of principles that they shared was the principles they used to build a service.

So, this is where we start thinking about what does a service, the product, if you like, that we create, and that encompasses not just the digital stuff, but any physical interactions, any offline interactions, as well as online interactions. So, kind of quite broad in reach. That’s what we talk about when we mean a service.

And so, they wanted to make sure that these services had particular standards that they held themselves to as a way of assessing whether they’re meeting the needs of users in particular. So, to do that, again, they had a selection of standards that they published, again, on the website. And so, these are things like understand users and their needs, solve a whole problem for users, provide a joined up experience across all channels, such as telephone, web, in-person, that kind of thing.

But then it starts getting into quite interesting things. And again, this touches on what we’ll be talking about later on. So, you’ll notice choose the right tools and technology.

Make new source code open. Okay? Use and contribute to open standards, common components, and patterns.

So, we’ll talk about this a bit more in a second, but this is really about encouraging reuse across government without every single individual federated department reinventing the wheel, and thereby wasting from that reinvention taxpayers’ money. Why do things 15 times when we can do it once and use it across government? So, that’s really a couple of examples at the organisational level.

And so, these were available to all departments to draw on. And we also used things like the service standards as a way of assessing whether we could release services into live usage by people in public. Moving a bit more individually, we also had team charters.

So, this is like the readme for the team, how teams worked and how teams’ individual cultures worked in real life. There was no company handbook, if you like. This was more about, well, what do we actually do?

What’s all the unsaid stuff, the cultural stuff about how this particular team works? And it could be stuff like, you know, who does, you know, how do we get together to discuss what we’re going to be doing next from time to time? It could be things like, you know, how we work when, you know, whether we have quiet periods or whether we have busy and noisy periods, you know, whether we use Slack, whether we use something else, all of that stuff.

So, it’s kind of like, we define your shared principles, your values, your behaviors, your expectations, your goals. And one of the ways this was done, which was really, really effective, was a kind of a list of things that it was okay to do. And so, I’ll pop up some links for you to look at.

But this kind of it’s okay to really caught on and started to be adopted by organisations, not just within government, but beyond. And it was kind of good, because it was everything from it’s okay to drink tea. You know, it’s like literally kind of just it’s okay to do these things and to behave in this particular way.

And it really was a way of the team’s defining their own psychological safety. And that’s really why it was so important. It wasn’t the document itself that mattered.

It was the fact that the organisations, the leadership teams, rusted the individual delivery teams to define their own acceptable behavior without interference and for them to be able to work in that way. So, often the artifact, whether it’s the team charter or something else, isn’t necessarily the important thing. It’s what it symbolizes.

It’s what it gives people permission to do. So, in the case of the design principles and the service standard, it’s giving organisation permission to say, this isn’t good enough. We need to do it better, or we need to do it in a way that’s more user centric.

The team charters, it’s giving permission for the teams to have psychological safety for them to be able to make decisions about their own ways of working. Yeah. So, it’s really, really important.

And it’s kind of, you can see it as an act of permission giving by the organisation to the people working there. So, how you can start doing this, first of all, get the permission to write the team charter, get together as a team, write it. If you’re struggling to figure out how to do it, maybe do a reversal exercise and say, what would the worst team in the world look like?

And how would they behave? And then reverse it. So, you can hopefully get a list of things that you prefer to do rather than not do.

And, you know, don’t worry about the fact that it’s going to take a few redrafts. You’re not going to get it right first time. So, give it a bit of time, give it a chance, but you will gradually settle on something that reflects how your team wants to work.

And you can do it at a relatively small granular level, or you can do it at a company-wide or organisational-wide level, whatever works best for you. From the leadership point of view, think about this, you know, permission giving. Letting the teams define their own ways of working might feel a bit uncomfortable, because it’s a yielding of control.

You know, there’s always that kind of concern in the back of your mind. Well, what happens if they say it’s okay to do something really strange? Well, trust them.

Generally speaking, they won’t come up with anything particularly weird or particularly damaging to the organisation. It will be relatively sensible, straightforward stuff. Just trust the team to come up with sensible things.

So, try not to interfere if you can. But the other thing you can do to support that is to look at the organisation as a whole and say, what are the guiding principles we have? What are the things that are okay for us as an organisation to do and what are not okay?

Can we make sure they’re clear? Can we make sure that they actually reflect what we do? I mean, so many organisations have their core values up on the wall, but then in practice don’t really adhere to them.

So, how can you think about ways of actually encapsulating those core values that you actually do on a day-to-day basis? And try not to have too many of them, you know, a small handful, four, five, six, maybe 10, yeah? But not hundreds and hundreds of these things.

And maybe use things like the 10 design principles I’ve linked to before, just as an example of what that can look like and use it to guide how you work. Great. So, let me pop into this. Next thing.

3. Make things open, it makes things better

So, making things open, it makes things better. Counter-intuitive to some.

Some organisations are wary of making things open because it opens them up to criticism if they’ve not done a fantastic job. If organisations have a sort of blame culture, it can potentially be problematic from that point of view. So, in government, which absolutely kind of had those concerns, this push to open things up was resisted in many places simply because it was, well, not the way they did things up until that point.

So, it wasn’t necessarily something that everyone adopted and, you know, welcomed with open arms. It took some work to do it. But the way we did it was, for example, yeah?

We shared openly things like what we were trying to do, what our designs were. Our failures, our mistakes, our lessons for next time, we were open and transparent about those things. The other reason why it’s really important is because sharing things in this way pays it forward.

One team solving a particular problem might find that actually there’s other teams in different parts of the organisation, in different departments that have a similar problem. And so, they can reuse, again, that knowledge gained and get the benefits all over again. In the same sort of way of thinking, not reinventing the wheel from technology’s point of view.

If there’s a really good way of doing something, it will have a gravitational pull, and if you make people aware that it exists, they’ll gradually all adopt it, which is the best thing. And so, we ended up with this concept kind of being writ large by essentially creating platform-based services that could be shared across government. The first one was kind of a design system.

So, all of the user research that went into designing accessible web-based forms, into creating clear, plain language that could be understood by anyone, into making systems for working stuff online that was very easily understood. All of that investment of user research and design effort shouldn’t be something that had to be multiplied by every single team in every single department across government doing it for themselves. So, it made absolute sense to open this up and share it as best they could and iterate upon it.

And as soon as they opened up and shared it, then suddenly everyone else could contribute it and improve it. And gradually, gradually, gradually, everyone got to benefit from the incremental improvements that went into the single thing. You know, it seems obvious, if you’ve worked with anything that’s open source, you’ll absolutely get this idea.

But again, in government, with that federation structure where everything is separate, has their own separate budget, that kind of idea of contributing to something outside of your own organisation was really alien and took some getting used to. But gradually, gradually, gradually, people got more comfortable with it. And then it led to provision of what we’d expect, you know, like almost like API services.

So, things for taking payments, yeah? You don’t need every single government department implementing their own way of taking credit card details. You don’t need every government department implementing their own way to send out SMSs or emails or even paper letters and so on.

So, you get the idea. So, creating government-wide services that could be shared across government was really, really, really valuable and was something that developed over time. But it was all within that spirit of kind of opening stuff up for reuse and for improvement across the board.

So, let me pop in a few more links for you to see when you want to in your own time. There was some contribution to open source projects where we were using them. But one of the things that was quite remarkable was how from the outset, the teams, the digital teams, would open up their code repositories on GitHub.

And you can see them on there now if you go there. They opened them up. And what that meant was whilst, okay, quite a lot of what they were doing was particularly specific to government.

And so, not likely to be picked up necessarily by other organisations outside of government. What did happen was that the kind of structure, the principles, the ideas was picked up and remixed by other governments.

And so you have examples such as the U.S. Digital Service. Australia picked up and remixed it. New Zealand picked up and remixed.

I’m sure others did as well. And I think there’s some governments in Southern America that actually have picked it up as well. So there’s quite a broad spectrum of places that have taken this code, this structure, and actually reworked it for their own needs.

And that’s great because it means it’s, again, it’s saving time. We’re not having to reinvent the wheel. And equally, the contributions they make can be things that we can pick up on as well.

So there’s a few examples here for you. I’ll just pop them in the chat again if anyone’s interested in having a look. So making things open, it makes things better.

How you can start. Again, you can do things small and easy. One of the things we had was something called show the thing, which was like a weekly get together where teams would have five, 10 minutes each and they had to show something, not talk about something that didn’t exist yet.

They had to show something they’d done, show something they’d learned, show kind of the results or the findings of their research. And it was very much about sharing within the different teams. And some would even broadcast it on a live stream.

But the idea being was it was about sharing what they’d done as openly and transparently as possible so other people could equally learn about it. I’ve got, I’ve done a write-up of this as well. So I won’t necessarily re-repeat the whole thing for you.

I’ll send the links in a second. Another way of sharing what we did maybe in a different way to a slightly larger audience on a broadcast way was through week notes where people on the teams, whether it’s the product managers or whoever else would write week notes about what the team had been up to, what they’d learned, what they’d achieved, what mistakes had happened, where they’d learned from them, what challenges they’re facing, maybe where they needed help.

All of this could be published into week notes from individuals. And then kind of following on from that, blogging. So a bit more formal, more kind of for public consumption.

But this was about talking about what we’re doing and why as openly and transparently as possible. And this was always kind of a little bit of a bone of contention because again, at the time at least, government liked to control the message. They didn’t necessarily like this stuff being out there, but actually realized over time it was beneficial.

It did help people engage with the services and ultimately didn’t cause any particular problems. So blogging about what you’re doing and how you’re doing it can be a really valuable way of showing that, you know, showing your thinking, showing why you’re doing things in a particular way and indeed soliciting feedback to maybe improve them. So let me just post up these things for you.

If you want to read more about kind of ways of communicating in a more agile way, there’s also a really good book by Giles Turnbull, who was again at GDS as well. And so he’s talked about this in a bit more detail. And similarly, if your organisation is saying, well, you know, we don’t want to open up our code repositories to absolutely everyone and make them public, that’s understandable.

And there’s some useful guides again online in one of the links I’ve just shared, which kind of talks about that challenge, how you can open things up if you wish to. And even if you don’t want to make the repos completely public and make the software open source, you can do what’s called inner sourcing, which is effectively allowing people within your organisation easier access to the stuff you’re building. So again, you can get the benefit of what you’re doing across the organisation.

So how can leaders help? So again, it’s permission giving. It’s allowing time for the communities of products, people, for the individual teams to talk about what they’re doing.

It’s about supporting, providing credit for what people are doing and saying, look, you know, recognizing when people have done good work and really just making that kind of idea of making things open, a fundamental principle that the organisation supports and permits is really, really crucial to getting this to work.

4. Seek to improve people, process and product continuously

Okay, so on to the last one. So seeking to improve people, process and products continuously.

As you can kind of imagine, whenever you go into some kind of organisation with a particular culture, especially government, there was like a grinding of gears. There was a group of people coming in who were user-centric, focused on delivering the best possible value for taxpayers’ money and delivering it quickly and without necessarily farming work out to big IT companies or consultancies to deliver for them. And this was such a cultural shift or sort of a kind of culture clash, if you like, between how things had been done for so long and how they were proposing to do things that it took so much effort to gradually convince people, allay their fears and earn the trust to be able to do these things.

So from the outset, even with strong support from the cabinet office, so the central body that can actually force things through if they needed to, we couldn’t just snap our fingers and change everything. Problems were complicated. They required lots of different things.

They were complex in that they needed lots of things to change at the same time and not all of those things were in the power of the teams. But also it highlighted things like misaligned goals in the organisation, these big initiatives to deliver something but actually wasn’t aligned with user needs. It took time to get people to realize that this was problematic and a waste of taxpayers’ money.

So we couldn’t just turn the ship around in the outset and it took years and years and years, much longer than I was there and I certainly don’t claim responsibility for the work that went in over the many years to kind of get this to work in a different way. But it’s something that you have to keep working at. You have to keep persisting with to get that change to happen.

So there has to be some kind of balance, okay? There have to be ambitious goals but also you have to be able to demonstrate you can deliver meaningful wins in a reasonable timeframe. So if you think about kind of earning trust, to begin with, you start with the quick wins.

You start with earning trust for a small thing to earn you a bit of permission, a bit of trust to do the bigger thing. Really, whether it was the individual teams kind of showing that they could solve a small problem and solve it well and be able to talk about that, then use that to gain the credit, the social credit, if you like, to work on something bigger, something more influential. They gradually worked on building up their track record to be able to earn permission to do the bigger things, to make the bigger changes, to take on the more politically sensitive projects, the more challenging projects.

But they couldn’t just jump straight into the big things because they wouldn’t have had that permission or that trust from senior leadership yet. And that’s partly why it ties into this, like, transparency and making things open. By communicating all of the things they’d done, the valuable learning they’d achieved, it helped to just multiply and reinforce the work they were doing.

So they became very, very, very adept at broadcasting their wins. Really getting as much credit for those wins. And it wasn’t about, you know, getting promotions and stuff like that.

It was about getting the team permission to do that bigger thing. Yeah. So from the leadership point of view, as you said, there was some top level support, at least for the first few years, but that didn’t necessarily persist as, say, politics got involved.

But again, if you are in a position of leadership in your organisation and you want to help people process and product to improve continuously, it’s about making sure there are clear goals. It’s about supporting and not blaming. It’s not micromanaging.

It’s about helping people to establish an environment of psychological safety to allow people to work in the way they need to. Because then once the teams are working that way with their guiding principles, with their team charters, with the communities to provide their support, they all layer on top of each other and help to promote this desire to make things better for the teams to work in more effective ways, for them to deliver more effective products and services to improve the way the organisation operates and engages with its users or customers.

This is kind of why it’s like a complex problem, why you need all of these different things layered on top of each other. Just doing one of these things by itself won’t necessarily have the desired effect. But when you combine it and you have those that underlying mindset in place, then that’s when the magic starts to happen.

So, you know, like I said, you can’t just copy and paste this and it will magically work for you. It’s thinking about how do you set in place that way of thinking in the organisation that allows that environment of change to happen. So one last link for you on this is a very useful book about the kind of challenges around getting an organisation into this service-oriented, this user-oriented culture.

And again, it’s from an insider. It’s from a lady called Kate Tarling, who worked in government for some time. And so her book is called The Service Organization, and you can find it here.

So that’s broadly the areas I wanted to talk about. I hope I haven’t run long. But just to recap, the four things that I learned and took away and try and implement myself whenever I work in any other organisations as a freelancer is I try and establish a community of practice for the product team.

I want the product people from across the organisation to know each other exists and to start collaborating with each other so they can multiply the learning they get as a community. I try and establish, if there aren’t already, shared principles at the organisational level and at the team level to guide how we do things, how we deliver product, but most of all, how we work as a group and how we interact with each other. I try to encourage greater transparency wherever we can.

I’m not necessarily going to go into a commercial organisation and tell them to open up their repos and make everything open source because that won’t work. But what we can do is we can blog about things, we can talk about stuff, we can engage with our community of customers and users in a more transparent way. But we can also encourage transparency across our organisation, across departments and silos.

Then the fourth piece is about seeking that continuous improvement. Really, this is about setting the environment for it and then people, if they’re motivated, will seek to make things better in that environment. Yeah, we can do retrospectives, we could do all this kind of stuff.

This is just part of it. The processes don’t necessarily create the improvement. There has to be that underlying desire and that environment to allow that change to happen for that improvement to come about.

But don’t expect it to happen overnight. So, thank you very much, everyone. And I’m happy to take any questions if there are any.

Q&A session

[Mia]

I’m just going to take over with screen sharing, Jock.

[Jock]

Perfect, please do.

[Mia]

One second. All right. Can everyone see me? Can you see my screen?

Yeah. Perfect. All right.

So, yeah, thanks so much, Jock. And thanks, everyone, for listening. And we’ll now start the Q&A segment.

So, please share your questions with us via Slido or you can scan the QR code. And to give you some time to draft and type in your questions, I’ll go over a couple more slides about product people. So, yeah.

Here are some typical use cases where our team is best fit to intervene. So, maybe you’ve got funding and need to grow your product team by a few PMs. Perhaps your PM is going on parental leave for three to 12 months, is leaving or has left your company and hiring will take two to nine months. Maybe you have a temporary initiative that is important and urgent, or maybe you’d just like someone to appraise the product team or processes.

So, we’ve done this successfully at many clients now. So, some B2C clients, such as Zalando, Douglas, Emma, and many B2B clients as well, such as Pliant, Permature and Sastrify. And here’s just some stats about our company.

So, we really value ourselves based on our diversity. So, 62% of our leadership are women. And yeah, can we do a bit more?

All right. So, we’ll now go through some questions. I can see we’ve got some.

Okay, Jock. All right, question number one.

What were some of the initial challenges that the UK government digital teams faced when implementing open working practices and how did they overcome them?

[Jock]

So, it really ties into that last piece I was saying. The resistance to change that kind of culture clash. You know, so at one point, kind of the traditional kind of civil servants seeing, as they put it, the people in jeans and hoodies kind of coming in to the organisation and work on these digital services.

There was a lot of kind of cultural change. And it would have been way too easy to kind of have a kind of them and us approach to this. So, by opening up what we were doing, by not kind of being defensive about sharing information freely, it kind of meant that it undermined any kind of criticisms in some way.

Because if we were the ones who were saying, oh yeah, you know, this worked really well or this didn’t work so well, but this is what we learned. There’s no, it doesn’t really give people any ammunition to criticise for us. So, what we really tried to do was, we tried to draw people and we tried to engage with them on their own terms.

We tried to be as empathetic as we could be to their existing ways of working. I mean, it’s all very nice for us to come in and say, you know, we’re going to be doing this with principles from the commercial sector, you know, best practices in product management or design or user research. But it’s also saying, well, we recognise the fact that you have been delivering services to the public for many, many, many years before we turned up and, you know, being respectful of that.

But equally saying, here are some new ideas, here are some ways that genuinely will save your time, that will make things easier to manage, will take away a lot of the manual stuff that was a problem for you. And by showing people that and by bringing them literally onto our teams and getting them to sit side by side with us and work with us, we were able to show them a different way of working and let them make their own minds up about whether that was better than what they were currently doing. And, you know, for the most part, it worked.

There were always going to be some people who were going to be resistant to change and we’d never be able to change their minds. But we did win people over and we were able to demonstrate the value of what we were doing. So try and meet people on their own terms, I think is maybe the way of summing that up.

[Mia]

Thanks, Jock. And can you share specific examples of how transparency has positively impacted team dynamics and decision-making within the digital teams?

[Jock]

Yeah, so one that was really interesting was every product or service, if you like, within government is kind of obliged to publish performance statistics. So this was more than just the operational stuff about how many people were using it. It was actually performance statistics about whether it was actually allowing people to do the thing successfully, yeah?

So if the service was apply for a driving license, clearly the number of successful applications was important, but equally the number of people who were rejected for valid reasons. So they weren’t eligible for a driver’s license in the first place. This was really important and it was completely counter to the culture at the time.

It was, as I said, it opened up, people were concerned that if they published statistics about how their service was doing, then people go, well, hang on, it’s not working very well. Your thing that you’ve spent millions of pounds on isn’t actually delivering any value and people maybe wanted to hide that. Whereas by bringing that into the sort of light of day, it got to highlight things that actually could be improved and where they needed to be improved.

It wasn’t necessarily a thing about saying, this is your fault and pointing blame, but it’s about saying, okay, this isn’t working so well, how can we, now that we know that, how can we make it better? And so that was like kind of almost like one of the biggest hurdles to overcome. But by just saying, look, everything has to publish these performance statistics, suddenly meant that people had to be kept honest.

And so they couldn’t release something that was a waste of taxpayers’ money. It had to actually be able to do the thing. So that’s one specific example I can think of off the top of my head.

There were other examples in similar ways about shining light on things that were clearly nuts. Not my story, but a speaker I was listening to recently who works on the COVID app in the UK. There were some questionable suggestions about what could be included in it.

And when this was then shared with like kind of a group of stakeholders who all were quite senior and all had a stake in what this COVID app needed to do, so represented from government, from the National Health Service, and so on. Then these crazy suggestions were seen to be as crazy as they were. And it meant that the team didn’t have to say no, the respective leaders from different parts of the organisation said, this is clearly crazy, you don’t do this.

And it kind of helped bring a sort of degree of sanity back to what the app needed to do and what was considered successful for it. So sometimes that aspect of kind of being transparent and open with stuff can maybe counter the vocal but influential stakeholder just pushing for possibly crazy stuff, which doesn’t make sense to the wider collective. And that can be a really valuable way of deflecting and diffusing that kind of input without necessarily tackling it head on and having to be the person who says no directly.

[Mia]

Okay, we’re nearly at time. So this will be the last question.

How does the concept of continuous improvement manifest in the daily operations of these teams?

And what tools or methodologies do they use to facilitate this?

[Jock]

So a variety of tools and methodologies. One of the aspects of the teams being autonomous was that they could define their own way of working. And that meant that some people, you know, follows scrum, some people follows kind of hybrid scrum, some people follow Kanban, you know, basically it was up to them how they worked as a team.

But within that, you know, broadly agile frameworks, they had, you know, retrospectives, things like that to say, you know, are we doing what we’re supposed to be doing? How can we both improve our products? But how can we as a team improve the way we’re working?

What are the things that are preventing us from doing that? And, you know, you surface that kind of stuff, both at the delivery team level, so the teams working on the products and services, but we’d also see that coming out at the community level, where we’re seeing the same kind of challenges from different departments or different bits of the organisation and saying, this is hard, you know, this dealing with this particular group of people is tricky, or we can’t get access to this information. How can we get around that?

And again, by pooling the experiences, somebody goes, ah, the way you do that is you need to talk to this person. They’re really crucial in getting it to work right or finding ways from the organisation saying, look, as a community, we can solve this problem for ourselves. We just need to get better at doing this.

So let’s spend some time as a community skilling up and we’ll devote some time to that. And in that way, hopefully this will become less of an issue in the future. So having that feedback mechanism, running experiments with a fixed hypothesis to say, we believe by making this change, this thing will improve.

And if it doesn’t, we’ll try something else. And then revisiting those experiments over and over to see whether the change had the desired effect. Those are really the kind of mechanisms that we put in place to make sure that there was that continuous improvement.

And again, you saw at different levels, at team level, at the service level, at the community level and so on, just in different ways. But with that same idea of saying, how can we prove that we are actually improving?

[Mia]

All right. Thank you so much for sharing these insights with us. It was great to have you.

[Jock]

Thank you very much.

[Mia]

And thanks everyone so much for joining us. And we hope to see you next time for our live stream event. All right.

Thanks. Bye.