How to Make Shared Services Suck Less

This post is an excerpt from the paper Accelerating Shared Services: How to Make Shared Services Suck Less by Charlie Betz, Scott Prugh, Erica Morrison, Scott Nasello, Adam Zimman, Damon Edwards, and Randy Shoup (with contributions from Julia Harrison).

When defined and operated well, shared services teams can provide substantial efficiency and leverage to organizations. It is hard to imagine a large organization that does not centralize broadly useful capabilities. They are a legitimate response to specialized problems that require specialist expertise.

When defined or operated poorly, however, shared services can be a source of intense frustration and inefficiency, with a reputation for behaving like silos and for putting would-be customers through burdensome bureaucracy and arbitrary decision-making.

All too often shared services are conceived as a conglomeration of systems and services that market-facing teams have deemed mundane. This can be anything from a feature that is considered commoditized (such as in-app messaging or email service) to a service that is mission critical but is seen as lacking opportunity for new feature development (such as CI or a deployment pipeline). In this scenario the shared services function can sometimes be seen as a “dumping ground” for undesirable work.

Shared services teams are also often born out of a need for deep expertise. While the strong preference of most Agile teams is to have all the skills they need on the team, at scale this proves very challenging. There are many areas in any highly scaled digital organization that call for deep expertise—expertise that can’t always be reduced to APIs. These include skillsets like DBAs (database administrators), security engineers, networking specialists, and infrastructure providers.

At the DevOps Enterprise Forum this year, it was reported that one CIO had, through analysis, determined that twenty-five people were the minimum number needed for a cross-functional product team to be truly viable in that environment—a number that is much larger than the seven to nine people often recommended for a “two-pizza team.”

Many solutions have been proposed and tried for this problem: T-shaped professionals, automation, platform teams, temporary assignments. But the basic issue of professional specialization versus product focus never goes away. As Don Reinertsen says: “Every time someone tells me that they are using a completely autonomous cross-functional team, when I dig deeper I find they have had to put in place a mechanism to create infrequent but quick access to deep expertise.”

Shared services are too often a sore point for DevOps and Agile teams, with a long and well-deserved reputation for bureaucracy, delay, and high-handed behavior. We need a new and more effective approach to shared services. In short, we want shared services to suck less!

Greater success can be found when organizations treat shared services as core to the business—a set of capabilities that enable and optimize the company’s ability to innovate while maintaining stability for existing customers. This paper seeks to present a deeper understanding of this problem and take this conversation to a new level, presenting an improved framework for understanding and guiding, helping scale companies through this problem. Each of the authors of this paper has experienced shared services done well and done poorly, and the purpose of this paper is to outline some of the patterns we have found that lead to successful shared services implementations in our organizations.

Common Dysfunctions with Shared Services

There are many reasons why shared services have gained a poor reputation in organizations:

• Users of shared services often wait for long periods of time due to bottlenecks or poor queuing models.
• Tickets are used for all interactions with shared services teams regardless of the characteristics or maturity of the services needed.
• When shared services have a strong component of expertise, the temptation is to manage them for utilization (keep the expensive experts busy). This directly contributes to unacceptable lead times and customer unwillingness to use the shared service.
• Shared services teams are used for governance (resource control) as well as enablement. “In order to get this thing you need, you need to convince us you need it and design how you will use it to our satisfaction, and in excruciating detail.”
• Designing for a great user experience is seen as a luxury. If usage will be mandated, why bother, there are so many other problems to solve?
• Shared services teams can be the dumping grounds for “leftover” products implemented or developed elsewhere in the enterprise. The shared services teams may lack the situational awareness, agency, or cycles to improve these services.
• Shared services teams get handed new technologies or vendor relationships to look after without an increase in team size, leading to the team becoming overburdened and having to adopt a defensive “keep the lights on” mode to survive.
• Shared services teams often don’t attract or retain talent with a strong engineering background, as they can be seen as boring, uninspiring, low-prestige work. As a consequence, shared services aren’t well engineered.
• Shared services are often implemented as big-bang, top-down, waterfall projects. By the time they’ve been delivered, needs have changed. Operational funding for ongoing improvement and customer-oriented delivery is too often unavailable.
• Shared services teams are often structured, incentivized, or behave in a way that makes the enterprise overdependent on them. Enterprise users never develop self-sufficiency to troubleshoot implementations of shared services. For example, can you debug why my CI build is failing?
• As a coping mechanism for being overburdened, shared services teams push difficult decisions and information gathering onto their consumers. This results in services being developed piecemeal, without an overarching strategy.

Principles for Successful Shared Services   

We propose the following overall principles for shared services:

• Treat shared services as a product and empower outcome-oriented product teams to find the most appropriate ways to solve problems and achieve agreed upon business outcomes.
• Ensure shared services teams have a deep understanding and empathy for the needs of their customers, e.g., through focus groups and relationship management.
• Develop shared services collaboratively with one or more customer teams.
• Design shared service solutions using systems thinking and architectural design, and ensure their ability to support modern engineering practices.
• Avoid falling into the assumption that shared services equate to ticketed (queued) work.
• Enable self-service at as many levels as possible: API, configuration, command line tools, approved design patterns, on-demand training.
• Ensure shared services are easy to find via a service catalog or API registry, provide well-
  defined APIs, and make it possible for consuming teams to suggest or contribute improvements.
• Promote Communities of Practice to serve as forums for improvement ideas and to allow the service’s consumers to deepen their understanding.
• Make reusing shared services more attractive and sustainable than recreating the wheel (creating a “paved path” versus a “dirt road”).
• Measure the service’s performance in terms of execution times, quality of service, Net Promoter Score, and other appropriate metrics.
• Ensure that shared services are funded sustainably for the long term, including ongoing improvement. Consider integrating funding via consumption charging.
• Avoid managing human-based shared services to maximize utilization; instead, manage to minimize customer lead times.
• Provide transparency in how requests are prioritized and consider value-based prioritization rather than simple “first come, first served.”

Patterns for Successful Shared Services

In the full paper, Accelerating Shared Services, we describe eleven patterns for shared service success:

• Long-Lived, Empowered Service Teams
• Understand and Solve the Customer Problem
• Develop Collaboratively with Customers
• Design for the Appropriate Level of Interaction
• Use Modern Engineering Practices
• Use the Appropriate Organizational Structure
• Service Discovery (aka Service Catalog)
• Choose to Use
• Charge to Use
• Measure Impact and Outcomes
• Support via Communities of Practice

To read the full paper, including details on each of these patterns, please download here.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•