Skip to content
CS Capstone Handbook

Conflict and Performance Conversations

A teammate’s task has sat in progress for two weeks and they’ve gone quiet in the channel, or a design argument has started to sound personal. This page covers how to tell which kind of conflict you’re in, how to raise a contribution problem without wrecking the working relationship, and when to take it to someone with authority over the team. It doesn’t cover writing the rules your team agrees to up front; the team working agreement guide does.

“Peace is not the absence of conflict but the presence of creative alternatives for responding to conflict.” (Jeanne Larson, Seeds of Peace, 1986)

Organizational research defines conflict broadly: the perception by the people involved that they hold discrepant views or have interpersonal incompatibilities. Jehn (1995) summarizes that definition and opens by calling conflict inevitable in groups, given how complex and interdependent their work is (pp. 256-257). By that definition every project team has some, whether or not anyone raises their voice. What changes the outcome is which kind of conflict it is and how the team handles it.

What Kind of Conflict Is This?

Section titled “What Kind of Conflict Is This?”

Diagnosing the type first tells you what to do about it, because the three types call for different responses: one you want less of, one you can put to work, and one you settle in writing so it stops coming back. Jehn (1995) separated relationship conflict, interpersonal incompatibility that shows up as tension, animosity, and annoyance, from task conflict, disagreement about the content of the work: viewpoints, ideas, and opinions. Later work added a third type, including a study of six work teams by Jehn (1997), and Jehn and Mannix (2001) define process conflict as disagreement about how the work will get done: who should do what, and how much each person gets.

Each type shows up on a student team in a recognizable form:

  • Relationship conflict: clashing personalities, egos, values. In the study of 105 work groups by Jehn (1995), it went with lower satisfaction, less liking between members, and less intent to stay in the group (p. 270).
  • Task conflict: goals, priorities, what to build. Jehn (1995) found that in groups doing nonroutine work, task disagreements weren’t harmful and sometimes helped, up to a point beyond which performance fell, and that groups with no task conflict at all tended toward complacency about problems and decisions (p. 275). It still cost something: task conflict also went with lower member satisfaction (p. 271).
  • Process conflict: tools, timelines, who decides, who owns what. The six-team study found it hurt performance. Settle it in your working agreement, because a process argument is about a rule, and once the rule is written down the argument has somewhere to end.

Keep task conflict from being read as relationship conflict, because once a disagreement about the work is heard as an attack, the team has two conflicts instead of one. Jehn and Mannix (2001) followed 51 three-person teams through a semester-long project and found that in the low-performing teams, task and relationship conflict rose together; they suggest the task conflict may have been heard as personal criticism. If Sam keeps pushing back on your design, start from the assumption that Sam is arguing about the design.

Where It Comes From

Section titled “Where It Comes From”

Before you decide the problem is a person, check for these five sources:

  • Value asymmetry: teammates want different things from the project. One wants an A, one wants a portfolio piece, one wants to learn Rust, one wants to graduate. All legitimate, and all pulling in different directions if nobody says them out loud.
  • Social loafing: unequal contribution, in quality or quantity (see below).
  • Ego and personality clashes: check trust before you treat these as the cause. Patrick Lencioni’s five-dysfunction model puts absence of trust at the base, with fear of conflict built on top of it.
  • Poor communication: unclear roles, misaligned expectations, decisions made in a channel half the team doesn’t read.
  • Ineffective project management: vague goals and unrealistic timelines turn every missed estimate into an argument about whose fault it was.

Social loafing is the one most likely to feel personal, and it’s a group effect, not a character flaw peculiar to your teammate. Latané et al. (1979) named it after experiments in which people clapped and shouted less hard in a group than alone, and Karau and Williams (1993) found the effect robust across tasks and populations in a review of 78 studies (p. 681). The same review found people more likely to loaf when their own contribution can’t be evaluated (p. 701). That’s the part you control: when every task on the board has one owner and the work shows up under that person’s name, each contribution can be seen.

Prevent value asymmetry, poor communication, and project-management conflict with a written team working agreement, because each one grows from something nobody said out loud: what each person wants from the project, where decisions get made, what counts as done.

To check whether a deeper team problem sits under those conflicts, run Team Dysfunctions Assessment. It walks Lencioni’s pyramid (trust, conflict, commitment, accountability, results) over your team and names the level where you’re stuck, before that level has produced something to escalate.

Difficult Behaviors

Section titled “Difficult Behaviors”

Some behaviors disrupt a team regardless of intent: assigning blame to avoid accountability, insulting teammates, overreacting to criticism, expressing frustration in ways that damage morale, refusing to negotiate, undermining others through gossip, and refusing to own mistakes.

Before you address any of them, prepare yourself:

  • Check your own history. Have you clashed with this person before, and is that shaping what you’re reading into their behavior?
  • Check your assumptions. You’re guessing at their motivation, so open with a question rather than a conclusion; if your guess is wrong, their answer will tell you.
  • Name your hesitation. What are you worried will happen if you raise it? That worry is usually what has kept it unraised.

Then aim the conversation at two outcomes: helping the person improve, and improving how the team works. Being right isn’t one of them, since you can win the point and leave the behavior exactly where it was.

The Escalation Path

Section titled “The Escalation Path”

Escalate in steps, and write down each one as it happens: the date, what was said, and what was agreed.

  1. A private one-on-one. One teammate, chosen deliberately, describes the observed behavior and its effect. Respectful, specific, and open to a response you didn’t expect.
  2. A mediated conversation. If the behavior continues, bring in a neutral third party (a mentor, or a peer outside the team) to sit in. They don’t take sides; they keep the conversation productive.
  3. Formal intervention. Bring in someone with authority over the team, such as a manager or whoever set the team up. Explain what you’ve already tried and describe the behavior, not the personality. They can reassign work or change how the team is set up, which no teammate can do.

Performance Conversations

Section titled “Performance Conversations”

A quieter problem is harder to raise than open conflict: a teammate who stops delivering. Deadlines slip, status updates go vague, and a task sits in progress for a whole sprint with nothing to show. It feels less clear-cut than bad behavior, and the person often doesn’t see the pattern themselves: in the studies reviewed by Karau and Williams (1993), people were generally unwilling or unable to acknowledge that they had loafed (p. 701).

The conversation has three jobs: surface the gap between what was expected and what happened, understand why, and agree what happens next.

Situation, Behavior, Impact

Section titled “Situation, Behavior, Impact”

Structure what you say around three elements: the situation (when, where, which task), the behavior you actually observed rather than the motive you inferred, and the impact on the team. The Situation-Behavior-Impact (SBI) model comes from the Center for Creative Leadership. Put most of your care into the middle term, because a described behavior gives the other person something to answer, while an implied motive gives them something to defend against. “You don’t care about this project” is a motive and can’t be answered. “The auth task has been in progress for eleven days” is a behavior, and it can.

"During the last sprint you were assigned the API integration. It's been
marked in-progress for two weeks with no commits or updates in the channel.
The rest of us couldn't start the frontend work that depends on it, so we
lost a week."


"You missed the last two stand-ups without letting anyone know. When we
don't hear from you we can't tell if you're blocked, behind, or on track,
and we end up planning around incomplete information."

Compare those with what not to say:

  • “You’re not pulling your weight.” Vague, and it lands as a character attack.
  • “You clearly don’t care about this project.” Assumes a motive you can’t see.
  • “Everyone else is doing more than you.” Comparative, and it guarantees defensiveness.

The Center for Creative Leadership also teaches a four-step version, SBII, that adds asking about the other person’s intent, which is the curiosity step in the conversation below.

A Bad Week Versus a Pattern

Section titled “A Bad Week Versus a Pattern”

Everyone has a bad sprint. One missed deadline doesn’t warrant a structured conversation, and treating it as one will cost you trust.

The signal is a pattern: the same problem across two or more sprints, or several indicators arriving together (deadlines missed, absent from meetings, silent in the channel). For a single incident, a light check-in is the right move: “You seemed stuck on the auth task this sprint. Everything okay?”

Having the Conversation

Section titled “Having the Conversation”

The order matters here, because each step depends on what you learned in the one before:

  1. Do it privately, in person or on a call, never in a stand-up, a group channel, or text. Correcting someone in front of the team puts them on the defensive before they’ve heard the point.
  2. Lead with curiosity, because there’s often something you don’t know: a health problem, a family crisis, a skills gap they’re embarrassed about, or a misunderstanding of what was expected. Open by describing what you observed and asking what happened.
  3. Let the answer decide the next step:
    • A legitimate reason (illness, emergency, a task that turned out much harder than it looked): acknowledge it, ask what they need, and adjust the plan. That’s a situation that needs support rather than a performance problem.
    • A skills gap: pair them with someone, break the task down, or reassign it. Then address the other issue, which is that the blocker went unraised.
    • No clear reason, or the same reason several sprints running: move to explicit expectations.
  4. Set expectations that are specific and time-bound: “Can you have the dashboard endpoint done by Wednesday and post a progress update Monday? If you hit a blocker, raise it in stand-up the same day.” That gives the person a target and the team a way to tell whether things improved.
  5. Follow up at the agreed time. If they met it, say so.

When to Escalate

Section titled “When to Escalate”

Tie the timeline to sprints, and agree on it before anyone needs it:

  1. Sprint N: you notice the pattern. Have the private conversation above.
  2. Sprint N+1: no change. Raise it at the retrospective so the whole team discusses it.
  3. Sprint N+2: still no change. Escalate to someone with authority over the team.

Waiting longer than this costs more than it seems to at the time. The team absorbs the work, frustration compounds, and by the time anyone speaks there may not be enough project left to repair the relationship. Escalating can feel like punishing a teammate, but what it actually does is bring in someone who can reassign work or restructure the team, and the earlier they hear about it, the more of those options are still open.

Team Working Agreement: Conflict ResolutionWhere the team writes this escalation path down.

When You Are the One Underperforming

Section titled “When You Are the One Underperforming”

If you recognize yourself here, get ahead of it. Tell your team you’re stuck or overwhelmed, and be specific about what’s blocking you. Ask for help: pairing, a task swap, or breaking the work into smaller pieces usually gets it moving again. If it’s personal, you owe nobody the details; “I’m dealing with something outside school and need to adjust my workload this sprint” is enough.

Timing matters more than the explanation. If you’re falling behind, tell the team before the stand-up where it would come out anyway. A teammate who says “I’m stuck on the auth flow and won’t finish it this sprint” gives everyone else two days to re-plan; one who goes quiet gives them a surprise at the demo.

Conflict-Handling Modes

Section titled “Conflict-Handling Modes”

The Thomas-Kilmann model describes five ways people handle conflict, positioned on two axes: assertiveness (how far you pursue your own needs) and cooperativeness (how far you accommodate others’). None is correct in general. Ralph Kilmann, the model’s co-author, lists when each mode fits by asking about the situation: how stressed people are, how complex the problem is, how much it matters to each side, how much time there is, and how much trust exists. The fit conditions below follow his list; the cost of using each mode by habit is this page’s own reasoning.

  • Competing (assertive, uncooperative): a win-lose push. Fits a simple problem that matters more to you than to others, with little time to discuss it. Used by habit, it teaches the people on the other side to stop raising things with you, since they expect to lose.
  • Collaborating (assertive, cooperative): work the problem until everyone’s needs are met. Fits a complex problem that matters equally to everyone, when there’s time to discuss it, trust is high, and the relationships are meant to last. It costs time, so save it for the problems that need it.
  • Compromising (middle on both): everyone gives something up. Fits a simple problem that matters moderately to everyone, under time pressure. Used by habit, it splits differences that a better option would have removed, so neither side gets what it needed.
  • Avoiding (unassertive, uncooperative): postpone or ignore. Fits a problem that isn’t important, at a moment when stress is too high for anyone to think; Kilmann’s advice then is to postpone until people have their composure back. Used by habit, it leaves a small problem costing the team a little more each week.
  • Accommodating (unassertive, cooperative): yield. Fits a problem that matters more to the other person than to you, in a relationship you want to protect. Used by habit, it builds resentment, because your own needs keep going unmet and nobody else knows it.

Kilmann’s advice is to choose the mode from the situation and never out of habit, and he notes that the same person’s conflict behavior often differs from one setting to another. The assessment shows which modes you reach for most, which tells you which habit to watch for when a disagreement starts.

Personality and Working Styles

Section titled “Personality and Working Styles”

Prefer trait-based models, specifically the Big Five, because each trait is a spectrum you can discuss by degree rather than a type that sorts people into boxes. The Big Five measures openness, conscientiousness, extraversion, agreeableness, and neuroticism (often reported as its inverse, emotional stability). Ozer and Benet-Martínez (2006) used it to organize a review of what personality predicts, from health and relationships to occupational choice, satisfaction, and performance.

You’ll meet MBTI (the Myers-Briggs Type Indicator) and DISC in industry, and it pays to know what the research says about the first. McCrae and Costa (1989) tested the MBTI against the Big Five in 468 adults and found no support for the idea that it sorts people into distinct types. What it measures is four fairly independent dimensions, which capture aspects of four of the five Big Five traits. Pittenger (2005) reviewed its psychometric limitations and concluded they warrant considerable caution when reading anything into the four-letter type. Read an MBTI result as a rough position on four spectra rather than a type, because two people just either side of a cutoff get different letters while scoring almost the same.

You can take a Big Five test free. It’s built on items from the International Personality Item Pool, a public-domain collection hosted by the Oregon Research Institute, and the site itself is open source.

Your own score matters less than the places where you and a teammate sit at opposite ends of a trait, because that gap is where friction starts and where a small adjustment pays off. A highly conscientious student reads a spontaneous teammate as unreliable, and the spontaneous one reads them as rigid. Naming the trait gap turns “you’re unreliable” into “we plan differently”, and a planning difference can be settled with a rule, such as when work is due to the rest of the team.

Validation

Section titled “Validation”

You can tell these practices are working when a teammate can describe a problem to you factually, without hedging and without an accusation, and you don’t feel attacked hearing it. Concretely, check that:

  • Your working agreement names an escalation path with measurable triggers, not “if problems persist”.
  • Someone other than the most senior or most confident person has raised a concern in the last month.
  • A concern raised in one sprint visibly changed something by the next.

If nobody has ever raised anything, ask whether it feels safe to. Edmondson (1999) defined team psychological safety as a shared belief that the team is safe for interpersonal risk taking, and telling a teammate their work is late is exactly that kind of risk.

Measuring Success

Section titled “Measuring Success”

The signals are about the team, not the documents:

  • Time to raise: how long between a problem starting and someone naming it. Aim for one sprint.
  • Resolution without escalation: most issues settled in the first private conversation.
  • Distribution of who speaks: if the same person raises everything, the others have concluded it isn’t worth it.
  • Surprises at the end: if a teammate learns in a final review that their contribution was a problem, that conversation should have happened months earlier.

Best Practices

Section titled “Best Practices”

These are the habits that keep a problem small enough to fix in one conversation:

  • Raise things early, small, and privately, while a sentence or two is still enough to fix them.
  • Describe behavior you observed, never motive you inferred.
  • Separate the person from the work.
  • Write the escalation path into your working agreement before you need it, with triggers you can point at.
  • Ask before you conclude.
  • Document each escalation step as it happens, not afterwards from memory.
  • Assume your own habitual conflict mode is showing up whether or not it fits.

Some Truths about Conflict

Section titled “Some Truths about Conflict”

Team conflict is easy to picture as shouting, but the failure to plan for is silence. A team that never has the conversation absorbs the imbalance, complains in private, and settles it in whatever evaluation arrives at the end, where the person can’t respond and nothing improves. Each step of avoidance is rational on its own: raising a problem costs something now and pays off later, while absorbing it costs a little more each week and never presents a bill. Agreeing the escalation timeline in advance takes that choice out of the moment: when the third sprint arrives with no change, the next step is already decided.

The claim that task conflict is good for a team is weaker than popular advice makes it sound. A meta-analysis by De Dreu and Weingart (2003) found task conflict correlated strongly and negatively with team performance and satisfaction, contrary to what earlier research and textbooks had suggested, though less so where task and relationship conflict were only weakly linked. A later meta-analysis of 116 studies by de Wit et al. (2012) found no strong negative association, and the same moderator: task conflict was more positively related to performance where it was only weakly linked to relationship conflict, one of three conditions the analysis identified.

Talking everything out isn’t a cure either. Jehn (1995) found that groups with norms of openness about conflict had more and more intense relationship conflicts, and weren’t any better at handling them (p. 275). The same norms made task conflict more beneficial to performance (p. 274). That’s the argument for handling a relationship problem in a private one-on-one about a specific behavior, rather than airing it in front of the whole team.

Frameworks don’t resolve conflict. Knowing that you default to avoiding, or that a teammate defaults to competing, changes nothing by itself. The Thomas-Kilmann modes and the personality models above are vocabulary for naming a pattern quickly, so that a conversation about it can start sooner.

Some conflict can’t be resolved before the project ends. Where a teammate is disengaged, the realistic outcome is an escalation and a written record rather than a breakthrough, and hoping otherwise costs the rest of the team the time they spend waiting for one. Plan the rest of the project around the work you know will get done, and keep the written record current with dates and specifics, since it’s what the person you escalate to will act on.

Personality models are weaker evidence than they look, including the good ones. Even in the meta-analysis by Barrick and Mount (1991), only conscientiousness related to performance consistently; the other traits’ links varied by occupation and by the performance measure, and some were small. A trait score describes a tendency across many situations, not what one person will do in the next one. Never use a personality result as a reason to expect a particular person to behave a particular way, because once a label becomes a prediction it becomes an excuse: “they’re just not detail-oriented” ends the conversation that “the last two pull requests skipped the tests” would have started.

Being the person who raises things is uncomfortable, and nothing on this page makes it comfortable. What the scripts here do is lower the stakes of each attempt. A conversation about one specific behavior, raised early and in private, is hard to hear as an attack, so getting the wording slightly wrong costs little, and there will be another conversation in which to get it right.

Conflict in Industry and Academia

Section titled “Conflict in Industry and Academia”

When you join an engineering team, ask your manager how and when feedback is given, because a performance conversation you’ve been told to expect is far easier to hear than one that arrives as a surprise.

Incident review in operations shares SBI’s rule: describe what happened, not whom to blame. Google’s Site Reliability Engineering book describes blameless postmortems, which look for the contributing causes of an incident without indicting any individual, and argues that where finger-pointing and shaming prevail, people stop bringing issues to light for fear of punishment. The book traces the practice to healthcare and aviation, and research on hospitals points the same way: Edmondson (1999) built her study on earlier work with patient-care teams in which members of some teams openly discussed medication errors, while members of others kept them to themselves. The same logic applies to a team problem: a team where raising a concern is expensive ends up running on incomplete information.

If you join an academic research group, agree on how problems get raised before one comes up, because the person you’d raise a problem with may also be the one writing your recommendation letter, and that makes an unplanned conversation harder to start.

References

Section titled “References”

Additional Readings

Section titled “Additional Readings”

The first two entries summarize research; the entries after them are practitioner frameworks, useful for their scripts and weaker on evidence.

Sources and further reading

Activities that exercise this