Open, honest and always improving
Best product management practice in government organisations will look startlingly familiar to anyone who’s worked in a user-centric company. But what does it look like when the usual commercial drivers such as revenue, profits and investors are taken out of the picture?
Video, slides and transcript after the break.
In government, product is borne out of transparency, quite a lot of cake and a fanatical desire to serve the needs of users.
In this recent video for ProdPad’s webinar series, I talk about the acute challenges of culture clash. You’ll also discover what can be achieved by highly motivated, principled and capable people when they set an example for the rest of an organisation – or the entire Civil Service – to follow.
Hello everyone! Thanks for coming along today. So hello, my name is Jock Busuttil and I’m going to be talking to you today about some of the experiences I had in government. So this is all about product in government and hopefully this will be of interest to you whether you’re working in government, or indeed working in the private sector as well. So hopefully yeah hopefully we’ll get some good things out of this.
Context: role, timeframe, digital services
So where to start I think you need a bit of context so first of all I was in – working in government, in between 2014 and 2016. And I had two different roles: one was as head of product for the Ministry of Justice the digital team there; and then the second one was for the Ministry of Justice where I was head of the product community there. Now so obviously it’s a little while ago, and things have moved on from there, but I did want to share what I’d learned from my time there, because it was quite an interesting time. And to put this in context of when these digital services existed.
So GDS, Government Digital Service, was the central digital service, and that started up in about 2011, and was attached to the cabinet office in the UK. So it’s quite a central government department. And what they did was they defined a template that other independent ministries and departments across the UK government were expected to follow. Now early on, because they had some pretty good support, they had a lot of political clout. So they could push through change and they capitalised this on this. They got they got a lot done they got a lot changed. But later on their authority had to come less from ‘do as I say’, and more from ‘follow our example’.
So each government department was as independent, and so when GDS was setting the template, it was up to the departments and ministries to decide whether and how to follow that template. And the Ministry of Justice which is actually where I started out was one of a relatively small handful of departments that follow GDS’s lead from the outset. So so yeah we’re seeing things only a couple – two to three years after the whole move towards digital services started off.
How I ended up working for government
Now my journey started with a tweet as some things tend to. And after a couple of months and a lot of security vetting later, I ended up at the Ministry of Justice. And this brutalistic concrete building is down in Petty France near St James’s Park. And the Ministry of Justice, as you might expect, is responsible for things like prisons, courts, and it had a Ministry of Justice digital team.
And so when I joined MoJ digital they’ve been running for a couple of years, they committed to deliver four of GDS’s 25 exemplar services. So these were high-profile services that they wanted to launch to demonstrate, almost a proof of concept of a more digital government. And they promised to deliver these by march 2015. So about six to nine months after I was joining.
Controlling the message
So one of the things that GDS, and MoJ to an extent, have been particularly good at over the years is telling their story. Now you’ll probably remember if you’ve been to a conference product management conference any time between – in the last eight years or so, you’ll probably see I’ve seen at least some presentation from GDS. And you’ll probably remember the high production values of their videos that you tended to see. And whilst these did accurately represent their focus on user needs and the things they did well, yeah by choice and by necessity, I think, they had to gloss over some of the challenges, shall we say, of the day-to-day life in the various digital teams.
Politics as you can expect always played a major part. And GDS because it started out a disruptor, they ruffled feathers. They they alienated some big departments, and they did talk about sometimes the things that didn’t go so well. But there was always a worry in the background that if they made too much of a deal about some of the stuff that didn’t work so well, then it might end up on the front page of the daily mail, one of the tabloids here in the UK. So you can understand what they wanted to minimise the politics.
You know, if every mistake you make as a product manager, or as a working in your company is potentially going to be a front page news the next day, then you really don’t want to do that. And particularly in precarious position they were in where they needed to make sure that the approach actually worked, and they didn’t want to undermine that, they were understandably quite conscious of their image and what was going on
So what I really I’m just trying to say is that I want to give a little bit of a behind the scenes thing, because funnily enough not everything plays out perfectly, and not everything is necessarily as easy as it may look. And that’s important to realise.
Product management was still relatively new to government
So at the time I joined, product management, and many other disciplines like design and user research, were very new to the civil service so generally these disciplines had to be recruited in especially or homegrown. And recruiting people into the civil service would take about six months, whereas in comparison, recruiting contractors or freelancers would take two to three months.
So to get things moving that’s the approach that GDS and MoJ took. They’ve got lots of contractors in. Now the freelancers of my team were talented and lovely, but they were a lot more expensive than civil servants, and we’re all very kind to the fact this is paid for by the taxpayer.
The brain drain
Another problem was the brain drain. A contractor could walk out the door with minimal notice. They could walk out with days, not even weeks. And when they left they would take all of the investment of knowledge with them. And there was some there was minimal incentive for them to do any handover, unless they were nice people, which to be fair quite a lot of them were.
So this initial reliance on freelancers meant that civil servants were not getting the chance to learn more about product management. So the goal was to get more civil servant product managers in place, who would keep the investment of knowledge within the civil service, and by definition save them the taxpayer a bit of money.
And for those of you who may think that I’m potentially being hypocritical in this yes I was a freelancer and I made myself redundant as quickly as possible by recruiting a civil servant to replace me as head of product, both MoJ and GDS. So that was something I did I did reasonably quickly.
What we’re going to talk about today
So I’m going to talk about four things today, in the time we’ve got: one is building a community; second thing open working; three how we kept ourselves honest; and four about how we continuously improved ourselves.
Establishing a product community
So one of the ways I wanted to counteract this brain drain was to establish more of a product community. Now at MoJ we had 12 products managers, including a couple of civil servants, but mostly freelancers, and there were differing levels of experience. Each product manager worked with multi-disciplinary delivery teams, so product management use researchers, designers, developers, et cetera, et cetera, et cetera.
And my team was about twice the size of the one you see in the photo, so these guys were about half of my team and before I got there I don’t think they’d even sat in a room together. They they were so busy, that they were just getting on with their products. They didn’t necessarily socialise, let alone have time to socialise much with each other. So as a result there was not really anything resembling a community, it was just a collection of individuals.
And this was almost repeated at GDS, a much bigger organisation compared to the Ministry of Justice’s digital service. So there are at least about 40 product managers at differing levels, from associates junior level all the way up to lead or effectively product manager head of product management. And they again I don’t think they necessarily knew about each other’s existence.
So while I was at GDS in particular I was trying to dig out where all these product managers were hiding, and I’d probably say there was about 400 of them across central government alone. And again there wasn’t really any community to speak of. So my focus really at both MoJ and GDS was to try and get this product community acting like a product community.
The science behind changing behaviours
One of the reasons for this is some research I read a while back by Professor Alex Pentland. He’s at MIT. And he researches how people decide to change their behavior. And what he discovered was that it’s very difficult to give an incentive or influence people to change their behavior or habits, and that’s why people don’t quit smoking even when all the evidence is showing them in or even they’re paid to do so. As soon as the incentive goes away the effect wears off.
But what he did see was that people did change the behaviors when they saw their peers getting a good outcome from a particular approach, because then they were far more likely to copy that approach, because they thought they could get a benefit for themselves.
So part of the reason for establishing a product community was to encourage more peer learning. Because when you see somebody getting a benefit from a particular approach they’re taking in product management, my hope was that other people would want to emulate that, and share that behavior, which means that we have less of a concern if people leave the organisation.
Starting small with a weekly get-together
So I started small and I got a weekly get-together in the diary for product managers to attend. And it was fixed in time, relatively short, and attendance was optional. Essentially what I wanted to do was not to force people into this, but what I wanted is to want to come along to this. But also I recognised that people had routines and schedules already set up. So gradually over time people would start to avoid scheduling other meetings over the time slot we had for our weekly get together.
But it wasn’t a problem if they just absolutely had to meet with a stakeholder or something at the same time. You know these things happen. So relaxed but a fixed time in the diary.
A safe space – psychological safety
And we needed to have psychological safety, because it was absolutely crucial that our get-together was a safe space for the product manager to be able to talk openly about what they were doing, the mistakes they were making potentially, the challenges they were facing. And so it was very important for that to be a closed space to begin with, and to make sure that people were comfortable talking about this stuff in front of each other.
The next thing we did was to put a bit of timeboxing around this. I didn’t really want the session to become some cathartic therapy session, where people turn up and just want to have a massive moan about something or vent about whatever is annoying them that week. Because to be honest my one-to-one coaching sessions with the product managers were the place for that.
So what we’d do is we give each product manager and a team three minutes, and they’d have to cover three questions. There was like a sitting down stand up if you like. And I’d actually set a timer to keep things moving. So if all 12 of the product managers turned up plus me, we were really looking at at least 45 minutes for this, so there was a reason to keep it brief.
And of course there I always expected people to have a quick chat afterwards if there’s anything they wanted to follow up afterwards. And so this became quite an efficient way to share experience. Now the way we structured this was three questions: what have I learned that’s worth sharing; what’s the next big thing coming up for me, so a bit of almost situational awareness for the team; and I’ve got a problem – can anyone help me with this.
More interesting challenges
Now a few more interesting challenges we had to deal with at the time. So culture clash – always fun and games. Now whenever you’re disrupting or introducing a new way of doing things, there’s going to be some culture clash with the prevailing culture at the time. And as you can imagine, things were very different, there’s a very different way of organising things in the civil service. It was very much a top-down approach, and the minister would announce some policy, which would largely come as a surprise to the civil servants, who then had to somehow make it happen.
And I fully appreciate the irony of talking about that given what’s going on right now, but let’s keep that to one side. And so it’s not surprising given that it was seen, not as a core competency of the civil service at the time, that whenever something came up that needed some system it was almost immediately outsourced to one of the big providers, rather than attempting to deal with it in-house.
And these big it providers would promise a certain solution, at a certain time scale, for a certain price that met the budget constraints. That would get them selected but as soon as they were selected, then suddenly all of these budget, time scales, cost and scope would go out the window and the thing would end up costing 10 times the price and take 10 times as long.
So we’re working to change that way of thinking, because actually, with the right skills in-house, things could be done much more effectively, and actually a lot more cheaply at the same time. So this was exactly the problem we’re trying to set out to solve. But it was very embedded it was very tricky to get things to change.
A fear of delegated decision-making
Culturally, there was a fear of delegating decision making to the product teams. It just went against this top-down approach, this command and control approach that was in place. So the idea of empowering delivery teams of comparatively junior civil servants to take their own decisions, based on their own research, was disconcerting and difficult for the more senior civil servants. It didn’t help that agile working was seen as a fad or an experiment, , that was being carried out by (in inverted commas) “kids wearing jeans”.
And there was very much a thought that this would fall out of fashion and the experiment would fail. So bearing in mind that the UK government invented PRINCE2, and so existing programme management and project management offices were in a position of control and power, and funnily enough they wanted to keep hold of that control.
So it’s not surprising that subsequently agile as a concept was hijacked, and its meaning was twisted, so that essentially all of these program management processes could stay in place under the auspices of or under the banner of being agile, and hence why you’ve got these abominations such as safe, scaled agile framework for enterprise, and things like that. But anyway needless to say, a tricky culture to work with.
Winning over sceptics with open working practices
So the way we wanted to win over the sceptics was through open working. So this meant making stuff as visible as possible, being absolutely transparent in the way we worked. And sometimes it meant explaining how things worked. And so this is by this is a post that was up in GDS it was by lisa reichelt, who at the time was the head of user research there at GDS. And what she’s doing in this particular poster is explaining, for the benefit of possibly some of the actual delivery teams, but maybe just anyone else who happened to be passing by, what user research and design do at different stages of the process.
Another way of being open and transparent was doing stand-ups. And I’m sure that many of you are absolutely familiar with these. But it tended to be in front of a physical board that was always there, could always be seen, and that anyone could read if they walked past. So again it was it was trying to encourage this idea that people weren’t being private or being secretive about the things they were working on. We – all the working we were doing was in the open.
So things like putting user research findings, user personas, user stories on the walls, so again other teams could see what they’re working on potentially, oh that’s interesting we’re doing something a bit like that as well, come can you can you tell us how you’re getting around this particular problem. And it’s all about starting the conversation, getting the opportunities for peer-to-peer learning, and asking questions.
And I should I should hasten to add this is this was stuff that the teams were doing quite happily before I turned up, I am not in any way claiming any credit for this working practice. Is just to illustrate what we meant by working in the open.
An alpha roadmap to provoke more strategic thinking
Now what I think I did do was to try and get people thinking about roadmaps so here’s a real rough roadmap that I was throwing together, hence why it’s got alpha plastered all over it, because it’s literally scribbled on bits of paper and the more eagle-eyed of you will see the now, next, and later that’s probably very familiar to you as ProdPad users.
And so really what I was trying to do was to get people thinking a bit more strategically and a bit less reactively about the portfolio of digital services we were working on. And so I stuck this right up in the seating area, so where people had their lunches, and right next to the front door so it would get the maximum number of eyeballs on it. And as I said, it didn’t have to look pretty, but what I wanted is was to people to start thinking about what are we working on, how do those things fit together as a portfolio, does it make sense, is it coherent could we be doing things better, if we’re doing them in a different order, and so we can get the shared benefits from what we’re doing. So it was very much about getting things up there and getting people talking and seeing things.
Ministerial sign-off before going live
So another way of keeping things open and transparent was by sitting down and – sitting down with people and working with them in some way or another. One of the ways we do that would be to – every digital service – everything that we – every product we created before it could be sent into or a live operation and be fully signed off, it had to be demonstrated to the minister in charge, or in this case a lady called Ursula Brennan, who is the permanent secretary at the Ministry of Justice. So in effect the most senior civil servant there and the boss if you want to put it that way.
So what this meant was that things weren’t happening in a way that they’d get pushed out into the world without any oversight. What we’re doing is we’re deliberately going right to the top of the tree, right to the top of the organisation, and saying look this is something we’re doing, this is what we’ve done. We want you to see how this is going to work, we want you to see how this is going to affect people’s lives, and we want to make sure that there is no hidden or secretive aspect to what we’re doing. We’ll be absolutely open and transparent and make sure that, everyone is clear on what we’re doing and why we’re doing it.
Sharing user research findings
And that extended to our user research. So here’s Kelly helping out with the user research. She’s in one of the courts. And what she’s doing at the moment is she’s getting user research, effectively doing usability tests on what are variations of a paper form. Now the goal here wasn’t to make a better paper form, although the department that was responsible – the bit of the Ministry of Justice that was responsible for it – were in the habit of doing that, it was actually to do away with the form completely. And the only reason we’re testing out the paper form is to find out what people understand what’s easy and what’s difficult, because only then can we build a digital service to replace it, that gets around those particular challenges for the users. And this was one of the easiest, quickest ways to find that out.
And when we talked about working with people and sitting down with people to win over the sceptics here’s an example. So there’s a lady who wrote a blog article and she works for the bit of the Ministry of Justice that owns that particular service that kelly was doing usability tests in the paper forms for. And because they were absolutely sceptical of doing anything digital or agile they were quite happy just to keep iterating on the paper form, as they had done for dozens of years before. But because we got them involved, because we actually sat down with them and showed them a different way of working, they were able to win over sceptics like Maya who suddenly realised that actually there was a much better way of doing this, and that didn’t necessarily translate into a slightly better paper form.
Talking and blogging about what we did
And then of course the next area that we did to keep with things open and transparent was by talking and blogging about what we did. And this is probably some of the stuff that you might have read. I don’t think necessarily that the digital services blog as much as they used to, but what they do blog about is still worthwhile. So it’s always worth having a look to see what things are going on. I think in particular the design and user research blogs are particularly good.
Coding in the open
It may surprise some of you to see that the Ministry of Justice has a page on GitHub. Certainly it was surprising to me when I joined, actually, that they were quite they’re literally coding in the open. And as it turns out, pretty much everything created by any government digital team is open sourced by default, partly because it’s a condition to go live, but this means that we’re trying to capitalise on the benefits of not having to reinvent the wheel every single time. So because code can be reused and the idea being is if we’ve done something generic other departments should be able to take that code and reuse it, and add to it if they need to.
And also, because it’s essentially paid for by taxpayers, it’s also available to taxpayers and indeed anyone else. So all of these repos are open and available on GitHub. And I think when I checked check the other week, there’s like 63 central government accounts on GitHub, 29 local government accounts, and just the MoJ digital repository or account has got 1,200 repositories of code on there.
So if you imagine every single one of those accounts has a similar number or more of those repositories, you can understand how much code there is potentially available to people to use. Now obviously some of it’s gonna be quite specialised, but there’s certainly going to be some things in there that’s freely available and useful.
Keeping ourselves honest
So that takes us on to keeping ourselves honest – I’m just keeping an eye on the time, so I’ll move on with this. It’s probably a good idea for every organisation to have a set of guiding principles for how you create products. We had something called the digital service standard. And essentially this was things like, making sure we’re meeting user needs, providing good service, and using the right technology. And you’ll notice you can see make all source code open and so on and so forth.
Every service had to be assessed before it could go live, and this meant that we’d sit down as a panel and review every service of a particular size and above, to make sure that it was going to do what was needed.
And these reports themselves were then published and made available on the website, and you can go and see those as well. So the idea being is that we’re trying to make sure that not just we’re building the right products, but we’re building in the right way, and they’re ultimately focused on user needs and will actually solve the desired problem.
Open reporting of KPIs
And then we publish things like KPIs and performance dashboards but we’re measuring four particular KPIs: cost per transaction, user satisfaction, completion rate, digital take-up, and that thing. So again we’re trying to make things as open and transparent as possible. And here’s an example of one of the dashboards for the vehicle tax service. So when people check to see if the vehicle’s taxed they use this particular service 150 million people are using it every quarter and the user satisfaction is 89.5%, which is pretty good going.
So the last piece of the puzzle was continuous improvement about the people, as well as how we worked. So one of the things I did was to get people to do a self-assessment about where they were stronger or weaker in both the technical and the soft skills as a product manager.
And what it’s allowed us to do is, when we collated the results, we could explore how they’re doing against the average for the team, and say well okay you’re a bit weaker in these areas, maybe you can work on these in the one-to-one coaching sessions, or maybe you’re a bit more – you’re above average in this particular area, so maybe you can share some knowledge with the other product managers, either as a show and tell or show the thing.
And part of that was doing the show and tells. Lisa Reichelt again, who has now since gone to Atlassian, always talked about showing the value of – showing what you’ve done over talking about it. So we had these sessions called show the thing, and this is where we’d spend half an hour each week spending 5-10 minutes talking about something we’ve learned, or something we’ve done or built. And the emphasis was very much about getting other people to see the benefits of what we’ve done and being able to ask questions and that thing. And again we get three or four show the things into 30 minutes, so it’s relatively quick and timeboxed.
Team and organisation retrospectives
We also had retrospectives after each set of sprints, as you’d expect, but probably more uniquely, the whole organisation, the whole digital service team, so about 150 odd people, would get together and do a retrospective every quarter. And this was about how we aas an organisation can do better at what we’re doing.
What to take away from this talk
So here are the takeaways then it’s taken us about eight years plus to get to this point where people are no longer questioning the agile or user-centric way of working as being a fad or an experiment, and the only reason that’s happened is there’s been a lot of hard work by dedicated, motivated people, over a long period of time.
In the context I’d been in total in government for maybe one of those eight years, and culture change by definition takes a long time. So while agile may no longer be seen anymore as a fad, the problem is that its meaning has been hijacked and subverted a bit, so it doesn’t make sense anymore to use the term agile, because it now means something completely different, the SAFe diagram you saw earlier is an indication of what people seem to think agile means these days. It’s not about the process, it’s about being responsive to feedback, and being able to do something with that feedback in your in your products as quickly as possible.
Start with the people
So really I think if you were in a position where you’re trying to get some culture change to happen in your organisation, the first place to start is with the people. Because it’s the people and their continuing effort, that are really going to make the change. You need to work as openly as you can do. I’m not saying expose your corporate IP and company secrets to the whole world, but I’m saying work as openly as you can do within your organisation. And if you can work openly with your customers as well, then that’s going to be even better.
Keep yourselves honest
I think you need to try and find a way to keep yourselves as honest as possible through peer reviews, through publishing results, by not shying away from the things that you could do better, as long as you are able to demonstrate what you’re doing to do them better. And it suddenly becomes a lot harder for people to criticise you if you’ve already made the point yourself and then explained how you made it better.
Always try to improve
Always try to find ways to improve yourselves, in terms of teaching yourselves, learning from each other, building yourselves up as a community, but also how you can improve the way you’re working as an organisation. So beyond the product management community and to other communities and as an organisation as a whole.
What can you do to remove some of the roadblocks or impediments that you’re seeing, not just within your teams, but as an organisation? If hiring is taking a long time, what can you do to speed up the hiring process? If on-boarding people is really difficult, what can you do to make that better? And so really focusing in on and doing these retrospectives, and then doing experiments off the back of those retrospectives to see if you can improve things is really valuable important.
Changing organisational culture takes time and dedication
So culture change is possible but it takes time and it’s only through tenacious, dedicated people working really hard over a long period of time that you can actually get things to stick and become habitual. But you know what? It is worthwhile and the results do speak for themselves hopefully.
So that’s what I had. Thank you very much for listening and I will be happy to take any questions.
Working in the open during COVID-19
[ANDREEA] So her question is: the working in the open concept. How would you recommend that continues through COVID?
[JOCK] Oh okay so COVID is one of those things I think that has forced everyone to make an even bigger effort than before on communicating. So whether it’s keeping up the communications within your team and through video calls or whatever else. Whatever you’re doing before to work remotely or to communicate, you have to do even more of.
And I think that goes the same for communicating about what you’re doing and working in the open. So fine you can’t all gather in the same place, and you can’t see the physical boards anymore, what can you do to make the information available digitally, and make it as accessible as you can do virtually. You know I’m not saying necessarily this is the best way of doing it but I’ve seen teams who would literally have a webcam on some of the some of the things they’re working on so you could remind you right remind themselves of what people were looking at. Now obviously if no one’s at the office updating the thing that doesn’t really help.
But if you do have things like, I don’t know , something on Miro or something on a Trello board, or some online collaborative system, then there’s it’s never going to be as good, because let’s face it everything that we’re having to do remotely and virtually is a compromise from being in person, but I think just finding the best ways we can to over-communicate and compensate for this virtual nature, I think, is all we can do, and we just have to make the best of it. I don’t have any magic solutions for that but I think everyone’s in the same boat at least.
Recommendations of tools and method
[ANDREEA] On this next question is: which specific methods or tools would you recommend starting with in a company that has a new and small product team?
[JOCK] You know what? I would say to start with don’t worry about the tools or the methodologies, because really what you want to think about most is the mindset you’re going into something with. And the reason I say that is not because I don’t think there’s value in some of these tools and frameworks, but often people get hung up on deploying the tool over thinking about what it is they’re trying to achieve.
So to when I had those 12 product managers and their respective delivery teams, they all actually use completely different tools, and completely – well not necessarily completely – different but generally different methodologies to achieve what they’re trying to do. So some would do a variation of Scrum, some would do variation of kanban, some people do a hybrid of the two, some people do something completely different.
The idea being is that you need to look at the circumstances, the context you’re in, and decide what tools and what approaches are going to help you solve those specific problems. So that’s why I’m loathe to recommend anything in particular because what works in one situation doesn’t necessarily work so well in others. But it’s really boils down to, can you figure out what are the challenges your team is facing, and what are the tools that can be best placed to help you, and what’s going to be the methodology that’s going to help you most in that situation.
So maybe to give you a little bit of example rather than being a bit evasive and not answering the question properly. If you’re doing something that’s relatively certain, so roughly what you’re going to be building and how you’re going to be doing it, using something like Scrum is great because you do two-week sprints, and then you can change direction every couple of weeks. But if you’re dealing with something that’s a bit more uncertain, so you’re not really sure what technologies you’re going to be using, something like kanban can help because the time it takes to go through a cycle, and therefore to be able to change direction in response to feedback, can be as short as a day or less, because it’s literally the time it takes for an item to get from one side of the board to the other.
So depending on, I guess, how uncertain the thing is you’re working, will help to dictate to an extent what methodologies, even within the agile world, will be more appropriate or less appropriate to use. And then you can start looking at tools to help you run those particular methodologies more efficiently.
Interesting feedback from ministers
[ANDREEA] Were the ministers able to provide you with interesting feedback?
[JOCK] Oh yeah interesting, yeah. Was it the feedback we’re looking for? Not always! As with anything we had a real mixture of people. Now broadly speaking actually once you actually got in front of the more senior people, as long as you could show them how that was going to help them enact the policies they wanted to make, then generally they were they were quite supportive. Now clearly when politics started to play a part in this, it became a bit more tricky.
But what you have to also remember is that iin parallel with what we’re doing with the digital teams, there was like a groundswell of attempts to bring a bit more, I guess almost like user research and almost, I dare to say, product management to policymaking. So instead of the whole idea of like the first you hear of a policy is when the minister stands up in the house of commons and declares that something is going to happen, and we’ve all seen examples of that recently, instead the minister would work with their teams down the organisation to figure out what is the problem we’re actually trying to solve, and therefore what should the policy be that we put in place to solve it.
But it’s very difficult to break with hundreds of years of tradition or habit at least, if not if not necessarily. So sometimes we had like really supportive ministers, who would give us great feedback and they could see that this was going to be absolutely useful to what they’re trying to achieve, and what they’re doing for their constituents.
But sometimes people go, yeah that’s not what I wanted because that’s not what I personally would have done, that’s not personally how I have designed it, because they haven’t quite got their head around the whole user-centric thinking, the whole way of putting the problem first and then solving that, rather than putting the solution first and then retrofitting something and trying to solve it that way.
So it’s a bit of a mixed bag really and as you can see across government if you just look at the UK, there are good examples and there are bad examples. You tend to hear more of the bad examples because they’re the ones that make the headlines
Benefits of communities of practice
[ANDREEA] You mentioned trying to nudge people into coming to community of practice meetups.
[ANDREEA] By presenting benefits. What were the most common benefits that you saw?
[JOCK] Oh it’s really difficult to it’s really difficult to put my finger on it. But there’s a subtle change that happens when people stop acting as individuals and acting as a group of people with a with a shared goal. And it’s a little it’s a weird one to describe.
It’s quite subtle, but it’s little things like: rather than individuals waiting to talk about things with their head of product in one-to-ones, they’d almost take the initiative and just go and talk to someone else in their team. So peers, rather than line manager. And whilst that’s a subtle shift, it makes a dramatic difference on, first of all how information gets spread around, but also how quickly things how quickly individual people’s challenges can be resolved.
There’s also a sense of ‘we’re in this together’, which you don’t necessarily get to begin with until the community starts forming. And that also I think which is something that we’ve seen over and over again. I mean just look at the broader product management community that’s sprung up over the last eight or nine years or so.
And just seeing the benefits when suddenly you realise oh there’s a whole bunch of people who have actually been through this as well. I’m not on my own, I’m not the only one experiencing these problems, I’m not I’m not going mad, this is just difficult. And there are certain hacks and ways of getting around this that other people have maybe managed to figure out that they can share with me. So I think that the benefits really I think start to multiply.
And you start to see more of an effect when suddenly as a head of community or as a head of products or whatever else, when you suddenly realise you’re not pushing anymore you’re not putting the effort in to keep rolling the thing along, it’s actually taken on a momentum of its own and people are just taking initiative and doing things for themselves. They’re doing their own meetups, they’re doing their own talks, they’re doing their own little mini get-togethers, on a particular topic , that’s the point at which I think you start to see the real change happening. And it’s quite a nice place to be. It takes a little while but it’s a nice place to be.
Balancing cost versus value to users
[ANDREEA] Product teams are expensive and government doesn’t have the commercial drivers. How did you balance cost versus value to users?
[JOCK] So well in the context it was comparatively easy to demonstrate the value of a team that was able to deliver something in between 9 and 18 months, over the cost of something that had been outsourced to one of the big IT providers that wouldn’t get near users in a live environment for at least three to four years, and would cost ten times even more the cost of doing it in-house.
So it was – bearing in mind that GDS (Government Digital Service) was set up primarily with cost control authority, so really it was a way of stopping things being done in a very expensive and actually not very effective way. And all of the other stuff that came after that was almost a happy a happy coincidence.
But really it’s not that difficult to come in cheaper than the big IT providers of this world with something that actually works, if you’re taking the approach where, from the very outset you’re testing ideas out with the people who you expect to be using this, and continually checking if you’re on the right track. If the first time you’re checking whether or not the service or the product you’ve built is right, is like three or four years down the line, how on earth are you supposed to build something that’s that works?
So you don’t necessarily save money by from the cost of the teams working over a period of 9 to 18 months, because as the person asking the question said, they cost money too, but where you do save the money is effectively not having to take that 9, 18, 2 years’ worth of work and throw it away because it doesn’t do anything of any use to anyone. That’s the fundamental difference. You know you’re still paying the same amount of money, you’re just not chucking it all the way after two years.
Product and project management working together effectively
[ANDREEA] How do product and project management disciplines effectively work together – don’t you just love this already? – particularly when like a Venn diagram there are often overlapping responsibilities?
[JOCK] So if for example you’ve got someone who – and I should I should point out I did a very basic qualification in PRINCE2 a while back because I wanted to understand what I was dealing with myself – and it is perfectly possible to get a good result when and deliver really great products, in a nice effective way when you’re working with a project manager, providing you’re on the same page, and you’re all thinking in the same way.
If project management is seen as essentially a set of controls to be placed upon the team, because essentially the team isn’t trusted to do things by itself, and doesn’t have any autonomy to take its own decisions, then the issue isn’t the fact that using project managers or project management methodologies, the issue is that the team isn’t trusted to do the thing. And so that’s why it doesn’t work.
If however you’ve got a project manager who understands and empowers the team and effectively helps them to be as efficient as possible, then it can work very well. Within PRINCE2 there’s a concept of tailoring, I believe, which allows essentially the process to be altered as needed to suit the needs of the team and to help them work in as an efficient way as in as efficient or way as possible.
And so what that basically means is, rather than just throwing the process book at every project and making every project just tied up in red tape, you can take the more enlightened approach of saying what does the team actually need to do their job, and what’s the minimal amount of process that we need to allow them to do that. And if that’s coupled with we’re going to trust and empower the teams to take their own decisions, then suddenly all of the associated problems that come with a very rigorous, or a very detailed, or a very paper-heavy process melt away.
And in actual fact when you look at the what they call delivery managers in government – and they call them delivery managers because they’re not necessarily doing Scrum, not necessarily doing agile, they’re not necessarily doing Waterfall, they are just the people who are there to help the team do the thing – their mindset is very much one of collaboration, of coaching the team to be more effective, of clearing away obstacles, to almost be like a servant-leader to the team, rather than the person imposing the controls, and forcing them to do a document, and do all this laborious stuff that actually detracts from the time they’ve got to build the thing.
Now if you’ve got a delivery manager or somebody, a project manager, who’s working in that delivery manager way, you’ve got no problem, it’s not an issue, and things can co-exist happily. Where I always saw the problem was where you had a power base in a programme team or a project management office team that resisted the change, and essentially reasserted their power within the organisation by forcing a particular process to be used, even if it wasn’t the right thing to be doing. That’s I think where part of the thing we were fighting against to an extent, which was blindly following a process even if it’s not the right process to follow.
So as I said it depends because you can have perfectly good project managers, who can work in a really supportive way in the same way as you can have product managers, who can have a really closed-minded way of working and blindly follow a methodology even if that iterates you into a brick wall at the end of the process.
Softer measures of effectiveness
[ANDREEA] As well as things like cost per transaction, did you try to measure any softer measures of effectiveness?
[JOCK] Those four KPIs were the ones that, where it made sense to do so, so for the public facing transactional services and so on, those were like the four ones you absolutely had to measure. Absolutely, if you need to measure other stuff as well there’s nothing stopping you. In fact the performance dashboards could put up whatever metrics you want to do frankly.
And clearly the on the operational side, you’ll be monitoring stuff like is a service up and running, is it do we need to be thinking about increasing the amount of storage, or the amount of CPU available to the surface. You know all the operational stuff as well. So yeah absolutely teams would set their metrics based on first of all what was important as a success metric for the service from a user perspective, but also what made most sense for them to be keeping an eye on.
So for example if you can imagine the spike in traffic that the Registered to Vote service got when just before an election, the people monitoring that service would make sure that absolutely the operational stuff was there, and they were making sure the thing was responding quickly, and there’s enough capacity in the service to actually meet the demand that was coming along.
So absolutely it wasn’t that we only ever measured those four metrics, they were the bare minimum you had to measure and then you measured whatever else as you would do in any other product management scenario.
Get articles when they’re published
My articles get published irregularly (erratically, some might say). Never miss an article again by getting them delivered direct to your inbox as soon as they go live.
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”— Lyndsay Denton