Cross-functional Teams are NOT for PE Portcos
I’m brought in to work alongside portco CTOs because I’ve seen a lot of things before and I “know what good looks like”. Sometimes people explain their plan to overcome some problem and unfortunately I tell them:
“That’s a really well-thought out and rational idea. It just doesn’t work.”
How you think it will work
One example is cross-functional teams. The idea is great: assemble individuals from different departments to work together towards a common goal, breaking down silos, and fostering collaboration. DevOps!
When I was an Architect at Salesforce, I worked on cross-functional teams. Quality Engineering folks, software developers, network engineers. All kinds of different configurations. I even wrote a series of blog posts about their evolution.
How it actually works
Cross-functional teams are great, if you’re willing to pay to staff them properly. In a PE portfolio company, this raises a big problem:
In PE portcos, we want teams to be high leverage, and therefore high margin.
While cross-functional teams can have an advantage in execution speed by placing the expertise on the team itself, it quickly becomes expensive. If I have a network engineer on the team who has special permissions to configure network gear, what if they want to take a vacation? Do we need two network engineers on a team? Three? Some would argue that we should instead embed engineers as needed. That comes with an entirely new set of problems.
If you’re a Salesforce or a Google and can afford this type of arrangement, great. But even Google doesn’t fund SREs on every team.
What to do
In their book Team Topologies, authors Matthew Skelton and Manuel Pais describe four different team types:
- Stream-aligned teams - similar to your traditional development team
- Platform teams - similar to your traditional ops team
- Complicated subsystem teams - Cassandra, Kafka, etc.
- Enabling team - DevTools, Quality Engineering, etc.
These teams in essence create “virtual cross-functional teams” by shifting left.
I’ve described Shifting Left as “making it easy and safe to do things early in the process”. These teams take their expertise and make it available to other teams (via an API, DSL, etc) so that there are many less dependencies between teams.
For example, Platform Engineering can provide a way for developers to stand up their own representative test environment. This is a classic demonstration of a successful “shift left” strategy. By giving developers the tools they need, Platform Engineering enables them to work independently, reducing reliance on specific team members. There is no need to assign a Platform Engineer to each stream-aligned team.
This approach not only increases efficiency but also empowers teams to make decisions and take ownership of their projects. It can work for quality engineering, security, observability, and many more functional disciplines, without the expense or complication of staffing cross-functional teams.
While cross-functional teams may seem like an attractive solution for private equity owned companies, they are not a realistic one. In order to maximize growth via value creation, as well as maintain margin consciousness, the solution is to encourage collaboration in a way that enables and empowers teams to move quickly and safely, without funding redundancy.
This methodology is well proven at all sizes of the middle market, it will work for yours as well.