CPIA Module 20, Section 3: Cross-Functional Team Building & Conflict Resolution
MODULE 20: LEADERSHIP & STRATEGIC MANAGEMENT

Section 20.3: Cross-Functional Team Building and Conflict Resolution

Informatics projects are the ultimate team sport. Learn the art of building and leading high-performing teams composed of nurses, physicians, analysts, and administrators, and master the skills to navigate the inevitable conflicts that arise.

SECTION 20.3

Cross-Functional Team Building and Conflict Resolution

From Clinical Silo to Collaborative Engine.

20.3.1 The “Why”: Informatics is a Team Sport, Not a Solo Performance

In your pharmacy education and much of your practice, the model of excellence is often one of individual expertise. As a pharmacist, you are the final authority on a prescription, the sole verifier of a dose, the individual accountable for the clinical check. This cultivates a deep sense of personal responsibility and clinical mastery, which is essential for patient safety. However, this model of the “heroic individual expert” is fundamentally incompatible with the reality of health informatics.

No single person can successfully implement an EHR. It is an undertaking of such staggering complexity, touching every facet of the hospital’s operations, that it is by definition a cross-functional, multidisciplinary endeavor. A project’s success is not determined by the brilliance of a single analyst, but by the collective intelligence, communication, and collaboration of the entire team. You may be the world’s foremost expert on medication-related clinical decision support, but your expertise is useless without the network engineer who ensures the system has the necessary bandwidth, the interface analyst who connects the EHR to the lab system, the nurse informaticist who can validate the clinical workflow, and the physician champion who can build buy-in with their peers.

This reality presents a profound challenge and opportunity. You must learn to transition your mindset from being the ultimate authority within a well-defined silo to becoming a highly effective collaborator and leader within a complex, diverse team. Your value is no longer just what you know; it’s how effectively you can integrate your knowledge with the expertise of others to achieve a shared goal. Building and nurturing these teams is not a peripheral task; it is the central work of informatics.

Furthermore, where there are passionate experts with different perspectives, there will inevitably be conflict. This is not a sign of dysfunction; it is a sign of a team that cares. Conflict between a clinician and a developer over a user interface is not a problem to be avoided; it is a necessary debate between patient safety and technical feasibility. Conflict between the project manager and the clinical team over a deadline is a critical negotiation between speed and quality. Your ability to navigate these conflicts constructively—to transform them from personal battles into opportunities for creative problem-solving—is what separates a mediocre analyst from a true informatics leader. This section will provide you with the frameworks and tools to build a cohesive team and to master the art of productive conflict.

Retail Pharmacist Analogy: Orchestrating the Annual Flu Shot Clinic

Think about the most complex operational challenge in a retail pharmacy: a high-volume, walk-in flu shot clinic on a busy Saturday. As the pharmacist, you cannot do this alone. Success requires orchestrating a cross-functional team, each with a distinct role, and navigating the inevitable friction between them.

  • The Cross-Functional Team: You have your pharmacy technicians (the “operations team”) responsible for patient intake, billing, and managing the queue. You have the store’s front-end manager (the “stakeholder from another department”) who is concerned about the long line of people blocking the main aisle. You have the corporate immunizations coordinator on the phone (the “project manager”) asking for hourly updates on your vaccination numbers. You, the pharmacist, are the clinical subject matter expert, responsible for screening, counseling, and administration.
  • Building the Team (Pre-Clinic Huddle): A good pharmacist doesn’t just let this chaos happen. You hold a huddle before the doors open. You define roles (“Sarah, you’re on intake. Mike, you’re on billing. I will be in the immunization room.”). You establish a workflow (“We’ll use these stanchions to form the line here, away from the aisle.”). You create a communication plan (“If you get a complex insurance rejection, don’t spend more than two minutes on it; put it in this red basket for me to solve later.”). This is Team Building. You are creating a shared mental model for success.
  • The Inevitable Conflict: An hour in, a conflict arises. The front-end manager comes to you, frustrated. “Your line is backing up into the greeting card aisle! You need to move it.” Your technicians are frustrated because they are following the plan you laid out. This is a classic conflict: Operational Efficiency vs. Departmental Priorities.
  • Conflict Resolution in Action: A poor leader might get defensive (“We’re following the plan!”) or simply give in, causing chaos. A skilled leader engages in problem-solving. You acknowledge the manager’s concern (“You’re right, the line is getting long. I see the problem.”). You gather the key players (the manager and your lead tech). You diagnose the root cause (the intake paperwork is taking longer than expected). You collaborate on a solution (“Mike, can you step out from behind the counter and pre-screen people for paperwork while they are in line? Manager, can you spare one of your cashiers for 15 minutes just to help manage the queue?”). This is Conflict Resolution. You have transformed a confrontation into a collaborative solution that respects both parties’ needs.

Your experience managing the complex interplay of people, processes, and priorities in a busy pharmacy has already given you the foundational skills for leading a cross-functional informatics team. This section will give you the formal models and language to elevate those intuitive skills into a deliberate, strategic practice.

20.3.2 The Science of Team Formation: Tuckman’s Stages of Group Development

You cannot build a high-performing team by simply putting a group of smart people in a room and giving them a deadline. Teams, like all living organisms, go through predictable stages of development. Understanding these stages is essential for a leader. It allows you to anticipate challenges, provide the right kind of support at the right time, and avoid being discouraged by the natural friction that occurs in a team’s lifecycle. The most famous and practical model for this is Bruce Tuckman’s Stages of Group Development.

As an informatics leader, your role is to guide your team through these stages as efficiently and effectively as possible. You are the catalyst for their development.

Masterclass Diagram: The Journey of an Informatics Project Team

1. Forming

“The Honeymoon”

Team members are polite, excited, and often anxious. Roles are unclear. The focus is on getting to know each other.

2. Storming

“The Reality Check”

Personalities clash. Disagreements arise over processes and goals. This is the most difficult stage, where many teams fail.

3. Norming

“Finding the Rhythm”

The team resolves its differences, establishes ground rules, and begins to work more cohesively. Trust begins to form.

4. Performing

“The High-Performing Team”

The team is a well-oiled machine. They are autonomous, interdependent, and focused on achieving the goal without friction.

The Pharmacist Leader’s Playbook for Each Stage
Stage What it Looks Like in Informatics Your Primary Goal as Leader Actionable Leadership Interventions
1. Forming The project kickoff meeting. Everyone is on their best behavior. The physician, nurse, developer, and pharmacist are all trying to figure out each other’s roles and communication styles. There is a lot of optimism but very little clarity. Provide Clarity and Direction.
  • Facilitate Introductions: Go beyond names and titles. Ask each person to share their expertise and what they hope to contribute to the project.
  • Develop a Team Charter: This is a critical document that you co-create with the team. It should explicitly define the project’s mission, individual roles and responsibilities, communication norms (e.g., “we will use Teams for daily chat and email for formal decisions”), decision-making processes, and meeting cadences. This document is the foundation for the Norming stage.
  • Set Clear, Realistic Initial Goals: Start with a small, achievable task to build early momentum.
2. Storming The first major disagreement. The developer says a requested feature will take six weeks. The nurse says it’s a “must-have” for patient safety and is needed in two weeks. The physician doesn’t see why the feature is needed at all. Voices are raised. The meeting ends with tension. Coach Through Conflict and Re-establish Purpose.
  • Do Not Avoid the Conflict: Acknowledge it openly and validate all perspectives. “I can see we have a conflict between clinical need, technical feasibility, and project timelines. All of these are valid constraints. Let’s break this down.”
  • Revisit the Team Charter: Remind the team of the ground rules they established for communication and decision-making.
  • Facilitate, Don’t Dictate: Your role is to guide the conversation toward a solution. Use active listening, reframe statements, and focus the team on the shared project goal (patient safety) rather than individual positions. (We will cover specific conflict resolution techniques in the next section).
  • Normalize this Stage: Reassure the team that this is a normal and necessary part of becoming a high-performing team.
3. Norming The team has a process for disagreements. The nurse now knows to bring a detailed workflow diagram to the developer to explain a request. The developer has learned to explain technical constraints in plain English. The team starts to develop inside jokes and a sense of shared identity. Empower, Facilitate, and Give Feedback.
  • Step Back: Begin to transition from a directive leader to a facilitative one. Let the team take more ownership of meetings and problem-solving.
  • Encourage Social Interaction: A team that trusts each other personally performs better professionally. Suggest a team lunch or a non-work-related activity.
  • Provide Positive Reinforcement: Acknowledge and celebrate the team’s improved processes. “I was really impressed with how the team worked through that last issue. Our new process is really working.”
4. Performing The team is humming. They anticipate each other’s needs. The developer proactively identifies a potential clinical issue with a piece of code. The pharmacist and nurse collaborate to solve a workflow problem without needing to escalate to leadership. The team is focused, motivated, and delivering high-quality work ahead of schedule. Delegate, Support, and Celebrate.
  • Get Out of the Way: Your primary role now is to protect the team from outside distractions and bureaucracy. Run interference with senior leadership so the team can focus.
  • Delegate with Trust: Give the team high levels of autonomy and authority over their work.
  • Focus on Individual Growth: Look for opportunities to challenge team members with new responsibilities to help them grow their skills.
  • Celebrate Success: Ensure the team’s accomplishments are highly visible to the rest of the organization.

20.3.3 Masterclass in Conflict Resolution: From Confrontation to Collaboration

Conflict is the lifeblood of innovation. A team with no conflict is a team with no passion, no diversity of thought, and no pressure-testing of ideas. Your goal is not to eliminate conflict, but to harness it. You must learn to distinguish between destructive, relationship-based conflict (personal attacks, blame) and constructive, task-based conflict (healthy debate over ideas, processes, and priorities). Your job is to create an environment of psychological safety where the latter can flourish while the former is quickly extinguished.

The Thomas-Kilmann Conflict Mode Instrument (TKI) is a powerful framework for understanding your own natural tendencies in conflict and for strategically choosing the most appropriate approach for a given situation. The model defines five conflict-handling modes based on two dimensions: Assertiveness (the degree to which you try to satisfy your own concerns) and Cooperativeness (the degree to which you try to satisfy the other person’s concerns).

Masterclass Diagram: The Five Conflict Modes

Assertiveness

Competing

(Win-Lose)

High Assertiveness
Low Cooperativeness

Collaborating

(Win-Win)

High Assertiveness
High Cooperativeness

Compromising

(Mini-Win/Mini-Lose)

Moderate Assertiveness
Moderate Cooperativeness

Avoiding

(Lose-Lose)

Low Assertiveness
Low Cooperativeness

Accommodating

(Lose-Win)

Low Assertiveness
High Cooperativeness

Cooperativeness

The Informatics Leader’s Guide to Choosing Your Conflict Mode
Conflict Mode The Goal When This is the RIGHT Tool in Informatics When This is the WRONG Tool (The Pitfall)
Competing
“My Way”		 To win. You pursue your own concerns at the other person’s expense.
  • On non-negotiable patient safety issues. A developer wants to use a yellow font for a critical allergy warning. You state, “This is not a debate. The alert text must be red. This is a patient safety standard.”
  • When a quick, decisive action is vital. During a system outage, you must make an authoritative decision.
  • To protect your team from an unreasonable demand from another department.
 Using this style for everything. It alienates team members, destroys psychological safety, and prevents good ideas from surfacing. It creates a culture of fear, not innovation.
Collaborating
“Our Way”		 To find a true win-win solution that fully satisfies the concerns of both parties.
  • For complex, high-stakes design decisions. Designing a new workflow for chemotherapy verification requires deep collaboration between pharmacists, nurses, and developers to find a solution that is both safe and efficient.
  • To synthesize insights from people with different perspectives.
  • When building long-term commitment and relationships is essential.
 For trivial issues. Spending two hours collaborating on the color of a minor button is a waste of time. It is also ineffective when there is no time for a deep-dive discussion (like in a crisis).
Compromising
“Half Way”		 To find an expedient, mutually acceptable solution that partially satisfies both parties.
  • When goals are important but not worth the effort of a full collaboration. Pharmacy wants a report with 15 data fields, but IT says they can only provide 10 by the deadline. You agree on the 12 most critical fields.
  • As a temporary settlement on a complex issue.
  • When you are short on time and need a quick resolution.
 On issues of core values or patient safety. You cannot “compromise” on a critical safety feature. Also, if overused, it can lead to a culture where no one fully pursues an optimal solution.
Avoiding
“No Way”		 To sidestep, postpone, or withdraw from a conflict.
  • When the issue is trivial and not worth the disruption.
  • When you have no power to change the situation.
  • To let people cool down. When a meeting becomes too heated and personal, you say, “Let’s table this discussion and revisit it tomorrow when we’ve all had a chance to think.”
 For important issues that need to be addressed. Avoiding conflict around a major project risk will not make it go away; it will only let it fester and grow worse. This is often the default for inexperienced leaders.
Accommodating
“Your Way”		 To yield to the other person’s point of view, often at the expense of your own.
  • When you realize you are wrong.
  • When the issue is far more important to the other person than it is to you. The nursing team has a strong preference for the placement of a button on the screen. It doesn’t impact safety or workflow efficiency. You accommodate their request to build goodwill.
  • To build social “credits” for later issues.
 On issues that are critical to your project’s success or to patient safety. If you constantly accommodate, your expertise will not be respected, and you will set a precedent that your concerns can be ignored.

20.3.4 Practical Playbooks for the Informatics Leader

Theory is valuable, but success lies in its application. This section provides concrete tools and scripts to help you put the principles of team building and conflict resolution into practice.

Playbook 1: The Team Charter – Your Constitution for Collaboration

Do not start any significant project without one. This is a living document created by the team, for the team, during the Forming stage. It is your primary tool for preventing and resolving conflict.

Key Sections of an Informatics Team Charter:

  1. Project Mission & Vision: A concise, inspiring statement of the project’s purpose. (Kotter’s Vision)
  2. Team Members & Roles: A clear list of who is on the core team and their primary responsibilities (e.g., Clinical Lead, Technical Lead, Project Manager, Physician Champion).
  3. Goals & Success Metrics: What does success look like? How will we measure it? (e.g., “Reduce medication reconciliation errors by 50% within 3 months of go-live.”)
  4. Communication Norms: How will we communicate?
    • Meetings: What is our standing meeting schedule? What is the purpose of each meeting? Agendas will be sent 24 hours in advance.
    • Channels: Use Microsoft Teams for urgent, informal questions. Use email for formal decisions that need a paper trail. Use Jira/Azure DevOps for all technical bug tracking.
  5. Decision-Making Process: How will we make decisions? This is critical for avoiding conflict.
    • “For routine decisions, the project manager can decide.”
    • “For clinical workflow decisions, we will strive for consensus among the clinical leads. If consensus cannot be reached, the Chief Medical Information Officer (CMIO) is the final tie-breaker.”
  6. Conflict Resolution Process: How will we handle disagreements?
    • “We agree to address conflict directly and respectfully with the person involved before escalating.”
    • “We will use active listening and focus on the issue, not the person.”
    • “If the conflict cannot be resolved, it will be brought to the project lead for mediation.”
Playbook 2: Scripts for Navigating Difficult Conversations

Having the right words can make all the difference in a tense situation. These scripts are frameworks you can adapt to your own style.

The Scenario: A developer has built a feature that technically meets the requirements but is clinically clunky and inefficient for nurses.

Bad Approach (Blaming): “This is wrong. The nurses will never use this. You didn’t listen to what we asked for.” (This will trigger defensiveness).

Good Approach (Collaborative Inquiry):

  1. Start with a Shared Goal: “Hi Mark, do you have a few minutes to look at the new workflow with me? I want to make sure we build something the nurses find fast and safe.”
  2. State Your Observation (Neutrally): “I was testing the new process, and I observed that it takes seven clicks to document a medication administration.”
  3. Explain the Clinical Impact: “From a nursing perspective, during a busy med pass, that number of clicks could add significant time and increase the risk of distraction. My concern is that they might start using workarounds if the process feels too slow.”
  4. Ask for Their Expertise (Acknowledge Their World): “I know there are probably technical reasons for why it was built this way related to the database structure. Can you walk me through your thinking?”
  5. Shift to Collaborative Problem-Solving: “Knowing both the clinical goal (fewer clicks) and the technical constraints you’ve just explained, could we brainstorm some alternative ways to achieve this? What if we…?”

This approach transforms a potential accusation into a collaborative problem-solving session. It respects the expertise of both parties and focuses them on a shared goal, which is the very essence of leading a high-performing cross-functional team.