IT and engineering leaders often grapple with the decision to centralize functions, or permit a degree of controlled redundancy within the company to facilitate agility. Striking a balance can be challenging, but here are some pointers to guide the way.
Horizontal Team Challenges
As a consultant, I routinely assist executives with capability building. That includes introducing not only new technologies, but also new team structures, service providers, and processes to an organization.
Leaders are quick to spot duplication of effort across the enterprise: pockets of QA teams, departmental data teams, and dual security teams (internal IT security vs. product security) to name a few. As a result, executives yearn to “stop the sprawl” by way of building new horizontal, shared-services style teams. Yet this approach often creates an entirely new set of problems.
Horizontal Team Examples
The catalyst to building a shared team comes from the perceived problem of functional duplication being remedied through consolidating. That is to say, collapsing duplicate functions into reusable capabilities which may be leveraged by numerous teams. While this approach works well for repeatable work (think purchasing or recruiting) it falls apart when customer needs are both diverse and complex.
Examples of challenged horizontal teams I come across include:
- Security teams
- QA teams
- Site reliability engineering (SRE) teams, including NOCs and SOCs
- Enterprise architecture (EA) practices
- Tool-based teams (the “Tableau team” or the “ServiceNow team”)
The problem with this approach is that horizontal teams lack understanding of the complex verticals they serve. How can a “generic” or “interchangeable” horizontal QA person review a code base they have no prior exposure to? What if the code is written in an unfamiliar programming language? How can SREs observe and govern a service they didn’t help build and deploy? What if Tableau isn’t the right data visualization tool to begin with?
When horizontal teams are built in isolation they often become ivory towers at best, and slow-moving bottlenecks at worst. Such teams are expected to parachute into any situation and “take the reins” with a deep understanding of customer needs. This is simply unrealistic, and will lead to frustration on both the customer and service provider ends of the equation.
Deciphering Jobs From Skills
When it comes to building teams, I often ask myself: are we centering the team around an outcome, or a skillset?
A skill is an ability or a suite of expertise that is applied to a job. A job is a position in which particular outcomes are expected. In a way, skills are the means and the job is the end (result).
Security is not an end-result per se. Your application should be secure. Your facilities should be secure, and so on. This requires an intersection of security skills and other subject matter expertise (software development, facilities management, etc) to achieve the desired result. Skills alone simply won’t yield business outcomes.
Structuring Teams for Flexibility
The executive goal is to optimize corporate resources to prevent egregious redundancy in terms of teams and tools. This makes sense in theory, but in practice, horizontal teams need the breadth to service a diverse customer base while clearly defining how far up the stack they play.
A center of excellence (CoE) is often the go-to pattern to “reuse that which is reusable” and delegate (i.e. allow redundancy) to enable tactical teams with potential overlapping skills to function. In my experience, CoEs are successful when:
- The foundational tooling and processes are shared / reusable
- Skill redundancy is embraced (not combatted) when jobs require unique subject matter expertise
- CoEs and functional teams/pods coordinate and collaborate on a routine basis
The key takeaway here is not to attempt “centralization of everything.”
Final Thoughts on Horizontal Team Structure
It often makes sense to consolidate tools and processes into reusable capabilities that may be shared across teams. But decision makers should remain cautious of over-abstraction. That is to say: simplifying customer needs into cookie-cutter / overly-generic horizontal functions.
Moreover, responsibility and familiarity go hand-in-hand. Without familiarity, responsibility is constrained. If shared service teams lack familiarity with customer needs, a bifurcation strategy may be in order. For example: a shared marketing platform team may manage the various martech solutions, yet separate teams will run campaigns on top of those solutions. Those campaign teams may have members with overlapping skills, and that’s perfectly fine. The goal isn’t perfectly balanced teams with zero redundancy; it’s about sharing what you can, and fostering agility everywhere else.
