When it’s not about user needs or human centric design, but instead about fixing technological infrastructure.
When it’s not about transforming the service but keeping the lights on systems.
When it’s not about asking “why?”, because you already know the solution you want.
As Tom Loosemore said, Digital is applying the culture, practices, processes & technologies of the Internet-era to respond to people’s raised expectations.
There are lots of conversations online about being digital, not doing digital. Digital is not a process, it is a cultural mind-set.
It is a way of asking questions and prioritising needs. It’s about delivering value and designing services that meet user needs and expectations.
Now and then you can still see organisations that use Digital as a label when they mean technology or IT.
However, those things are not interchangeable. The culture and mindset of of the teams of the teams, and the organisations itself, is very different.
In organisations that use digital as a label but are not embracing what it means to be digital you will still see a separation between change or transformation and digital. They will still have siloed ways of working.
The business will still separate the programme funding, governance and strategy from the digital teams tasked with delivery.
Organisations where digital is a way of working, not just a label, you will see properly empowered teams made up of people from across the business. You will have teams who ‘own’ the holistic service they are delivering from strategy to delivery.
These are organisations where the multidisciplinary team isn’t just something that digital ‘do’ but the whole organisations embraces.
This comparison between Digital and Technology is equally relevant when considering the role of the Chief Digital Officer vs. a Chief Technology Officer or Chief Information Officer. There’s a good discussion of the various roles here. As with the other roles the Chief Digital Officer looks after an organisations data and technology assets. However, they go one step further and have a wider eye, considering the strategy and the possibilities for innovation and wider transformation. Their focus is not on keeping the lights on, but understanding why the lights are needed and are there any other options?
For me this sums up why digital is wider ands more far reaching than Technology, and why the Digital mind-set and culture is so important to get right for organisations trying to deliver transformation. And why, if you don’t have these things right, if you are digital in name but not culture, you are going to struggle to deliver real transformation.
I’ve been working within Digital transformation for almost ten years now, working on some of the largest projects and programmes within the public sector. From front line services to backend systems, from simple forms to complex benefit processing applications.
One thing that has been a feature of every product or service I’ve been a part of has been the business case. Over the years I’ve worked to challenge and transform the business case itself, making it more agile and less cumbersome, in multiple organisations.
Traditionally business cases have been built on the preconception that you know exactly what solution you want, with the costs and timings estimated accordingly. These behemoth business cases usually clock in over 25 pages long, with very little room of flexibly or change. The millstones in them are clearly laid out and everyone sits around clapping themselves on the back for delivering the business case, and then wondering why the Product itself never gets delivered.
In the last decade as the more agile methodologies and user centric ways of working have spread the traditional business case, and the role of those individuals who are focused on their development, has struggled to keep pace with the changes happening within the projects and programmes themselves.
The traditional method of drafting business cases that map out your road map and spend in full are now antiquated, and holding back teams from delivering. New business cases need to instead focus on agreeing design principles and the problem the business is trying to fix rather than bottoming out the minutiae of the roadmap. On explaining the assumptions that have helped define the scope of the Product or programme, which can be backed up by evidence , this is worth more than a cost estimate hammered down to the pounds and pence.
Before doing Product evaluations it is vitally important to ensure all senior stakeholders agree on the assumptions the team is working too (regarding the scope, business needs, user needs etc.) And these are the things new business cases should be focused on, not jumping straight to a solution based on product comparisons that have been carried out before everyone has agreed what is in scope.
One anecdote in particular has always stuck with me, in terms of why it’s important to agree your scope, before you start comparing products.
A few years ago, back when I was working with the Office of the Public Guardian on their CRM replacement, the team at the time did some research and analysis into the best options for the business and whether they should be looking to build, buy or configure a new system.
As the business wanted to be a digital be default exemplar, there was an early assumption that the new system would only need to ingest data received via digital channels, or call data for the minimal cases that couldn’t be dealt with digitally. This led to some early product comparisons being done, into Products that would meet the business’ requirements.
However, some research and conversations with legal SMEs during the Discover period highlighted that, as the OPG had responsibilities as a safeguarding body, they needed to be able to accept and analyse data received via any source. Which meant they actually needed a system that could ingest and understand faxed data, call data, digital data and handwritten data. The ability to ingest and assign meta data to handwritten data meant some products that had actually been in consideration now had to be ruled out.
Thankfully the business case for the CRM system had been developed with enough flexibility and empowerment and trust within the programme team, that this did not dramatically slow down or derail the team in terms of delivery as they were still working within the agreed scope and cost envelope, but the Product Comparisons had to be reconsidered and the scope and cost estimates changed accordingly.
While this was a relatively small example, it highlights the importance of validating scope assumptions before pinning down your business case.
Many organisations embracing Digital and agile ways of working have struggled with how they can fit the need for traditional governance structures, and especially the business case, into the culture and ways of working that Digital brings with it. My honest opinion is that you can’t.
Instead, there has been a movement in some areas, led by the likes of GDS and MoJ which I have been apart of and leading conversations along with others on for some years, to change the role and format of the Business case. To encourage the business case itself to be developed and iterated alongside the Product and Programme it supports. This approach to iterate the business case alongside the agile Project lifecycle was first laid out by GDS back in 2014 for digital transformation programmes. The Institute for Government did a report back in October 2018 on how business cases were used, and what could be improved to enable better delivery.
Rather than a business case written almost in isolation by a Programme Manager before going round and round for comments, there is value in treating your business case like any other output from the a multidisciplinary team.
Instead of a 25+ page tome that aims to spell everything out upfront, before the project even commences properly, there is much more value in simply having a couple of pages explaining the problem the project is seeking to fix and why, along with estimated timing and costs for some exploratory work to define key assumptions and answer key questions (like what happens if we don’t fix this? How many people will it effect? Are there any legal requirements we need to be aware of?) that will help your project start on the right foot.
Once you can answer those questions, then you can iterate the business case; taking a stab at estimating how you think you might going about fixing the problem(s), how long it will take to fix the important key problem(s) you identified need fixing first, are there any products out there in the market that could do this for you? How much might this roughly cost?
You can then iterate the business case again once you’ve started developing the Product or implementing the identified solution. Once you have validated the assumptions you’ve made previously about the solution to the problem you’re fixing.
This means the business case is a living document, kept up to date with the costs and timetable you’re working to. It means your board are able to much more accurately assuage their accountabilities, ensuring costs are being spent in line with the scope of the programme or project.
Whatever methodology you are using, the importance of being able to explain why you are doing something, and what the problem you are trying to fix is, before leaping into what software product is the solution to buy and how much it’ll cost you. If it’s done right, the business case helps you evidence you are doing the right thing and spending money in the right way.
Hi, I’m Zoe and I’m a NeuroDiverse Senior Civil Servant.
Last week I attended Civil Service Live, it was an interesting day, with sessions on everything from AI and keeping abreast of new technologies, to Transformation to resilience and personal wellbeing. The session that stood out most for me was the “Making Government an event greater place to work” which was an interesting session featuring several people talking about their own mental health, and colleagues from DWP’s Diversity and Inclusion Team talking about the work they have been doing to make invisible disabilities more visible.
The team has been working with neurodiverse colleagues to make short videos to help neurotypical colleagues understand their disabilities. This included a video on sensory processing disorder, and how many colleagues with ASD can find what some people might call normal background noise overwhelming; and another video on how some people with Dyslexia can struggle with reading, with text moving around the page.
I thought these were really useful tools for colleagues to help increase understanding, and to normalise invisible disabilities.
After the session I got talking to one of the speakers and a few other attendees about some of the mentoring and leadership schemes that exist for Disabled people, and that unfortunately these are not widely visible with a lot of people not knowing they exist or how to join them. We also discussed the need for more visible representation of neurodiverse people within senior leadership.
I was diagnosed with Dyspraxia when I was 14, and nowadays I’ve recognised (through parenting my child through the intricate diagnosis process for ASD and ADHD) that I probably have ADHD as well and am now in conversations with my GP to get a referral for an assessment.
When I first joined the Civil Service (technically as a temp back in 2002 before I went to university) I was doing a data entry job, and when I admitted to a senior manager that I had Dypraxia he told me to keep it quiet or everyone would wonder why he’d hired me. Having a learning disability was definitely seen as a barrier to progression.
I remember when I joined the Ministry of Defence as a Fast Streamer back in 2006, I looked at the data for the Senior Civil Service at the time and realised that less than 3% of colleagues in the SCS had a disability, and of those, the number who were declaring a non-physical disability was in single figures (in the MoD at least). At that time, I made the decision that I would do everything I could to reach the SCS, so I could help change those stats.
Until a few years ago I’d never met an SCS person who I knew was neurodiverse. I was talking to a senior leader asking for advice on speaking at conferences as it was something I’ve always struggled with in terms of confidence, and he admitted that he was Dyslexic and couldn’t read of prompts, so would always have to learn his presentations by heart. This was someone I had known for over a year, and it felt like I was being told a secret that they were ashamed of, but it made me feel hope. Here was this person 2 grades above me, who also had a learning disability. It was possible.
Several years ago at a leadership development session designed to help G6 colleagues pass the SCS application tests, one of the senior colleagues stated that “anyone can just learn to do maths with a little bit practice”. I ended up speaking up and saying that “as someone with a learning disability I found that kind of sweeping statement very unhelpful”. After the session I had another colleague approach me and ask if I could provide some mentoring to one of their members of staff who had Dyslexia and wanted to progress in their career but they weren’t sure if that was possible given their disability, and my colleague believed that talking to another neurodiverse person might help their confidence.
Over the years I’ve mentored perhaps a dozen people, some through official schemes, but just as many have approached me and asked whether I would mentor them as they themselves are neurodiverse and there aren’t that many senior leaders out there who own up publicly to having a learning disability or being neurodiverse. As such people feel that there aren’t people in senior leadership positions who have learning disabilities or are not neurotypical.
Within the Civil Service and wider public sector we are doing more now to normalise Disability, there are great leadership and development schemes like the Possetive Action Pathway out there now to help build capability for Disabled colleagues or recruit more neurodiverse people. DWP and HMRC have been running Autism work placement programmes, GCHQ has it’s “Positive About Disabled People” scheme and there’s the Summer Diversity Internship programme; Diversity and Inclusion networks across the Civil Service are working to help support Disabled colleagues, and schemes like the ‘Workplace Adjustment passport’ are a great tool for disabled colleagues and their managers.
But I still believe we need more visible neurodiverse senior leaders, and leaders with both visible and invisible disabilities. Figures from 2018 show that still only 5.4% of SCS colleagues have a disability. I couldn’t find any data on the percentage of those colleagues whose disability was visible, invisible or both, but it’s safe to say we need to normalise neurodiversity at all levels.
For those of us who are neurodiverse in the Senior Civil Service, we need to speak up and say to our colleagues that we are here. It is possible. We bring something to the table, and so do you.
The event was focused on how digital has transformed governments across the world, sharing best practices and lessons learned. With speakers from the founding of GDS, like Lord Maude, as well as speakers from the Netherlands, and it was a great opportunity to meet others working on solving problems for users in the Government space wider than the UK.
A lot of the talks, especially by the GDS alum were things I had heard before, but I actually found that reassuring, that over 5 years later I am still doing the right things, and approaching problems in the right way.
It was especially interesting to hear from both Lord Maude, and others, about the work they have been doing with foreign governments, for example in Canada, Peru and Hawaii. The map Andrew Greenway, previous of GDS now from Public Digital, shared of the digital government movement was fantastic to see, and really made me realise how big what we are trying to achieve around the world really is.
The talks from some of the Dutch speakers were really interesting. I loved hearing about the approach the council in The Hague are taking to digital innovations, and their soon to be published digital strategy. One of the pilots the city are running in particular intrigued me; in an effort to reduce traffic, they put sensors onto parking spaces in key shopping streets and all disabled parking bays in the city. This gave them real time information on the use of the parking spaces, and where available spaces were and successfully decreased traffic from people driving around searching for spaces. They were now looking at how to scale the pilot an manage the infrastructure and senor data for a ‘smart’ city, working with local business to enable new services to be offered.
We also heard about the work the Netherlands has been doing to pilot other innovative digital services, like a new service that allows residents in an area to submit planning ideas to improve their neighbourhoods, with the first trial receiving over 50 suggestions, of those 4 have been chosen to take forward. We heard about the support that was given to enable everyone to take part, and it was nice to hear about the 78 year old resident who’s suggestion came 5th.
It was also great to hear from the speaker from Matthij from Novum, a digital innovation lab in the Netherlands, who talked about his own personal journey into Digital transformation, learning from failures and ensuring that you prepare for failure from the start. He also told us about some fascinating research they have been doing into the use of smart speakers, especially with the elderly, to enable better engagement and use of government services to those that need assistive technologies.
Realising that 30% of eligible claimants for the Dutch state pension supplement were not claiming it, they believed that this was potentially down to the complexity of the form. They hypothesised that smart speakers might be one way to solve this problem. However recognising that it was no good to make assumptions and design a solution for users without ensuring they had understood the problem their users were facing properly they did a small sample test with elderly users to see whether they could use smart speakers to check the date of their next pension payment (one of the largest contributors to inbound calls to the Sociale Verzekeringsbank), they found that not only could elderly users use the smart speakers, but that the introduction of smart speakers into their homes decreased loneliness dramatically.
There were other good sessions with James Stewart from GDS & Public Digtial on technology within digital, and an interesting panel session at the end. Every session was good, and I learnt something I heard something new at each one. My only grumble from the day was the lack of diversity in the speakers. Which the organises themselves put their hands up and admitted before they were called out on it. A quick call on twitter and the ever amazing Joanne Rewcaslte from DWP shared a list of amazing female speakers, so hopefully that will help with the next event.
One key thing I took away from the day is that the challenges are the same everyone, but the message is also the same, involve users from the start. In the practical steps everyone could start tomorrow, Matthij talked about ensuring you interview 5 end users, and some steps to simple prototypes you could develop to engage your users.
Lord Maude talked about the importance of a strong mandate, Novum talked about having a good understanding of the problem you are trying to fix at the start. The digital strategy from the Hague highlights the fact they want everyone to be able to participate and deliver a personal service to their citizens. As Andrew Greenaway said, they key thing is to “start with user needs”.
The other second key message from the day was that, as Lord Maude put it… “Just Do it!” A digital strategy delivers nothing, the strategy should be delivery, instead of spending months on developing a digital strategy, “you just have to start” by doing something, this in turn will help you develop your strategy once you understand the problems you are trying to solve, the people you will need, and the set up and way of doing things that works best in your organisation. This was a message reinforced by every speaker throughout the day.
The third key message was the importance of good leadership, good teams and good people. Talk in the open about the failures you’ve made and what you have learned. Build strong multidisciplinary and diverse teams. As Andrew Greenway said, Start with teams, not apps or documents. In the round table discussion on building capability we spent a lot of time discussing the best ways to build capability, and the fact that in order to get good people and be able to keep them, and to go on to develop good things, you need strong leadership that is bought in to the culture you need to deliver.
I left the day with a number of good contacts, had some great conversations, and felt reinvigorated and reassured. Speaking to Worth I know they are aiming to run another event next year, with both an even more diverse international cohort and an equal number of female speakers, and I for one will definitely be signing up again for the next event.
As I sat listening to the conversations happening at the Women in Digital event on Wednesday, it occurred to me that although the point of the day was around creating more opportunities and continuing to support women working within digital, so many of the things that we talked about are also applicable outside of the digital industry.
One of the main points of discussion was how we can create opportunities. Opportunities through recruitment, promotion, to step up or work in new areas, to train and learn new skills, chances to take part in development programmes, attend conferences or speak at events. Opportunities for mentoring, to be a mentor or even just to job shadow someone. Those opportunities can come in all shapes and sizes and one of our roles as leaders is to make sure we’re creating those opportunities for people.
At the start of the event @Aaronjaffery mentioned that within the last year, DWP Digital has recruited for 9 new Senior Civil Service roles. For those they had almost 300 applications from men, but only 60 applications from women. However, of those 9 roles, 6 were filled by women who had applied and only 3 went to male candidates. This shows that the opportunities are out there but we need to work on encouraging women to apply for opportunities when they do arise. So what else needs to be done?
The right culture
We need to create the right kind of culture: the kind of culture that allows you to ask for help, to challenge things that you think aren’t working right, to admit that you’re not doing ok and need more support. The kind of culture that encourages people to check in with each other. @CheryJStevens did a fantastic keynote speech about her return to work journey a few years ago, the help and support she needed and the practical steps she took to successfully reintegrate into the workplace. As she so perfectly said: “It’s ok to not be ok, and to ask for help.” This message from a senior leader is really important and something we need to hear and talk about more.
Paying it forward
No one gets where they are without help and support, so it’s important to create an environment where you can pay that forward. For leaders to make themselves more available, offer coaching and support – creating those opportunities. It’s been nice to hear what organisations have been doing to create opportunities and the right culture for women to thrive in digital. It was great to hear from @ReneeNo17, Director of Digital Platforms at Sky, about their Returners Programme aimed at helping women return to work after career breaks, and the work they’re doing to increase diversity and be more inclusive. I know things like Digital Voices and Crossing Thresholds exist in the public sector to help women develop their skills, but we need more of this.
Whether it’s following a promotion, helping someone progress in their career or supporting someone returning to work, one of the key themes of the day was around people who have had their confidence knocked and needed to rebuild their faith in themselves. Running sessions that bust myths about who makes a good programmer and what skills they need was a good start. Following that up with opportunities to learn the basics of code in work was even better. It was great to see @SarahInTalent at the event, taking about @WILD_igital, a community in Leeds that was set up to grow and retain women in digital roles in the city. Schemes like Digital Voices where women can support each other to learn new skills and take up new opportunities are a great example of how DWP Digital is helping build skills, but all the women today cited how, most importantly, it has helped them build their confidence.
One of the reasons I love coming to events like Women in Digital is because they’re all about building support networks, and I think they are so critical to all of us. Good networks give you all of the things I’ve talked about here. They can support you, build your confidence and encourage you. They can help you access new opportunities.
The other positive about networks is you can belong to many – none of us only wear one label. Intersectionality is important when considering things like how we get more women in digital, as we don’t want to only get more white women, or straight women, or women who went to Oxford University. It was great today to hear from lots of different women about their journey, and it’s always good to be able to hear about and consider perceptions and experiences different to our own. I want to keep widening that circle. Our networks can work together to build each other up.
For me, days like today let me check in with my ‘tribe’. Even when we’ve all been busy, events like this are an opportunity to set aside time to focus on yourself and your development and see what is happening in the wider world, to consider that wider bubble, to challenge your assumptions and keep adding to your network; and that is really important. We gain skills and develop ourselves the more we work together to share our knowledge and experiences.
Over the last 6 months or so I’ve been percolating on what good leadership looks like, at least to me, and how I can make sure I am acting like the good leader I would want to see.
There’s been lots of good thought pieces and conversations happening about good leadership over the last year or so. Kit Collingwood’s blog on Empathetic Leadership in the civil service being one, and there was a #OneTeamGov workshop a few months ago where we discussed what makes a good leader, so I know I’m not alone in considering the subject.
For me there are a number of traits I look for when I consider whether someone is a good leader, and on a personal level, could I work for them?
Empathy is the fist, given the field I work in, empathy is key. We have to try and understand the experiences of the users of our services, be able to recognise our privilege and still empathise with people who’s experiences are different than our own.
Active Listening is the second, I’ve encountered a number of leaders over the years who do a good job of acting like they are listening, but as soon as they have left the room that conversation is forgotten. Their opinions seem to change with the wind depending on who they have talked to last. The ability as a leader to actively listen, to try and understand what is being said and why, is fundamental in being a good leader.
Approachable, for me Leaders have to be approachable, I have to be able to discuss things with them, come to them with concerns and ideas.
Authentic, I find it much easier to respect people when I can trust that they mean what they say, that they are being themselves.
Personable. A lot of things discussing leadership talk about charisma, charismatic leaders etc. The cult of personality. I’d rather work for a decent human that I can relate to or get along with rather than a charismatic figure.
Encouraging. They empower those around them. They encourage them to try things. The support them to develop and grow. They trust their people. They make them feel valued.
And on a personal level, what does good leadership mean for me?
It means I can be myself.
It means I feel empowered and trusted
It means I feel listened to and heard
It means I’m more able to just get on and deliver, rather than cover my back in paper trails.
It means I’m more likely to actively enjoy my job and deliver good things.
It means I understand my value, and feel appreciated, I understand my purpose and what I can deliver.
It means I feel safe to innovate and take risks
So how do I try to model those behaviours?
I don’t ask for more from anyone than I’m willing to give, I try to set a good example, whether that’s working the right hours, recognising when people have gone above and beyond and celebrating not only success but effort.
I encourage those around me to get on and do things without waiting for my sign off, as long as they have the data or evidence to back up their decisions I make sure they know I will back them. We are all on a journey to discover and grow; it’s important to take risks sometimes when there are things we can learn.
I try to be approachable and human. I talk about my mental health. My family. I may not share with my work colleagues everything, but nor do I put up a wall or plaster on false face. I talk to people. I value the people around me and try to recognise that everyone can have bad days as well as good ones. Equally I recognise that sometimes my role as a leader is to shoulder more of that burden, to protect my teams; but rarely is that any one persons alone; knowing who you can call on for support is an essential part of being human.
I try to be transparent and honest. I admit when I know things I’m not yet able to share. I admit when things are hard. I appreciate that we all have to sometimes do things we don’t want to, that is life, and sometimes we struggle with things, we are all human.
I try to be adaptable. I accept that not everyone is the same and try to understand the needs of those around me, my staff and my teams.
I am always trying to learn from my experiences and my mistakes and perhaps most importantly I admit when I’ve got things wrong and apologise. I am always learning and growing as a leader and a person.
Are the roles of Scrum Master and Delivery manager the same?
Continuing on my recent musings on the different roles within Agile multidisciplinary teams, today’s blog focuses on the role of the Delivery Manager, or the Scrum Master, and whether these roles are really the same thing.
This is a conversation that came up a few weeks ago at the #ProductPeople community meetup in Birmingham, and something that causes quite a bit of frustration from those people I’ve talked to in the Delivery Manager community.
The role of the Scrum Master is that of facilitator within the multidisciplinary team, it is a role particular to Scrum, and they are the ‘expert’ on how to make Scrum work, often described as a ‘Servant leader’ they help everyone in the team understand the theory and practices of Scrum as a way of working together.
Within digital government the role has been widened out to include other responsibilities, and often mixed with the role of the Delivery Manager. Emily Webber did a fantastic blog a few years ago on the role of the Delivery Manger, and as she put’s it, while the roles are often used interchangeably, they really shouldn’t be.
But why not? What makes them different?
As said above, the Scrum Master focuses on the ‘how’ of Scrum as a methodology. The are the expert in the room on how best to utilise Scrum to deliver. They are more akin to an agile coach, guiding the team, and often the person best versed on the most up to date practices and ways of working.
But for me, the Delivery Manager focuses more on the ‘What’ and ‘When’. While the Product Manager (or Owner) focuses on ‘Why’ the team are doing what they are doing, the problems they are trying to solve, the vision they are trying to deliver. The Delivery Manager is looking at what could block the team from being able to deliver; what the right make up of the team needs to be in terms of roles and capabilities, what governance processes does the team have to meet in order to stay on track to deliver, and when delivery will happen.
As the Digital Data and Technology capability framework says, at the most basic level the delivery manager is accountable for the delivery of products and services. They are very much a doer paired with the Product Managers visionary thinker. They make sure things actually happen. They hold the Product Manager and the team to account and keep them on track.
They are the heart of the team, responsible for maintaining the health and happiness of the team; they understand who from the team will be available and when, making sure people are able to work well together, identifying conflicts and ensuring the team stay motivated and happy in order to enable delivery.
When you look at the role as explained in the capability framework it looks very straight forward, build and motivate teams, manage risk s and issues, ensure delivery, ok great. But then you get to the bit that merges the scrum master tole and the delivery manager role, and this is where a lot of individuals I know within the team struggle, “coach team members and others, facilitate continuous improvement and apply the most appropriate agile and lean tools and techniques for their environment”.
This is actually quite a big task, to stay on top of the most appropriate agile and lean tools and techniques requires a lot of self learning; which is fantastic, but also requires quite a bit of time away form the team you are meant to be supporting.
Most Delivery Managers that I know (certainly within CQC, and others I have talked to across Government) are involved with (if not directly responsible for) the business cases for their Products and Services. Unblocking issues, ensuring funding requests, requesting resources, etc. this all takes up a lot of a Delivery Managers time. When you are also meant to be running the daily stand-ups, managing team retrospectives, monitoring team velocity and organising show and tells you can find your days are very full.
More and more delivery managers that I know are finding they just don’t have time for the ‘people centric’ part that is meant to be at the heart of their role, as Projects and Programmes utilise them more and more as project Managers who are also scrum masters, and so our Delivery managers feel pulled in two directions, and our teams suffer because of it.
When organisations so often find they are struggling to deliver, often at the heart of that is the issue that they have not properly recognised the role of the Delivery Manager. This is a fundamental issues, especially when organisations are new to agile ways of working. Embedding ‘how’ to be agile, takes up just as much time as understanding ‘what’ you can deliver and ‘when’.
Perhaps in mature agile organisations bringing those roles together makes more sense, but for now I think we need to go back to letting our Delivery Managers focus on making sure we can deliver, and our scrum masters helping us use the right techniques to be able to delivery well.
Our numbers are growing, but what is the role, and what value does it add?
When I first took up the role of ‘Head of Product Management’ back in October 2016, I was one of the first in Government to have the title, and within a few months there was a very small band of 5 of us, who were responsible for looking after the Product Management professionals within our own Government Departments. We were professional leaders, tasked with building capability and skills, and building communities of practice. The original job description we created for a Head of Product was very different to what I do now.
In my first 12 months of the role I focused on the people, working with the others across government to develop a capability framework, training and development plan and a career pathway that Product Managers could use to develop a proper career as a Product Manager within Government.
A lot of our time was spent debating the skills Product Managers needed, and what value Product Managers brought to Projects and teams. It was, upon reflection, a very inward focused role; which given the maturity of the profession at that time made sense. But several years later user needs have changed and I think it’s a good time to reflect on the value we Heads of Product now find ourselves adding within our work, and making sure everyone understands the work some of us are now doing and why. To discuss what that difference is between what we were doing and what we are doing now, and does everyone understand and agree that difference.
This change in the dichotomy of the Head of Product role came up at our last Head of Product catch up, for those of us in role a few years ago, we have all separately found that our focus isn’t purely on developing that community and the professional skills and capabilities of Product Managers anymore.
Instead we are now focussing on Product strategies, on aiding Prioritisation of portfolios, of working with Senior leaders to break problems down, understanding the value we are trying to gain, or the outcomes we are trying to achieve through the Products and Services we are developing. We’re running roadmap workshops across directorates, debating Targeting Operating Models and strategic alignment.
Most departments are now hiring ‘Head’s of Product’ or ‘Deputy Directors of Product’ to be part of their Senior Leadership teams within Digital, and personally I think that is the right move.
As organisations mature in their agile ways of working, the role of prioritisation has become ever more important, and as Product Management professionals, the ability to weigh up data and evidence to make decisions about priorities is our bread and butter. As organisational budgets continue to be constrained we all need to get better at focusing on outputs and understanding the value we are looking to deliver through our projects and programmes, ensuring we are meeting user needs whilst spending public money wisely. Determining priorities and ensuring we are delivering value for users are the fundamental objectives of the Product Manger role, and as such it makes sense to utilise those skills at an organisational level.
We are, in fact, much closer to our counterparts in the private sector determining Returns on Investment etc. than we have ever been before. Yes, we as Head’s of Product still work with Product Managers and teams to help them ensure they are meeting the standards and delivering value, and we still look at the resource demands of teams and make calls on which person within our professional community might be best placed to work on with Product; and in some departments the community is so big that actually they still need someone to focus onleading that; but for the most part, our communities and our people have grown along with us, and most don’t need the level of support from us as community managers that they did before.
Most of the communities now across government are self-sustaining, events like #ProductPeople are being set up and run by members of the community; and while we as Heads of Product are still here to help champion Product Management, and to support the people in our communities, the role of the Head of Product Management as a community lead, has adapted and gown into what our organisations need now, someone who can use those Product Management skills at an organisational level.
As such, I think it’s time we look at the Digital Data and Technology capability framework again for Product Management, talk to community, and review the job description for the Head of Product role we initially developed and iterate that. We need to understand the role of the community lead and the need for that, whilst also recognising the value of Product Management and the skills Head’s of Product can bring to our senior leadership and our organisations.
One thing that comes up time and again from senior managers is “My focus or priority is improving Productivity”.
Early on in my career I worked on a number of ‘productivity improvement inniatives’ and sometimes they would seem to make some improvments, sometimes they wouldn’t, but they never really solved the issues and there always seemed to be more to do to ‘improve productivity’, so I began to wonder whether these projects were ready adding any value.
Nowadays when I talk to a manager to understand why they are prioritising any productivity initative, the answer is usually something like, “we can be more productive, it’ll help us cut costs and deliver a better service.” If I then ask how they plan to do this, the answer is generally “by improving our processes/ transforming our service/ getting more staff”.
Anyone who has ever been responsible for transforming processes or services acknowledges that when you introduce a change or a new way of working productivity drops, at least for a short time. This is a truth pretty much universally acknowledged. In fact lets repeat that, just to be clear, when you introduce any new change to processes, technology or ways of working productivity will drop. This can be as much as 30% while people learn the new processes, or get up to speed with any changes. This drop generally doesn’t last for too long, but it will happen.
Next, when you hire more staff, your existing high performing staff are often the ones tasked with training them and building capability. So, for those staff at least, productivity will drop while they help support and build the capability of your new staff. There’s evidence that it can take new staff 6-12 months to fully get to the same capability and productivity levels as existing staff, and that the productivity of the staff responsible for training and coaching them will be impacted as well.
This is all fine, as long as it is acknowledged upfront. If we tell people that we know their productivity will drop while they get up to speed with these new changes, or help train new staff, then we are helping to reassure them, and managing our own expectations.
But the biggest mistake I often see is a reluctance by senior managers to face that truth. We refuse to change people’s targets, we expect them to still meet the previous demands, and what happens?
First morale drops, and then productivity drops, morale drops more because people are struggling to meet unrealistic targets and then they leave or go off sick, and productivity drops further. In the end the change we’ve introduced fails or we have less staff than we did to start with and we’re actually achieving less than we did before not more. It is almost Oedipal in it’s obviousness, you can see it coming a mile off. So why do Managers do it?
For me this conversation comes down to Managers rather than Leaders, and a failure to look at the actual problem we are trying to fix.
When I work with organisations to understand the outcomes they are trying to reach, or the problems they are trying to fix, productivity is often mentioned, especially in operational delivery spaces.
But by working with both the leadership team and the people delivering on the front line, productivity itself is never really the problem. It’s the IT, or the processes, or the checks and balances we’ve put in place creating multiple handoffs, or generally a mixture of all of the above. So, we’re back to changing processes or introducing new tools or ways of working, but we’ve already said that doesn’t help, right? No.
Changing the tools or processes is absolutely the right thing to do, BUT, we have to really understand why we are doing it. Equally investing in people and training them is absolutely the right thing to do, but, we can’t solely make it all about upping productivity, because that forgets the people who are at the heart of getting things done, treating them solely as resources rather than individuals with thoughts and feelings. By telling people we’re trying to improve productivity we make it sound like they are not already being productive. By imposing change on them to simply improve productivity we are treating them like cogs in a factory and demotivating them before we even start.
Instead we need to talk to them to really understand the problems they are facing, and what blockers or issues they are having to work around to do actually their job. We need to consider their views and ideas and involve them in the process of making any changes. By empowering our people to talk to us about the issues they are facing and consulting them we are hopefully getting them motivated and invested in any changes we make, rather than making the change happen to them we are doing it with them.
We also need to look wider than one particular function or area, it’s likely that what looks like a productivity issue in one function, is actually a more systemic issue. By just trying to improve productivity in one area we are not considering the design of the whole service, but instead working ourselves into a silo.
While we may have assumptions about what changes will work, we we have to accept we may need to try out different options to really improve things, and we have to acknowledge this out loud. Again, it’s important to manage everyones expectations so that people don’t feel disempowered and like the change is happening to them.
And finally we have to reassure people that we know that for a short period of time productivity will drop and that is ok. And you know what? It is ok. Yes, we all have targets to hit, but if for 2 or 3 months every case worker out there processes 13 cases rather than 15, that is acceptable, because within 12 months’ time, if we as change leaders have done our job right, they’ll be processing over 20 cases rather than 15. And they’ll feel listened to, they’ll feel supported, and in the end productivity will go up.
But it’ll be a biproduct of successful change. We’ll have taken people with us, we’ll have learned from the work we have done, and probably given ourselves a nice backlog of things we can do to keep improving things, so that productivity can keep improving; but more importantly our organisation will hopefully be a better place for everyone in it.
So please, next time you hear a senior manager say “My focus is improving Productivity” just ask them how? And if you are that Senior Manager, ask yourself, “Why?” What is the problem you are really trying to solve? Is it really just about productivity?
We need to lead people, not simply manage productivity.
At a leadership conference recently there was an interesting debate about whether people perceived making a change or making progress to be more important.
Everyone on my table voted for making a change, my vote initially was for making progress, and so we debated what the difference was.
For me, change can be positive or negative. A negative change isn’t necessarily bad, you can learn from it, but it won’t necessarily move you in the right direction. If you don’t know what outcome you’re looking to acheive or how you will measure whether the change has had the effect you want, how do you know if the you have delivered value or not. There is little value in making changes just for the sake of it.
Progress to me means you are moving in the right direction, towards the outcomes you are looking to acheive. It can be slow, or achieved in small increments, but it is always valuable.
But both good changes and delivering progress both depend on you knowing the outcomes you are looking to achieve, and in my experience that is where organisations tend to struggle most.
They can say what they think the problems are, recognise that things are right, and be willing to make changes to help themselves make progress, but a lot of the time the changes are superficial, offering what are thought to be quick solutions to what are actually much deeper problems, and so the progress is slow and painful.
To transform an organisation and the services it delivers requires a massive change in how the organisation is structured, and more importantly how it thinks.
In my experience this change often starts within Digital, because the organisation views its technology or digital teams as not delivering. And yet the teams can not deliver because the organisation can not express the outcomes it is seeking to achieve or understand the wider problems it is seeking to fix.
This is why user research and business analysis are so important. Why we run Discoveries and encourage service design approaches that span the organisation as a whole, rather than remain within the silos the organisation has structured itself into.
These conversations can be uncomfortable, they challenge hierarchies, organisational structures and traditional assumptions, but they are there to help. Service Design and Product Management is about fostering and supporting those people able to lead those critical conversations, creating the environment we need to deliver outcomes for users and value for organisations.
Being transparent about what the real problems are, and open to new ideas and approaches at an organisational level is key if we want to change and adapt in order to make progress.
When looking to make changes its important to consider the environment we are working within. No conversation is best done via board papers or email, it is best done in the room face to face.
If we can’t move to a culture that values the time and commitment it takes to have those conversations then we must acknowledge that any progress we make will be slow and painful and not deliver any real value or acheive the outcomes we were looking for.
But for all that, recognising that change is needed is the best first step. Stepping up and admitting there is a problem that needs fixing in order to allow you to make any progress against the outcomes you want to acheive is not always easy, but it is important and something we should talk about more.
Needing to change doesn’t mean you have failed or not made progress or delivered no value. It just means you have learnt from what you have done, and recognise there is still more to do and we should celebrate that and talk about it more positively.