Cross-functionality is a Secret Weapon for Product Development Teams

In my experience, cross-functional teams align people to business goals best, and so they can get to real results much faster and much easier than teams made up of a single function. They really don't seem to be that popular, so I thought I'd talk about them a bit.

Here's some common chatter across mono-functional teams:

The Engineering team:

• "We should never be taking on tech debt. Tech debt slows us down!"
• "We should stop everything and clean up all our tech debt, regardless of cost or current business goals"
• "We should convert all our code to use this new framework everywhere because it has [INSERT TODAY'S LATEST DEVELOPMENT FAD]"
• "It's the testers' job to test, not mine"
• "Works on my machine!"
• "Let ops know that I used the latest version of the database client library, so they'll have to upgrade all the databases"

The Testing team:

• "Let me see if I can find a reason to stop this release"
• "We need X more days to test before the release"

The Frontend/Mobile/Ios/Android team:

• "That bug is on the backend."

The Backend Team

• "That bug is on the frontend."

The Operations Team

• "We haven't got time to do the release today. Let's schedule something for early next week."
• "Engineering doesn't need access to that. Just tell us what you need."

The Design Team

• "We don't want to help with a quick and dirty design for that feature experiment. It doesn't fit into our vision"
• "We've got the new total redesign for this month specced out."

The Product Management Team

• "That technical debt burndown can wait, right?"
• "We should do this the fastest way possible."
• "Here are the detailed specs of what I want you to build. Don't worry about what problem we're trying to solve."
• "I've finally finished our detailed roadmap for the year."

Do you see the patterns?

These teams...

• optimize for the areas of their specialization, not for the business' goals or for other teams' goals.
• defend their area of specialization by hoarding power and information
• constantly try to expand their area of specialization at the expense of the business' goals
• focus more on looking busy than getting real business results
• push blame to others
• too willingly take on expensive projects where others pay the majority of the costs or where the value isn't aligned with company goals.

So what to do instead?

Well you get these mono-functional teams because someone talking about a specialty or discipline once said something like "X is important. We should have a team for X."

My suggestion instead is simply to start saying "X is important. We should have X on every team."

This leads to a team with a bunch of different but cooperating specialties. The only thing they all have in common is their team's portion of the business' goals.

Think of it this way:

• If the members of a team don't share their goals can they really even be called a team?
• Why would you give goals to a team without also empowering them with all the specialist skillsets and ability to also deliver on those goals?

In general I've found that only a cross-functional team can make the proper trade-offs on its own, react quickly to changes in the world, and execute with minimal communication overhead. Once it has all the specialties it needs to autonomously deliver on its goals, you're set up for a whole new level of speed of execution.

I'm not saying that cross-functional teams solve all the issues above, but they make the conversations happen on-team where it's much cheaper than across teams, and the conversations are much easier because people don't have to guess each other's motives nearly as much.

It's not any easy transition either if you're currently on mono-functional teams. In my experience though, cross-functional teams can really make mono-functional teams look like like a morass of endless disagreements and easily avoidable meetings.

---

Tags: cross-functionality, teamwork, practices

← Back home