Organisational Design for a Service Line

I first came across the concept of a service line when consulting in government 3 years ago and have used the concept ever since. It’s a good organising principle when thinking about sets of related services.

What is a service line?

A service line is simply a set of services that work together to enable a user to complete an end-to-end journey. A simple example could be a service line to enable a user to get money for energy-saving measures for their home. There might be a a service allowing the user to find and compare measures for which they are eligible, this sends users to an application service to collect information from the user; a backend service — perhaps invisible to the user — checks their details authorises payment and another service that transfer money to the users bank account, notifying the user it’s done so. More complex service lines might have more services that have to work together to enable a user to complete the journey or might have alternative paths to completing that journey.

Organising a service line

I’ve seen a few examples of service lines over the past years and the different organisational structures that deliver them. Sometimes these structures are siloed.

I want to share my thinking and get some feedback. (With my limited sketching ability) I’ve come up with the following design for the organisation around a service line:

Product Teams — at the heart of the service line there are 1 or more cross-functional product teams, working on different parts of the service. These are long-lived teams — switched to different parts of the service line over time as priorities change. The organisation funds teams, not projects. If in government, these teams will include policy specialists who own the policy for the product they are working with. A core set of teams should be staffed by permanent employees with scale up / scale down achieved through contractors — with permanent employees taking key roles in each team if possible.

Service Line Operations — The service line is run by the same organisation that built it. A common runbook and incident management approach should exist across the service line. Operations includes end-user support to keep support and delivery close.

Marketing and Engagement — If use of your service line is optional or in a competitive space you’ll need some marketing or engagement-type activity to encourage people into the journey and keep them there.

Platform — It’s likely that as your service line grows and matures common needs arise across different services. This could be as simple as aggregating data across the services to better understand the service line as a whole or providing shared monitoring and logging solutions or shared identity management. Your platform may also provide various APIs to the rest of your organisation or to external parties.

Enabling — I’ve talked before about the many types of enabling team I’ve worked with. Depending on the size of the service line and the type of organisation you are in you will want a small Enabling team looking after e.g. Finance, Procurement, HR, Estates, Learning & Development, supporting Governance activities and providing Administrative support.

Senior Leadership Team (SLT) — An overall Service Line Head plus Lead roles e.g. Lead Service Designer, Lead Product Manager, Lead Technical Architect, Lead Delivery Manager and, if you are in government, a Policy Lead across the service line. (“Don’t bring policy and delivery closer together — make them the same thing — James Reeve, 24th March 2017)

Some Questions I’m thinking about

To help me evolve this model I’ve been thinking about some unanswered questions. Here are a few with some of my thoughts about how to answer them:

• What scope should the organisation around a service line have? Where should it start and finish in a potentially long (multi-year) user journey? — I’ve been thinking about how a technique like Strategic Domain-Driven Design might inform that decision.
• In a strongly hierarchical organisation should there be one leader across everything? How could multiple leaders collaborate together? (other than job-sharing). Would it make sense to split responsibilities by user if there were very different types of user for example?
• How would things be organised where the service line split across multiple organisational boundaries? (Perhaps each organisation’s parts of the service line could just be treated as providing a service to the other organisation through a defined API? But what practices to put in place to create that API if it doesn’t exist?) (The Team Topologies book talks more about collaboration across team boundaries.)
• Does it make sense to split something that naturally forms a single service line? Maybe to make the different parts more manageable for less experienced leadership?
• How should service lines be funded in a government organisation that typically funds finite projects or programmes? (A service line is more like a portfolio of services — and has no defined end date — you make investment decisions in anticipation of expected outcomes and adjust those decisions regularly depending on whether your outcomes are being achieved.)
• Could this organisation design support multiple service lines rather than just one? Probably if the service lines were closely related (e.g. same types of user).
• What would happen if, say, we centralised Marketing elsewhere? How might outcomes be affected?
• What would happen if we handed over part of the service line to a Business-as-Usual team once it had matured enough? (Not sure I believe this could be a good idea but it happens enough to consider the impact.)
• How might we efficiently get to this design over time given an existing organisational structure?

This post is the first draft of something I’ve been thinking about for a while. It would be great to get your feedback and hear about your experiences organising service lines.

Thanks

I’ve been privileged to work with some great service designers over the past few years and they have all helped inform my thinking about service lines — thanks Darius Pocha, Dan Rider, Audree Fletcher, Emma Gasson, Emily Bazalgette, Lou Downe and Harry Trimble.

He’s not a service designer but James Reeve (now at DfE) has also been very influential in my thinking since we met at BIS.