How to Inherit a Service

A while back, before quarantine and therefore a lifetime ago, I ‘inherited’ a service. Anyone familiar with how these things go will also be somewhat familiar with how the conversation went:

“We think you’ve done quiet well and we’d like you to take over this service”

“Does that mean I can drop my old service”

“No”.

Thankfully I have loved taking over this service, by this service I do actually mean *this* service. I now manage the Academic Blogging service, blogs.ed.ac.uk which is what you are reading this post on. I have blogged in the past but sporadically at best. Managing the service is completely different, managing any service is difficult but managing a service which is designed to be open and allow people to do what they want (to an extent) comes with it’s own interesting challenges, more of that in another post.

Today however I wanted to talk more specifically about inheriting a service. It’s something that I hadn’t really thought about before but it struck me that this is the first ‘living’ service that I have taken over. I have a relatively short period of experience of managing learning technology services, roughly 6 years at this point. In that time I have managed two large services but both of these were in their infancy when I got hold. I was able to largely decide what these service should look like, what they would look like and what the policies around them would be. Obviously there is an amount of team work and involvement of other teams in this process but as a service manager the impetus usually came from me.

Taking on a new service that has existed before, however, is something completely different. I often enjoy using bad analogies that I tend to stretch to far, so allow me to do this yet again: Inheriting services is like getting an armchair that belonged to someone else (ish). It’s arranged in a different way, it faces the door, it doesn’t go back far enough, it feels a bit to firm and there are Revels tucked into the side of the cushion. Who would put Revels down there, why would they choose Revels of all the things available?

Service Personality

The problem/issue/opportunity is, someone or a group of somebodies have decided how this should work and put it all in place. Now you come in and you’re not sure if you always agree. Most of the time you will but you just need to understand the ‘why’ after seeing the ‘what’ and ‘how’. Most services have a ‘vision’ of sorts attached, usually within the original Project Brief or the Service Level Description (SLD) that sets out the ‘shape’ of the service. This works great in isolation but what often happens is that this clearly defined ‘shape’ then gets released and it tends to need to alter shape to fits its environment in some way. (I DID say I enjoy bad analogies).

Opportunities for Change

I’ve always very strongly believed that getting a ‘fresh pair of eyes’ is possibly one of the most useful things to do when you have a great idea or process. Having someone outside of the ‘organisation’ take a look is often the best way to pick up on things, firstly it forces you to explain why you made a decision and also allows you to be questioned. If you can’t convince someone as to why something works that way then you might want to re-evaluate or compromise with the other view point. I love the following quote, which I believe is attributed to Grace Hopper  – “The most dangerous phrase in the language is, ‘We’ve always done it this way’ ”

(If you don’t know who Grace Hopper is, please pause and look her up. I will wait)

Inheritance runs both ways

This is the part that surprised me the most when I realised that this was the first service that was secondhand/pre-loved/pre-existing/had a life before me. I started this long monologue talking about how I had inherited something but it seems obvious that the service had also imbibed something from it’s creators and previous owners. There were certain priorities or choices that were made by previous people upon the service, impressions in the surface that had left their mark. I agree with the vast majority of these but some I want to change, based on my priorities or choices that I think make it fit it’s environment in a better way, or a way that appears better to me. Obviously all of this is measured alongside the needs of the current community, I wouldn’t make big changes that negatively impacted people using the service but I may make decisions that change the ‘flavour’ in some ways.

Making it yours or making you part of it

After you have been looking after the service for a short while you will likely find a list of things that don’t really feel right to you. It’s likely that these decisions were made some time ago and might not reflect the needs of the user community anymore. I would say it is important to mention here that we aren’t criticising the previous owners, just using this change as an opportunity to review and also add you own input to the service. Once you have found these areas then try to seek the justification if possible, there could be a very good reason as to why something works like this and not like *this*. If there isn’t a good justification or if that doesn’t really hold anymore then start building your case for making a change and what that change will be. Next you get to take these changes to the service team, working group or user community. If these don’t exist then this is a good chance to make them as having some external input, if only at certain times will greatly improve the service as a whole. Also be sure to check that these changes are actually wanted/needed/will have a positive impact, change for the sake of change is a winding road. Always remember RACI (Responsible, Accountable, Consulted, Informed)

This is the part that I enjoy the most about managing services, there is a human part even if what *it* is an application running on virtual machines somewhere (I imagine in a basement, because, it has to be). I get to take all of the work that went before and add my layer on top and alter it ever so slightly, like a funky new flavour in your Rainbow Cake – I REALLY DID say that I like bad analogies.

 

 

Takeaways from service inheritance

If you are a current service owner

• For you managing a service, try to document what decisions were taken and why they were taken, this makes it a lot quicker for someone to get a feel for how the service exists now. Adding the justification really makes a big difference when someone new steps in
• Even if the service isn’t being taken over by someone else it can be very helpful to get fresh eyes on a service, or to include more people when making the decisions. Working groups or user involvement are very good for this.
• Try to update original documentation as the service shifts over time, most institutions seem to push for this at intervals but it helps to remember how services can change over time.
• Include retrospective look backs at the service at regular intervals, perhaps each year. Having a look at the changes that were added, how they were received and whether they helped add something useful to the service is a very rewarding process

If you are taking over an existing service

• Getting an overview or introduction to the service is incredibly useful but do bear in mind that it is unlikely that you will be able to understand the entire service after one meeting
• If possible try to take the previous service owner hostage so that you can refer to them if they didn’t document things
• Once you have a good understanding of the service highlight the areas that you have issues with. Areas that you don’t understand why something was done in a particular way or why a certain policy exists. Try to find to root cause for these, if they make sense and fit the service you can leave them for now. If that doesn’t fit the service or the user’s need then earmark those areas for change.
• Add your personal touch, come up with suggestions in these specific areas that you have highlighted and taken them to existing working groups or service team. If they don’t exist then consider creating them.