A better model for shared services

Most companies have some concept of shared services. HR, IT, PMOs and other teams often provide a centralized service across the organisation. Chugging all of your designers into a shared pool is a seductive idea, promising better utilization, better backup coverage, the ability to temporarily focus ressource for a big push and a center of excellence with professional sparring and specialization.

These are all worthy goals and if done well, shared services can be a boon to most companies. Pockets of individuals encumbered with a wide berth of tasks without backup or help can be transformed to shared setups for the benefit of both employees and users alike.

Unfortunately, this is often done as a strict cost saving exercise:

Put everyone doing Business Analyst work into a singular team and reduce their number.

Or the uniformity of service becomes a creed in itself:

Why should the Sales team have a local HR-representative when nobody else does?

These transformations are mostly driven from the top or from an existing centralized team and rarely spring from a stated desire from the users the services are meant to serve. In fact they often happen despite the protests of local teams and users who are currently well served by the existing model and who fear reduction in service, endless battles for priority or greater disconnect between business needs and service planning.

A huge part of this is caused by the “one size fits all” approach that often governs shared services setups. Instead of using the stronger pool to actively service each team in a way that helps them, teams are often presented with a new model and told to change their behavior to fit it. First order of business is generally to define the service catalogue and reduce the variation to a bare minimum.

While there may be a lower cost to serve from a standardized “one size fits all”, the effect is often much smaller than projected. Red tape and administrative overhead is required to keep approaches aligned across teams. As the toolkit shrinks and the range of situations it needs to cover expands, exceptions multiply. Dealing with exceptions is costly, either in terms of forcing non-optimal solutions on the organisation or by manually bypassing the official proces. As the paths narrows, people take detours. Detours are expensive.

This can also manifest itself in shadow organisations, where local teams hire HR-managers/UX-designers/developers/finance-people/data people etc. to serve their unmet needs, but disguise them under other titles. This reintroduces the fragmentation of the services, but in a less organized way and with a costly internal battle over decision making and functional monopoly that can consume an organisation entirely.

Another key argument in favor of a standardized service catalogue and a shared services setup is fairness. Why should one part of the organisation be treated “better” than another part? By benchmarking and clearly articulating what teams can expect (and more importantly NOT expect) from a central hub, we ensure that all parts of the organisation get a fair shake. But it isn’t good business.

Good business is about allocating ressources where they provides the most value, not spreading them thinly and evenly across. The needs of different teams can vary a great deal and so can the value that comes from meeting those needs. While it may be easier to apply a principle of equality and save leadership some difficult conversations, it is clearly not the best business decision.

So are shared services bad? Should we radically decentralize and hope that isolated pockets can do a better job? While that may be appropriate in certain settings, there are clear arguments in favor of shared services: robustness, specialization, overflow capacity, cross pollination and inspiration. These are all very tangible and real benefits that a shared setup can bring.

My suggestion is that we build shared services that put their customers first. The teams drawing on the services should articulate their needs and any conflict between central planning and team efficiency should be decided in favor of the team. The central hub must absorb the complexity and provide simplicity and tailored experiences to the consumers of their services. Matrix organisations, fully embedded ressources and dotted lines are important tools in terms of setting up the formalia, but the vital component here is culture.

We should build consumer centric cultures that gravitates towards what users want. Centralisation should, like everything else in organisations, be undertaken with clear outcomes in mind and comprehensive thinking about value. Any leader of a shared service must consider themselves to a servant of the organisation at large, not just look upward in the organizational chart.

Strictly looking at the head count and reducing it by lumping everyone together will more often than not destroy plenty of value elsewhere to push the case into red. But building a strong center of excellence that provides flexible and tailored servicing of its constituents can unlock a tremendous amount of value.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store