Cross-functional Collaboration - Expectations versus Reality

Completing a complex project in a rapidly-changing market requires cross-functional collaboration. And let’s face it, what project worth doing today isn’t complex and what market isn’t undergoing frequent and rapid change??

For an executive leading the project, it’s easy to see how the pieces of professional expertise - analysts, scientists, engineers, designers, and regulatory, manufacturing, quality, marketing, and sales - all fit together to achieve the ultimate goal - a safe, effective product that succeeds in the marketplace.?

Plans are drafted. Teams are formed. And the work begins.

Then before you know it, you’re fielding complaints from one group about how another is dropping the ball. Progress review meetings are object lessons in denial - “All good here…We’re on track…No problems…We’ll wrap that up this week.” Or they may take the form of performance art with flashy slide presentations showcasing each function’s activity but with little tangible evidence of progress.?

When pressed for tangible proof of progress and solid dates for key milestones, the finger-pointing begins. Each group may complain that they’re not getting needed information from another. Or the information they received wasn’t usable. Or that they’ve “been meeting and are still trying to figure out xyz.”

If this sounds like your team, you’re not alone. I’ve gotten three calls about dysfunctional interdisciplinary teams just this week, and it’s only Wednesday morning!?

What’s the problem?

Cross-functional, or interdisciplinary, collaboration is hard! Each discipline speaks its own language and uses different informal metrics to assess another person’s competence.?

An example that comes up again and again in EHR implementations is the difference in error tolerance between medical professionals and software developers. In medicine and nursing, giving the wrong medicine, the wrong dose of the correct medicine, or the correct medicine and dose to the wrong patient requires filing an Incident Report, most likely a formal counseling by their supervisor, and some notation in the proverbial “permanent record,” even if no patient was harmed. In contrast, software developers accept “bugs” as normal, laugh at some of the silly results, and spend a great deal of time trying to sort them out without any concern for repercussions. No surprise that physicians dismissed the software engineers as “reckless,” and the software engineers found the physicians to be “over-reactive” and “resistant to change.”?

Cross-functional collaboration also requires a skill set that not everyone is learning on their professional journey:

• Self-awareness - Knowing one’s own strengths and when/how those strengths can become liabilities
• Self-management - The self-control to interrupt and suspend one’s knee-jerk reactions in order to listen, be curious about, and fully consider others’ perspectives
• Situational (or social) awareness - Recognizing when a situation is/isn’t a good match for one’s strengths
• Appreciation of others’ strengths - Valuing the strengths others bring and their contributions to project success

Those of you steeped in emotional intelligence (EQ) will recognize these skills as a subset of the full suite of emotional intelligence capabilities first described by Daniel Goleman (HBR article) and further elaborated by Richard Boyatzis and Melvin Smith. The skills I’ve listed here can be seen as the “starter skills,” the bare minimum needed for effective cross-functional collaboration.

Why the emphasis on strengths? Because the research is unequivocal about the benefits of strengths-based leadership and management for individual performance.

At the same time, neither researchers nor strengths practitioners have given much attention to the performance risks associated with using one’s strengths or about the management of strengths in teams.

In an interdisciplinary team, the same complement of strengths needed to bring a complex product to market can also be a primary source of conflict.

Team optimization?

This is where team optimization comes into play. It’s not just about getting the right people on the bus and in the right seats or even trained in the right skills. Team optimization requires the ongoing appreciation of the strengths and limitations of each team member and of each discipline’s mindset, and repeatedly enrolling all team members in the appreciation of one another.

This is easier said than done.?

It is up to the team leader to serve as both orchestra conductor and translator. As a conductor, the team leader signals team members when their particular strengths are needed and when it would be best if they kept quiet. As a? translator, the team leader bridges the language differences between disciplines to help them make their way through the friction to common ground. With practice, the team should eventually develop the skills to “play” effectively with little conduction or translation, but it’s the rare team that does so from the start.?

Pro Tip - Encourage team members to use diagrams, flowcharts, lists, tables, charts - whatever sort of visualization that makes sense to them to illustrate their ideas. Getting ideas out of their heads into a visible form will allow them to better understand one another’s words. At a minimum, they’ll have a clearer picture (sic) of what they’re fussing about, but more often than no, having the information visualized will help them find their own way forward together.

As always, good luck! ??