What are the common traps of cross-functional working groups, and how can you avoid them?
A while ago, I happened upon an article from Harvard Business Review that so accurately described my experience that it’s haunted me ever since. That article was titled: 75% of Cross-Functional Teams are Dysfunctional. A staggering statistic, right?
I’ve spent a lot of time leading cross-functional teams in engineering companies, specifically working groups, and I’ve learned a lot. So, I thought I’d offer some tips on how to make sure your working group is in the functional 25%.
The problem with working groups
One of the fundamental problems with working groups is that there’s no one subteam that can do all the work needed to carry out the mission. However, every member has their own ideas on what is the highest priority work, who should be doing it, and in what order.
Additionally, there’s a high number of people who need to come together to make any decision. In a traditional team structure, an engineering manager is the sole person needed to arbitrate a dispute between two team members. On a traditional PDE team, you need three people in the room to resolve a difference. In a working group, the minimum number of folks needed to resolve a dispute can be as high as every member of that group. A higher number of decision-makers calls for a higher degree of communication and coordination skills.
Before I get into any potential solutions, my first piece of advice is that you’re better off not assigning a strategic priority to a working group. It’s hard enough to get a software development project across the finish line under normal circumstances; introducing a 75% chance of dysfunction makes that journey needlessly more difficult. So, whenever possible, assign strategic projects to permanent teams. This might mean restructuring your organization so that you have the right teams to deliver your strategy. I know the trope about managers loving to do reorgs (and who are these managers? Reorgs take so much work!), but this is one of those times where it might actually be warranted.
However, if re-organizing isn’t an option and you’ve decided that a working group is the appropriate tool for the job, here are some things I’ve learned about getting up and running.
1. Establish governance first.
As engineering folks, we’ve all been conditioned to jump straight into problem solving. But working groups are a particular type of meat grinder that can endlessly devour your proposed solutions and turn them into inaction and non-results. It is very easy to rack up check-in after check-in of ‘no progress made’.
To tackle this, instead of jumping straight into the doing, start by setting up rules of governance. This might look like creating a bunch of RACI charts. It might mean implementing meeting rules. But you need to ratify how decisions will be made, who approves work to be executed on, how work will be prioritized, how new work will be brought into the system, and the timelines and commitments that each member has to the group. You can think of this as doing some pre-norming (the first stage of team development). By doing some of this work upfront, you can get ahead of the inevitable friction to come.
2. Be mindful of the we/they boundaries.
Speaking of friction, the other big obstacle to overcome is breaking down the barriers between participants. Often, when working groups come together, they do so as a collection of subteams, rather than a cohesive cohort. When smaller groups are brought together, it’s natural to see some division. However, this can negatively impact your working group’s ability to get things done.
One way to identify if this is happening is using what David Marquet terms the we/they boundaries: when do folks say ‘we’ and when do folks say ‘they’? If you hear a lot of ‘they’ when people are talking about other members of the working group, it’s a flag that you’re going to run into a lot more problems. Another Marquet-ism is to combat this issue by focusing on changing behaviors rather than changing mindsets; if you can get folks to behave like a cohort, they will eventually start thinking as a cohort.
3. Bring problems, not solutions.
I know this sounds counterintuitive. But the reason you’ve formed a working group around a given project is that no one team can complete the mission on its own. As such, any solution you bring to the table will probably encroach on another team’s time and staff. Not only do you lack the authority to do that, but you’re going to be treading all over people’s core needs in the process (belonging, improvement, choice, equality, predictability, and significance).
If you bring a well-developed and thought-out solution to the table, those who weren’t involved will feel like they’ve been excluded. Instead, bring the problem you’re seeing to the group, keep your well-developed solution in your back pocket, and use it to facilitate developing a solution together.
4. Control the work in progress.
Be very mindful of the amount of inflight work and do not be shy about ruthlessly cutting it down until you’ve seen something successfully ship. Keep things simple with a single execution pipeline. Don’t be clever by trying to run the project with high concurrency.
If you’re just getting started as a working group, you should think of yourselves as a new team that needs to learn how to roll over, crawl, and walk before you can get to running. Get to the point where you’ve shipped one thing successfully and build from there. Be aware this means your working group will be slow to deliver initially.
Reflections
If you haven’t already found yourself in a working group, you will one day. It’s an inevitability. While they may not be the most ideal way of getting work done, they do serve a niche purpose for initiatives that are moderately important, but not urgent. Taking time upfront to establish good governance, aligning on how work will be coordinated, and breaking down inter-team boundaries are great ways to avoid a lot of the dysfunction found in most cross-functional environments.
