×

Tag: Leadership

Becoming Product Led

Recently I was asked how I would go about moving an organisation to being Product Led; when agile and user centric design are equally new to the company, or when agile has not delivered in the way that was expected.

Before diving into the how, I think it’s worth first considering the what and they why.

What do we mean by being ‘product led’?

A product led approach is where your product experience is the central focus of your organisation. Within the public sector we incorporate user centric design into our products to ensure that we deliver real value by:š

  • Taking an outside-in perspective (starting with user needs)š;
  • Rapid, early validation of ideas (testing early and often); š
  • Maturing through iteration (based on user feedback)š and
  • Disciplined prioritisation (using quantitative and qualitative data) to deliver value.

Is this not just another name for agile?

This is a question that comes up regularly; and in my opinion, no it’s not. Agile is a delivery methodology; being product led is wider than that. it’s the wrapper that sits above and surrounds the delivery approach you use. It comes ‘before’ you decide on which delivery methodology you will use; and continues long after. It’s your culture and ways of working. The two can often go hand in hand; but if agile is the how, product is the what and the why.

Why is being product led important?

šWell, by moving to a product led approach we allow the organisation to link their outputs to their customer needs and ensuring they align to their organisational capabilities and strategy. šIt also allows organisations to focus on their customers needs and understand their users perspectivesš. By understanding and focusing on user needs it allows organisations to deliver value faster, making it quicker and easier for organisations to learn from what has gone well (and what hasn’t)š which in turn makes cheaper and faster to address any issues or risksš. It also makes it easier for organisations to spot opportunities for innovation and growth.

How do you move your organisation to being product led?

First things first, a culture that empowers the asking of questions and testing of hypothesis is essential for innovation. But to allow that to happen, organisations need senior leaders who understand and support their teams to work in this way. The appropriate ,light weight/ adaptable, governance and funding approvals processes being in place are critical to enable product innovation and empower delivery teams.

The second element that’s key is having the right data. Good product orientation depends on having access to quality data; what are our current metrics? Where are our current pain points? Do we understand our current costs? What products/ services have the highest demand? etc. This data enables us to make quality decisions and measure our progress our successes.

Thirdly, we need to have clearly articulated strategy/vision for the organisation; what is our USP (Unique Selling Proposition)? What do we want to achieve? What are our goals? What value are we looking to add? What do we want to be different in 5/10 years from now?

To develop that strategy/vision, we need to have a clear understanding about our users and stakeholders. Who are we developing these products for? Who are our stakeholders? How are we engaging with them? What do they need from us?

Finally, once we’ve got the strategy, the vision, an understanding of our user needs and a set of hypothesis we want to test; we need a healthy delivery approach, with skilled teams in place to enable us to test our ideas and deliver that value. As we’ve said previously, to be product centric we need to be able to design services that are based on user needs, so that we can test regularly with our users to ensure we understand, and are meeting, those needs.

What are the sign of a good product led culture?

  • You are regularly engaging with the users; working to understand their needs and iterating your approach and services based on their feedback.
  • Your culture empowers and encourages people to ask questions. “Why are we doing this?”; “Who are we doing this for”, “Is anyone else already doing this?”, “What will happen if we don’t do this {now)?”, “What have we learnt from our previous failures/successes?”
  • Your teams are working collaboratively, policy and operations teams working hand in hand with tech/digital teams; to ensure you’re delivering value.
  • You’re considering and testing multiple options at each stage; looking for innovative solutions, and working to understand which options will best meet your users needs and add the most value.
  • Linked to the above; You’re testing regularly, being willing to ‘throw away’ what doesn’t work and refine your ideas based on what does work.
  • You’re delivering value early and often.
Prioritising the backlog

Which comes first, the Product Manager, or the product culture?

If you don’t have any trained product people, can you begin to move to a product led culture, or must you hire the product people first? This is the chicken and the egg question. For many organisations, especially those already using agile delivery methodologies or engaged in digital transformation; they may have already sunk a lot of time and money into delivery, and pausing their work whilst they change their culture and hire a load of skilled product folk just isn’t going to work; but, you can begin to move towards a product led approach without hiring a load of Product Managers. Whilst having experience product folk can definitely help, you probably have lots of folks in the organisation who are already over half way there and just need some help on that road.

One stumbling block many organisations fall over on their move to a product led approach is the difference between focusing on outcomes, rather than outputs or features.

An output is a product or service that you create; an outcome is the problem that you solve with that product. A feature is something a product or service does, whereas a benefit is what customers actually need. If we go straight to developing features, we could be making decisions based on untested assumptions. 

There are 5 steps to ensure you’re delivering outcomes that add value and deliver benefits vs. focusing on features that simply deliver an output:š

  • State the Problemš – what are we trying to solve/change?
  • Gather User Data – have we understood the problem correctly?
  • Set Concrete Goals and Define Success Criteria – what would success look like? š
  • Develop Hypothesis – how could we best solve this problem? š
  • Test Multiple Ideas – does this actually solve the problem?

When you’re trying to identify the right problem to fix, look at existing data from previous field studiescompetitive analysisanalytics, and feedback from customer support. Use a mix of quantitative and qualitative data to ensure you have understood your user needs, and their behaviours.  Then analyse the information, spot any gaps, and perform any additional research required to help you verify the hypothesis you have developed when trying to decide how you could solve the problem your users are facing.

They key element to being product led is understanding the problem you are trying to fix and focusing on the value you will deliver for your users by fixing it. It’s about not making assumptions you know what your users want, but by engaging with your users to understand what they need. It’s about spotting gaps and opportunities to innovate and add value, rather than simply building from or replacing what already exists. It’s about focusing on delivering that value early and often.

Product vs Service vs Programme?

How we define a product vs a service is a debate that comes up regularly; as proved by Randal Whitmore (Deputy Director of New Propositions at the UKHSA) today on Twitter:

In fact, it comes up so regularly, I could have sworn I’d blogged about it before; but if I have, it isn’t on here! So, what is the difference and does it matter?

If you search online for ‘Product vs. Service’ you’ll get a very dry (an in my opinion not that helpful) answer that “A product is a tangible item that is put on the market for acquisition, attention, or consumption, while a service is an intangible item, which arises from the output of one or more individuals. … In most cases services are intangible, but products are not always tangible.”

There you go, question answered!

Ok, so lets say you actually went a useful response; that is understandable; what’s the answer? The best analogy I have ever found to help describe this is one I heard Ben Holliday use once, and I’ve since stolen and reused any time anyone ever asks me this question (which is pretty regularly)!

So, let’s talk about going on holiday!

Sunglasses on a beach
Dreaming of a sunny holiday

A service is all about someone delivering the outcome you want to achieve.; its the holistic wrapper that contains all the end to end steps needed to enable you to achieve that desired outcome.

Let’s say you want to go on holiday; you can choose to use a travel agency like Tui who offer holidays as a service. Should you decide you want a package holiday, you can book and pay for your entire holiday through Tui and they will organise everything for you. Or you may decide you want to do all the organisation yourself and as such just need to book some flights, and go directly to KLM or EasyJet to book your flights. The services these companies offer are all similar (Tui will let you just book flights for example) but they will all differ in some ways; which is generally where the products that make up the service come in.

Products are the individual components that are part of that holistic service wrapper.

For our example of a package holiday; you can choose your flights; how much luggage you want to take with you, what hotel you want to stay at, whether you want to go on any excursions etc. These are all products a travel agency offer as part of their wider service; and you can choose which products you wish to use; But it’s not only that, you can also choose how you book your holiday. You can book via the app; via their website; you could call them and book over the phone; or you could book in one of their shops (well, ok not so much nowadays, but for our hypothetical example lets say you still can).

Lets say it’s the day before your holiday; A few years ago Tui released a new product; which was their App, which included lots of new features that customers could choose from. Now a days you can check in online; you can download your boarding pass to your phone; you can choose your seats; request special assistance and choose to check your bags in all before you get to the airport via the app.

white airplane on mid air
Come Fly Away

We’ve talked about the customer facing products and features that make up the holiday service a travel agency offers; but there is obviously a lot more to it than that. As part of developing each of these products the travel agencies had to think about how they would all fit together to form the holistic service. Theres also all the back end integration to think about, to offer their holiday Service Tui need to work with other suppliers (like the Airports and hotels; which partner with Tui, but are not owned or controlled by them). Should your flight get cancelled or delayed because of bad weather or congestion at the airport; the travel agency will first need to be notified, and then to notify you as their customer and give you options on what to do next etc.

When they decided to launch the App; or to open up holiday options into a new country; a programme could have been set up to manage this. A programme is one way an organisation may choose to manage multiple work streams or teams that are working to deliver something. They are entirely internal, and make no difference to the end users experience.

So there you have it:

A service is about the desired (intangible) outcome; it’s holistic and made up of many products etc.

A product is a succint (tangible) element that delivers value, it is made up of many features. A product can stand alone or alongside other products as part of a holistic service.

A feature is a componant of a product that adds value as part of the wider product but offers little value when utilised alone.

A programme is an organisational governance mechanism that can be used to organise and manage teams to deliver an outcome.

Cost vs. Quality

A debate as old as time, and a loop that goes around and around; or so it seems in the Public Sector commercial space.

Every few years, often every couple of spend control cycles, the debate of cost vs. quality rears its head again; with Commercial weighting flip flopping between Quality as the most important factor, to cost (or lowest cost) as the highest priority.

When quality is the most important factor in the commercial space; Government Departments will prioritise the outputs they want to achieve; and weighting their commercial scores to the areas that indicate Quality – things like ‘Value Add’; ‘Delivering Quality’, ‘Culture’, ‘Delivering in Partnership etc’. We will see more output focused contracts coming out on to the market; with organisations clear on the vision they want to achieve and problems they need to solve and looking for the supplier that can best help them achieve that.

When reducing costs becomes the highest priority, the commercial weighting moves to ‘Value for Money’. Contracts are more likely to be fixed price and are often thinly veiled requests for suppliers to act as body shops rather than partners with commercial tenders scoring day rate cards rather than requesting the cost for overall delivery of outcomes.

Unfortunately, a lot of the time, when the priority switches to cost over quality; we end up with a lot of projects not being delivered; of outcomes being missed, and user needs not being met. In order to cut more and more costs, offshoring resource can become the only way to deliver the results cheaply; with the departmental project teams working out of sync with their offshore delivery partners; making co-design and delivery much harder to do, and making it almost impossible to achieve the required quality. This goes in a cycle, with Departments toting and grooming between “offshore as much as possible to cut costs” and “the only way to deliver quality is for everyone to be collocated in the office 100% of the time”. Full collocation of the teams inevitably driving up the costs again.

So, does that mean in order to get quality we have to have high costs? Surely there is an obviously a sweet spot we’re all looking for, where cost and quality align; but why does it seem so hard to achieve within the Public Sector and what do we need to be looking at to achieve it?

When the government commercial function (and GDS) shook up the public sector digital world over nearly a decade ago they introduced things like the Digital Marketplace and implemented the Spend Control pipeline; with the aim of moving departments away from the large SI’s that won 90% of government contracts. These suppliers often charged a fortune and rarely seemed to deliver what was actually needed. (This blog gives the details on what they intended, back in 2014).

Lots of SME suppliers began to enter the market and began to win contracts and change up how contracts were delivered, as completion increased, costs decreased; with quality partnerships forming between new suppliers and government departments; and the quality of delivery increased as new options, solutions and was of working were explored.

However, this left Departments managing lots of individual contracts; which grew increasingly complex and time consuming to mange. In order to try and reduce the number of contracts they had to manage; the scale of the contracts began to increase, with more and more multimillion pound contacts emerging.

As the size and value of the contracts increased, SME’s began to struggle to win them, as they couldn’t stand up the teams needed quickly; nor could they demonstrate they had the experience in delivering contracts of that scale; which became a bit of a self-fulfilling prophecy, as the larger SI’s continued to win the larger contracts as they were the only ones able to provide the evidence they could staff and deliver them; and their costs remained high.

This left the SME’s facing three options:

  • Decide not to try for the larger contracts, reducing the amount of competition; potentially increasing costs and decreasing quality in the long run);
  • Form partnership agreements with a number of other SME’s or a larger supplier (again reducing the amount of completion) in order to be able to stand up the teams needed and enable delivery of larger contracts. However having a consortium of suppliers not used to working together could complicate delivery, which could in turn decrease the quality or speed of delivery if not carefully managed; as such not all contracts allowed consortium or partnership bids due to the perceived complexity they could bring.
  • Or the SME aimed to grow to allow them to be able to win and deliver the larger contracts. As SME’s grew however, they would often have to either increase their costs in order to run a larger organisation that could still deliver the same quality they did as before; or they could keep their costs low, but their quality would likely decrease.

Throughout the pandemic, the focus has been on delivery; and there’s been a healthy mix of both small and large contracts coming out, meaning lots of competition. While costs have always been a factor;  the pandemic allowed both departments and suppliers to remove much of the costly admin and bureaucratic approval processes in favour of lightweight approaches involved to bring on suppliers and manage teams outputs, encouraging innovation in delivery and cost; with lockdowns ensuring co-location was now out of the question many suppliers were able to reduce their rates to support the pandemic response as both departments and suppliers agreeing that the priority had been on delivering quality products and services to meet organisations and users urgent needs.The removal of co-location as a prerequisite also open up the market to more suppliers to bid for work, and more individuals applying for more roles; which increased competition and inevitably improved the quality out the outputs being produced. This in fact led to a lot of innovation being delivered throughout the pandemic which has benefited us all.

As we move out of the pandemic and into the next spending review round; the signs are that the focus is about to swing back to costs as the highest priority. With larger contracts coming out that are looking for cheaper day rates in order to allow departments to balance their own budgets; but as the economy bounces back and departments begin to insist again that teams return to the office, most suppliers will want to increase their costs to pre-pandemic levels. If we’re not careful the focus on cost reduction will mean we could decrease the quality and innovation that has been being delivered throughout the pandemic; and could cost the taxpayers more in the long run. Look at DWP’s first attempt to deliver Universal Credit for how badly things can go wrong when cost is the highest priority and when the Commercial team and runs the procurement process with minimum input from Delivery; driving the commercial and deliver decisions being made more than quality.

To find the sweet spot between Cost and Quality we need to create the best environment for innovation and competition. Allowing flexibility on where teams can be based will support this; supporting and encouraging SME’s and Medium sized suppliers to bid for and win contracts by varying contract sizes and values. Focusing on outputs over body shopping. Looking for what value suppliers can add in terms of knowledge transfer and partnership rather than simply prioritising who is the cheapest.

It’s important we all work together to get the balance between cost and quality right, and ensure we remain focused on delivering the right things in the right way.

Seesaw

‘The question is who… are you?’

Why being a Leader doesn’t mean not being yourself.

A sign in the woods baring the words, be yourself, everyone else is taken.
Be yourself, everyone else is taken

Chatting to a friend over the weekend, she mentioned her work had been encouraging her to go for more leadership type roles in the last year; but she hadn’t done it so far as she was worried she could never ‘fit in’ or be seen as a leader while she was being herself.

This made me reflect on my career, and when I had those same concerns; and how I over came them.

Back at the start of 2015 I had been working as a Grade 7 for a few years and I was now considering applying for my Grade 6. It’d had taken me a lot of effort and rejection to get my promotion to Grade 7 (I went through seven interviews before I finally got promoted) and I and was worried it would be the same all over again. When I’d first been going for my Grade 7, my manager at the time had tried to tell me I wasn’t leadership material and I’d really struggled to put myself into the professional box I thought leaders in the Civil Service had to fit within; and I was concerned I’d never be able to reach Grade 6 or higher because I just didn’t fit well enough.

My (then) current manager had put my forward for the Crossing Thresholds programme and as I sat with the group of amazing women who were like myself seeking promotion to Grade 6, all I could see was how much more professional they were; how comfortable they seemed to be in their own skin; how obviously they were what Civil Servants should be, and how much I obviously didn’t fit that mould. This wasn’t helped by the fact my previous line manager (who told me I’d never be a leader) was on the same programme as me.

Over the course of the programme we got to work together and get to know each other; and in one of the sessions we had to do some peer feedback 1:1 with each other. One of the other women on the course I’d been utterly enamoured by; she just came across as so cool and calm and together. She exemplified for me what a Civil Servant should be; and what I thought I needed to be in order to pass as a leader. During our 1:1 session as I told her all this, she astounded me by explaining that of everyone on the programme, she was most impressed with me; as I was the most ‘myself’; that I came across as real and approachable and authentic; and how she wished she’d had managers like me as she came up through her career. She was constantly exhausted from trying to pretend to be this perfect person she wasn’t; she was in fact debating leaving the civil service as she no longer felt able to pretend anymore and that I gave her hope that maybe things could change. Dear reader I was floored.

This message was repeated in different flavours throughout the day; even by my previous manager. She apologised and told me how impressed she was to see how I’d progressed, how I’d obviously flourished while remaining myself, and that she encouraged me to keep being myself and wished me luck for my future.

I reflected on that I’d heard from these amazing women, and what I’d observed; and decided that I didn’t want to spend my career pretending to be anyone other than myself, as it was exhausting. As such I attended my first Grade 6 interview sure it would be a car crash as I was determined to be myself; I spoke honestly about my neurodiversity; my strengths and weaknesses. my drives and passions; and made no effort to fit into the box I thought a Grade 6 Civil Servant needed to fit within. To my astonishment I was offered the role the very next day; and in just over a year I was then offered a role at Deputy Director level.

I’ve made a very concerted effort over the last few years to be authentic and myself; including speaking openly and transparently about things like my sexuality, my neurodiversity and my background growing up in a council estate. Because these are all the things that have helped me be me; and as such they are the things that have helped me succeed.

Now that’s not to say I could succeed anywhere and everywhere; some-places I fit, some I don’t. But part of owning who you are, and being true to it; is recognising that to be the best and most honest version of yourself, you need to recognise which environments work for you; and which ones don’t. It’s not a failing to not fit everyone. No one, if they’re being honest, does. The right organisation for you is the one that not only supports you to be yourself, but actively wants it. Because as leaders we know that people who feel able to bring their whole-self to work, are the people who generally work at their best.

Within the Kainos Neurodiveristy community group this week we were discussing personal user manuals and how they can help everyone within a team or organisation feel able to be their best and empower diverse teams to work together in the best possible way for everyone in them. This has reminded me I need to revisit my own user manual from a few years ago and share that with my new teams.

As a wise old monkey once explained to a confused young lion; you have to be true to yourself; so ask yourself, “who are you?”

Rafiki (image from Disney’s the Lion King)

How to be a Product Advocate

Why you need a Product Person in your team.

Since joining Kainos a few weeks ago, I’ve had a number of conversations internally and with clients about the relationship between Delivery and Product; and why I as a Product Person moved over to Delivery.

‘Products at the heart of delivery’ image

My answer to that question was that, having spent over 10 years as a Product Person, and seeing the growth of Product as a ‘thing’ within the Public Sector; helping Product grow and mature, developing the community, ways of working, career pathway etc; I realised that what was missing was Product thinking at a senior level. Most Senior leaders within the Programme delivery or Transformation space come from a traditional delivery background (if not an operational one) and while many of them do now understand the value of user centric design and user needs etc; they don’t understand the benefit of a product centric approach or what value Product thinking brings.

The expansion of Product people in the Public sector has predominantly been driven by GDS and the Digital Service standards; with most organisations now knowing they need a ‘Product Manger‘ in order to pass their Service Standard Assessment. However, almost 10 years later, most organisations are still not prioritising the hiring and capability development of their Product people. In May I worked with four different teams each working to the Digital Standards and needing to pass an assessment; and in none of those teams was the role of the Product manger working in the way we intended when we creating the DDaT Product Management capability framework.

Most organisations (understandably) feel the role of the Product Manager should be an internal one, rather than one provided by a Supplier; but 9 times out of 10 the person they have allocated to the role has no experience in the role, have never worked on a product or service that was developed to the digital standards never mind having been through an assessment; and they are regularly not budgeted or allocated the project full time; often being split across too many teams or split between the Product Manager role whilst still working in Ops or Policy or whoever they have come from previously; more often than not their actually a Subject Matter Expert, not a Product Manager (which I’ve blogged about before).

As a supplier; this makes delivery so much harder. When the right Product person isn’t allocated to a project, we can quickly see a whole crop of issues emerge.

So what are the signs that Product isn’t being properly represented within a team:

  • Overall vision and strategy are unclear or not shared widely; teams aren’t clear on what they’re trying to achieve or why; this can be because the Product person is not able to clearly articulate the problem the team are there to solve or the outcomes that team are their to deliver aren’t clearly defined.
  • Roadmap doesn’t exist, is unstable or does not go beyond immediate future/ or the Scope of the project keeps expanding; often a sign that prioritisation isn’t being looked at regularly or is happening behind closed doors making planning hard to do.
  • Success measures are unclear or undefined; because the team doesn’t understand what they’re trying to achieve and often leads to the wrong work getting prioritised or outcomes not getting delivered or user needs not met.
  • Work regularly comes in over budget or doesn’t meet the business case; or the team keeps completing Discoveries and then going back to the start or struggling to get funding to progress. This can be a sign the team aren’t clear what problem they are trying to solve or that the value that the work delivers cannot be/ isn’t clearly articulated by the Product person.
  • Delivery is late/ velocity is slow. This can be a sign the team aren’t getting access to their Product person in a timely manner causing bottlenecks in stories being agreed or signed off; or that the Product person is not empowered to make decisions and is constantly waiting for sign off from more senior stakeholders.
  • Role out is delayed or messy, with operational teams frustrated or unclear on project progress; a sign that the team doesn’t have someone owning the roadmap who understands what functionality will be available when and ensuring any dependancies are clearly understand and being monitored, or a sign that there isn’t someone engaging with or communicating progress to wider stakeholders.

More often than not as a Supplier I’ve had to argue that we need to provide a Product person to work alongside/ with teams to coach/support their internal Product people in the skills and responsibilities a Product person needs to have to enable successful delivery. Where clients have been adamant they don’t want Product people from a Supplier (often for budgetary reasons), we’ve then had to look at how we sneak someone in the door; usually by adding a Business Analyst or delivery manager to the team who also has Product skills, because otherwise are ability to deliver will be negatively impacted.

When budgets are tight, the role of Product person is often the first thing project managers try to cut or reduce; prioritising the technical or project delivery skills over Product ones. As such, teams (and organisations) need to understand the skills a good product person brings; and the cost of not having someone within a team who has those skills.

  • Their role is to focus on and clarify to the team (and business) the problem the team are trying to fix.
  • Ensure a balance between user needs; business requirements and technical constraints/options.
  • Quantifying and understanding the ROI/ value a project will deliver; and ensuring that can be tracked and measured through clear success measures and metrics.
  • Being able to translate complex problems into roadmaps for delivery. Prioritising work and controlling the scope of a product or service to ensure it can be delivered in a timely and cost effective manner, with a proper role out plan that can be clearly communicated to the wider organisation.

As an assessor, I have seen more projects fail their assessments at Alpha (or even occasionally Beta) because they lack that clear understanding of the problem there trying to solve or their success measures etc; than I have because they’ve used the wrong technical stack etc. This can be very costly; and often means undress of thousands (if not millions) of pounds being written off or wasted due to delays and rework. Much more costly than investing in having a properly qualified or experienced Product people working within teams.

While Product and Delivery are often seen as very different skill sets; I recognised a few years ago the value in having more people who understand and can advocate for both the value Product thinking brings to delivery; but also how delivery can work better with Product. People who can not only understand but also champion both in order to ensure we’re delivering the right things in the right ways to meet our clients and their users needs.

Which is why I made the active decision to hop the fence and try and bring the professions closer together and build understanding in both teams and senior leaders in the need for Product and Delivery skills to be invested in and present within teams in order to support and enable good delivery, and I as really glad to see when I joined Kainos that we’re already talking about how to bring our Product and Delivery communities closer together and act for advocates to support each other; and it was in fact a chat with the Kainos Head of Product Charlene McDonald that inspired this blog.

Having someone with the title of Product Manager or Owner isn’t enough; we need people who are experienced in Product thinking and skilled in Product Management; but that isn’t all we need. We need to stop seeing the role of Product person as an important label needed you can give to anyone in the team in order to pass an assessment and understand why the role and the skills it brings are important. We need senior leaders, project managers and delivery teams who understand what value Product brings; who understand why product is important and what it could cost the team and their organisation if those product skills are not included and budgeted for properly right from the start. We need Senior Leaders to understand why it’s important to invest in their product people; giving them the time and support they need to do their job properly; rather than spreading them thin across teams with minimal training or empowerment.

We need more Product advocates.

So, what is a Service Owner?

Before I discuss what (in my view) a Service Owner is, a brief history lesson into the role might be useful.

The role of the ‘Service Manager‘ was seen as critically important to the success of a product, and they were defined as a G6 (Manager) who had responsibility for the end to end service AND the person who led the team through their Service Standard assessments.

Now let’s think about this a bit; Back when the GDS Service Standard and the Service Manual first came into creation, they were specifically created for/with GOV.UK in mind. As such, this definition of the role makes some sense. GOV.UK was (relatively) small and simple; and one person could ‘own’ the end to end service.

The problem came about when the Service Standards were rolled out wider than in GDS itself. DWP is a good example of where this role didn’t work.

The Service Manual describes a service as the holistic experience for a user; so it’s not just a Digital Product, it’s the telephony service that sits alongside it, the back end systems that support it, the Operational processes that staff use to deliver the service daily, along with the budget that pays for it all. Universal Credit is a service, State Pension is a service; and both of these services are, to put it bluntly, HUGE.

Neil Couling is a lovely bloke, who works really hard, and has the unenviable task of having overarching responsibility for Universal Credit. He’s also, a Director General. While he knows A LOT about the service, it is very unlikely that he would know the full history of every design iteration and user research session the Service went through, or be able to talk in detail about the tech stack and it’s resilience etc; and even if he did, he certainly would be very unlikely to have the 4 hours spare to sit in the various GDS assessments UC went through.

This led to us (in DWP) phasing out the role; and splitting the responsibilities into two, the (newly created role of ) Product Lead and the Service Owner. The Product Lead did most of the work of the Service Manager (in terms of GDS assessments etc), but they didn’t have the responsibility of the end to end service; this sat with the Service Owner. The Service Owner was generally a Director General (and also the SRO), who we clarified the responsibilities of when it came to Digital Services.

A few years ago, Ross (the then Head of Product and Service Management at GDS) and I, along with a few others, had a lot of conversations about the role of the Service Manager; and why in departments like DWP, the role did not work, and what we were doing instead.

At the time there was the agreement in many of the Departments outside of GDS that the Service Manager role wasn’t working how it had been intended, and was instead causing confusion and in some cases, creating additional unnecessary hierarchy. The main problem was, as it was in DWP, the breadth of the role was too big for anyone below SCS, which mean instead we were ending up with Service Managers who were only responsible for the digital elements of the service (and often reported to a Digital Director), with all non digital elements of the service sitting under a Director outside of Digital, which was creating more division and confusion.

As such, the Service Manual and the newly created DDaT framework were changed to incorporate the role of the Service Owner instead of the Service Manager; with the suggestion this role should be an SCS level role. However, because the SCS was outside of the DDaT framework, the amount the role could be defined/ specified was rather limited, and instead became more of a suggestion rather than a clearly defined requirement.

The latest version of the DDaT framework has interestingly removed the suggestions that the role should be an SCS role and any reference of the cross over with the responsibilities of SRO, and now makes the role sound much more ‘middle management’ again, although it does still specify ownership of the end to end service. Re-adding in the confusion we tried to remove a few years ago.

Ok, so what should a Service Owner be?

When we talked about the role a few years ago, the intention was very much to define how the traditional role of the SRO joined up closer to the agile/digital/user centred design world; in order to create holistic joined up services.

Below is (at least my understanding of) what we intended the role to be:

  • They should have end to end responsibility for the holistic service.
  • They should understand and have overall responsibility for the scope of all products within the service.
  • They should have responsibility for agreeing the overall metrics for their service and ensuring they are met.
  • They should have responsibility for the overall budget for their service (and the products within it).
  • They should understand the high level needs of their users, and what teams are doing to meet their needs.
  • They should have an understanding (and have agreed) the high level priorities within the service. ((Which Product needs to be delivered first? Which has the most urgent resource needs etc.))
  • They should be working with the Product/Delivery/Design leads within their Products as much as the Operational leads etc. to empower them to make decisions, and understanding the decisions that have been made.
  • They should be encouraging and supporting cross functional working to ensure all elements of a service work together holistically.
  • They should be fully aware of any political/strategy decisions or issues that may impact their users and the service, and be working with their teams to ensure those are understand to minimise risks.
  • They should understand how Agile/Waterfall and any other change methodologies work to deliver change. And how to best support their teams no matter which methodology is being used.

In this way the role of the Service Owner would add clear value to the Product teams, without adding in unnecessary hierarchy. They would support and enable the development of a holistic service, bringing together all the functions a service would need to be able to deliver and meet user needs.

Whether they are an SCS person or not is irrelevant, the important thing is that they have the knowledge and ability to make decisions that affect the whole service, that they have overall responsibility for ensuring users needs are met, that they can ensure that all the products within the service work together, and that their teams are empowered, to deliver the right outcomes.

What even is agile anyway?

So you’re a leader in your organisation and Agile is ‘the thing’ that everyone is talking about. Your organisation has possible trialed one or two Agile projects within the Digital or Tech department, but they haven’t really delivered like you thought they would, and you think you can ‘do more’ with it, but honestly, what even is it in the first place?

It’s a question that comes up fairly regularly, and if you are asking it, you are not alone! This blog actually started from such a conversation last week.

Tweet https://twitter.com/NeilTamplin/status/1220608708452999170

First and foremost there is Agile with a capital A, this is the project methodology, predominantly designed for software development, as defined here. It “denotes a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.”

However nowadays, especially in the public sector, agile doesn’t only apply to software. More and more of the conversations happening in communities like #OneTeamGov are about the culture of agility. How you create the environment for Agile to succeed, and this is where many people, especially leaders, are getting lost.

So how do you ‘be agile?’

Being agile is borrowing the concepts used in agile development, to develop that culture. As Tom Loosemore says when talking about Digital, it’s about “applying the culture, processes, business models & technologies of the internet-era to respond to people’s raised expectations.”

But it’s more than what you transform, it’s how you do it.

The Agile manifesto says that Agile is about:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

When you consider individuals and interactions over processes and tools, then you remove unnecessary hierarchy and empower people to make decisions. You don’t enforce rigid processes for the sake of it, but iterate your governance based on feedback of users (in this instance your staff!). By being agile you focus on communicating directly with human beings, looking to how you can accommodate more actual conversations, and time together, rather than relaying on emails and papers as your only way to communicate.

By prioritising working software over comprehensive documentation you are constantly testing and iterating what works based on what is meeting your user needs, rather than deciding upfront what the answer is before knowing if it will actually work. You involve user research in your policy and strategy discussions. You analyse and test your new processes before you implement them. You change your funding and governance models to allow more innovation and exploration, and base your decisions on data and evidence, not theory. By being agile you are able to demonstrate working product or tangible services to stakeholders and customers, rather than just talking about what will be done.

Customer collaboration rather than contract negotiation is about bringing people along with you and working in partnership, achieving results together. Embracing and managing change to be innovative and deliver value whilst still being competitive and minimising unproductive churn and waste.

When thinking about responding to change over following a plan, it’s about being able to innovate and iterate. Prioritising and working on the most important work first. Building in short feedback loops and taking on board feedback.

Post it notes on a wall

Why is ‘being agile’ important?

Because as the market changes, and users expectations change, companies that can not take onboard feedback and iterate their products and services loose out. This is also true when it comes to companies themselves in terms of what they offer their staff, less people now go to work just for the money, people want more job satisfaction, empowering staff to make decisions and cutting bureaucracy are not only ways to cut costs, but also increase the value to both your users, your stakeholders and your staff.

Resources to help:

  • Scrum.org have a decent blog on Agile Leaders which can be found here
  • For Leaders in the Public Sector, the Digital Academy has an Agile for Leaders course, details of which can be found here
  • The Centre for Agile Leadership has a blog on business agility here (and for those in the US they run courses)
  • And the Agile Business Consortium have a white-paper describing the role of culture and leadership within Agile which can be found here

What I’ve learnt this year

This year has been a year of big change for me; I started a new job, left the public sector, moved cities, moved in with my partner, bought a new house, and most importantly, we got a dog.

As a Pagan, I celebrate Yule and the Winter Solstice; At the Winter Solstice we reach the longest night of the year. Darkness has reached its peak; and with the end of the longest night we celebrate the return of the Sun, the return of light, hope and promise. 

Sunrise over a snow covered village

As the year comes to an end I thought it would be worth reflecting on the year that is coming to a close, what I have learnt from it, things I’m still working on and taking forward into the year to come.

This year has been an interesting one, full of frustration and challenge; but also opportunities and excitement. I’ve always talked about the importance of finding your tribe, of being true to be yourself and being able to bring your whole self to work. For most of this year , if I’m honest, I was in a role that was not a good fit for me and I had never felt more cut off from my tribe. It taught me a lot.

What I have learnt:

What good leadership looks like

Reflecting on my time at the CQC, the fantastic opportunities that made me want to join the organisation when I was first offered the role, and the disappointment and frustration I felt in the last 6 months of the role after a change of line management left me being excluded and ignored. While CQC was a good fit for me at the start, a OneTeamGov event earlier this year on Leadership made me realise the impact a good (or bad) leader can have on an organisations culture.

The opportunities the organisation were facing were (and still are) real, but some of the recent hires brought in more recently made me realise that perhaps its readiness to embrace change at pace was not as real.

The difference within Difrent has been almost breath taking. From day one I’ve been empowered to get on and do things, with full support from my manager (the wonderful Rach) who has reminded me that there are good leaders out there fully capable of caring about their people.

Change is a movement not an individual

Whilst at CQC I got to speak to the Scottish Government Product Management community; I volunteered at OneTeamGovGlobal and attended my first international conference (the Delivering Digital Government event) in the Hague, where I got to catch up with Andrew Greenway and Tom Loosemore about the fantastic work Public Digital is doing around the world.

By the time I left CQC’s culture, and its ways of working, were no longer right for me, it felt more insular and less a part of the Digital movement. I felt more cut off from my tribe than ever before, it was a lonely feeling. I think something I have learned in the last year, you can not change everything on your own; nor will you always fit in everywhere; someplace’s are just not right for you (which doesn’t necessarily make them bad, but bad for you), sometimes you need to make a change. But note, even when you can’t see it, change is happening. You are not alone.

A person holding loose coins with a note saying ‘make a change’

Why the right culture matters

My frustrations with the culture in CQC, along with some advice from my mentor made me make a move outside of the public sector for the first time in my career. It’s something I thought long and hard about, as frustrated as I was at the CQC I didn’t want to just leave for any old role. The CQC made me realise I needed to find the right role, at the right organisation, with the right culture.

The senior leadership within Difrent talk constantly about our values, but it’s not just talk, it’s obvious everyone truly want to improve things together. Two months into the role, the suggestion we run a retro for the leadership team was met with open arms not disdain; everyone bought into the session and it felt very positive.

That’s not to say everything is perfect, it’s obvious that moving from ‘start up’ to ‘scale up’ means the culture has to adapt and change as well. But one thing I have learnt in the last year is good leaders don’t shy away from that challenge, they welcome it and talk about it in the open. That good leaders don’t just see ‘culture’ as a token word or a by product, but as a thing to invest in.

A row of different coloured leaves

You need to believe in yourself

I am an optimist, which made me ignore the initial doubts and worries I felt at the CQC; made me assume the problems I was facing were unintentional, that things would improve, and my desire to make things better things and to protect my team meant I pushed aside my doubts and tried hard to work things out. It took me a long time to realise the cumulative effect that was having on my own confidence.

Two months into my role at Difrent and I think it was absolutely the right move for me. After months of being disempowered and isolated by a manager who did not welcome challenge and for whom Digital was only about the technology, not the people; my role in Difrent has been a reminder that people matter, that I matter, and I am good at what I do.

I was absolutely delighted this year to be featured in Audree Fletcher’s book A Day is Not Enough, which featured 365 women influencing design for social good.

Within days of starting at Difrent I dived straight into contract negotiations and client engagement; talked to teams about what support they might need to enable them to deliver and within my first 60 days I lead on delivering my first (successful) pitch for business. I felt like I’ve achieved and delivered more in my last 2 months than the previous six months.

The importance of finding your own voice

My year has been a good one blog wise, many of my blogs were born from the frustrations I was feeling at the CQC, but also it felt like I finally hit my stride and found my tone of voice. While this blog has never been about ‘getting hits’ and more about sharing information, it’s been a very pleasant surprise to see how well they’ve done, the blogs about Thomas Cook and the Parliamentary Petitions site in particular seemed to strike a cord with people.

My goals for the year ahead:

My aim for next year is to keep building on the blog, but too also to try and get back into the swing of speaking at events. A year ago I was speaking at events fairly regularly, but the CQC hit my confidence more than I would like to admit. It’s hard to stand up in front of a crowd and feel like you have things to say when your manager regularly ‘accidentally’ leaves you out of the conversations your male colleagues seem to be invited to.

Since moving to Difrent I’ve already thrown my hat in the ring to speak at two conferences, and my aim is to try and have done 6 speaking events by the end of 2020. We shall see how that goes!

While politics at the moment is worrying, and has led some to question whether there is still empathy in the world, I’m approaching the next year full of hope. News like that of Twitter users recently joined together to develop a free Food Bank app highlight why the #TechForGood movement is so important and why I’m so proud to work for somewhere that is doing what it can to make a difference.

By this time next year I want to be able to stand up and talk about the things I have personally delivered. Up until now, while I’ve worked on amazing projects, very few of them I’ve been able to see through to delivery (either because of funding cuts, reprioritisation of projects, or promotions meaning I’ve move on before I got to see things through) the main reason for me taking the role at Difrent was to change that, to truly be able to deliver things that matter.

Both personally and professionally I’m doing what I can to add value, and learn from mistakes in the past to ensure the future is better.

Building a case based on assumptions

Why you shouldn’t start with the business case.

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.

A laptop with a document on next to a notebook and smartphone

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.  

A blank notebook next to a laptop

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.

Empty chairs around a table

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.

Being a visible leader with an invisible disability.

Hi, I’m Zoe and I’m a NeuroDiverse Senior Civil Servant.

This is me! (Photo curtesy of @RachelleMoose)

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.

Exmaple of how someone with Dyslexia can perceive text

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.

Writing ADHD on a blackboard.

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.

A picture of a ‘noise -o-meter sometimes used to help people with Sensory Processing Disorder indicate how they are perceiving the sound around them.

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.