Demystifying and elevating the status of Live Services

What is Live Services (in principle)?

Live Services is basically the goal of any service you build either digital or offline. In the context of public services and the GDS framework, it is a goalpost, where services are housed once they are completely built. The diagram below is a pictorial representation of what Live Services do:

What is live services (in reality)?

After landing in my new role as a Portfolio Product Manager, I met with my clients and they proceeded to over the first initial meetings state their unfiltered views of what Live Services meant:
“Live services is a dumping ground”
“Live services is not a bed of roses”
“Some live services are a steaming pile of….”

Indeed, Live Services does not have the most glamorous status, it does have a Bad Reputation. In part this is due to the challenging nature of the role. When looking after 20 services in various stages of the software delivery lifecycle at times, each service becomes its own mini project, and requires an incredible amount of context switching. If you have worked in live services, you have most certainly gained your scars of delivery, and often the job is about keeping services running, with no-one ever knowing (at best) that anything went wrong. In my humble opinion, Live Services stalwarts are the unsung heroes of technology at every level!

I am very biased here, but I hope to elevate the position of Live Services by giving you three key reasons why Live Services is actually THE place to be…

1. Live Services is the goal of all Product teams, and it should be celebrated!

Live is often classed as the Ugly Duckling of the software lifecycle, there is an assumption that the excitement of curating a service has all but disappeared by the time that is comes into live. However, the goal of getting a service live and being used by all the users, is completely forgotten when it reaches this point. Why?

Eternal optimist viewpoint – Live is where we evergreen the service, continually work on it to support the service for the user base. Though, it is more difficult and the services don’t often have a build or DevOps team to focus on the continual improvement of the service. As a Live Service Product Manager, I can confirm that there is continuous improvement. This is through maintenance of platform or essential tech debt requirements, change requests and policy changes and do result in the teams undertaking design, and development work on the services.

I am lucky enough to have a brilliant Design team alongside the two incredible scrum teams who look after almost 20 services now, putting the team in a unique position to undertake analytics, User research and design work to constantly review and rework, and improve the service, not just take care of when there are incidents.

2. Live Services allows continuous development and iteration of services and learning which is invaluable for build teams and building better services overall!

Live means that there is no sole focus, but many services with little attention given to each. Although this is true, we do not focus solely on one service, I do believe Jeremy Bentham’s panopticon is a useful analogy to tackle how and show how the services take care of themselves, but as a PM in the watch tower, you have the ability to monitor 20 services, and regulate how they are treated, monitor their behaviour and intervene when required.

The zoomed out view provides an assessment of how services perform in Live, during peaks, and analysis of user behaviour and code. As a Live team, we are in a unique position to inform and advise on how services can be successfully built, deployed and used with maximum reliance.

3. Live Services is a great safe place to learn and upskill our people whilst gaining the ‘scars of delivery’!

Live is often classed as the place where devs go to die…yes, there is little exciting decision making about approaches to databases, code styles, application creation and code writing. However, live is the place in which developers, desginers and more can learn from each other. As a safe space with an ongoing timeline, there are no pressures of build teams with not having time to allow team members to explore different skills. However, in Live, QA/ Testers can become developers, and vice versa, we call our team T shaped resources, with each member having at least two skills. We are popularising the I, T, X evolution of training model:

I – one deeply learnt skill for example development
T – two skills – one deeply learn skill, development and an additional learned, for example testing
X – three skills or more – one deeply learn skill, development, the an additional learned testing and then exploration into agile, Scrum Master for example or architect

Hopefully, I have convinced you of the marvels, wonders and delights of Live Service life and made you a convert, where one day, you might just want to become an unsung hero!

Maria Fairbank-Azcarate

Senior Consultant, Capgemini Invent

Maria Fairbank-Azcarate is a highly skilled Agile Product Manager with 5 years of experience working on Digital Transformation programmes across the Public Sector. She has a Business Analysis background and is specialised in leading Scrum teams as a Product Owner and Product Manager.