Member-only story
Rethinking Shared Services Teams in Software Development

Ever heard a team, while refining a product work item, such as a user story, say “we will need a DBA for this”? Does the team immediately freeze up because that means they will have to wait weeks, or even months, to get assistance?
Many software development organizations have adopted the practice of shared service teams as a solution to increasing efficiency. These teams, typically structured around specific skillsets like Quality Assurance (QA), User Experience (UX), or Database Administration (DBA), provide specialized expertise to multiple development teams.
While the rationale behind shared services teams — maximizing resource (people) utilization — sounds logical, it hides a critical tradeoff: a negative impact on product delivery flow.
Part of the theory behind shared service teams is that these skillsets are expensive so they must remain fully engaged all the time. In other words, management wants 100% utilization across these skillsets. The other part of the theory, less often discussed, is protecting management fiefdoms/silos comprised of a specialized skillset. This might include aspects of knowledge hoarding.
In this article I will illustrate how optimizing for resource efficiency, at the expense of flow efficiency, creates bottlenecks, dependencies, and adds…