The Split Team

“Three engineers love AI tools. Three refuse to use them. Two are undecided. Velocity is diverging and so is morale.”

The Situation

On your team of 8 Android engineers, there's a sharp divide. Three engineers have embraced AI tools and their individual output has measurably increased. Three others refuse on principle — concerns about code quality, IP ownership, and skill atrophy. Two are undecided but feeling pressure from both camps. In sprint retros, the divide is becoming visible and creating friction. Your manager asks you to 'figure it out.'

Context

Velocity data shows measurable divergence between AI-adopting and non-adopting engineers
IP and licensing concerns from the skeptics are legitimate — not irrational
Skill atrophy concern is also legitimate — there is evidence that over-reliance on AI tools degrades specific skills
The two undecided engineers feel torn and pressured by both camps
Sprint retros have become uncomfortable — the tool debate is consuming retrospective time
No company AI policy exists yet — the team is operating in a policy vacuum

The Question

“Tell me about a time you had to manage a significant disagreement within your team.”

Response Options

One of these is the strongest response. The others reflect common approaches with real trade-offs.

I sided with the AI adopters since the velocity data is clear — the team needs to move in the direction the data points, and the skeptics' concerns, while understandable, shouldn't hold the team back.

I ran a structured team conversation that validated all concerns as legitimate — velocity gains, IP risk, and skill atrophy are all real. Then I proposed shared team norms: outcome-based metrics apply to all engineers regardless of tool choice, the team commits to periodic skill reviews to surface any atrophy early, and IP concerns are escalated to legal for a formal opinion rather than debated in retro. I separated the 'what tools do you use' question from the 'are you delivering outcomes' question — making tool choice a personal decision and outcome delivery a shared expectation.

I escalated to HR and my manager since the team conflict was affecting performance and I didn't feel equipped to resolve a values-based disagreement without support.

I let each engineer choose their tools freely and decided to ignore the retro friction — teams work through tool disagreements over time as the data becomes clearer.

The Debrief

Why the Best Response Works

Answer B works because it changes what the conflict is about. The team is fighting about tools — but the real question is: what do we expect from each other as engineers? Outcome-based norms answer that question in a way that doesn't require everyone to use the same tools. The IP escalation removes a legitimate unresolvable debate from the retro. The skill atrophy commitment makes the skeptics' concern a team-owned risk rather than a personal preference.

What to Avoid

Siding with the velocity data is the most common error — it feels like data-driven decision making, but it dismisses legitimate concerns as irrational. IP and skill atrophy are real issues with substance. Engineers who raise them are not being obstructionist — they're identifying risks the team hasn't addressed. The split isn't about tools — it's about values, and values conflicts require acknowledgment before resolution.

What the Interviewer Is Probing

The interviewer is evaluating whether you can navigate values-based team conflict without picking a side — and whether you can create shared frameworks that hold without requiring everyone to agree on the underlying question. The outcome-based norm is the mechanism that makes tool choice secondary to delivery, which is the only resolution that holds.

SOAR Structure

**Situation:** Team of 8 split 3/3/2 on AI tool adoption; velocity diverging; retros becoming dysfunctional; two undecided engineers under pressure from both camps. **Obstacle:** Both sides had legitimate concerns; no company policy; manager delegated resolution without providing a framework. **Action:** Structured team conversation validating all concerns; proposed outcome-based norms applying to all engineers regardless of tool choice; escalated IP concerns to legal for a formal opinion; committed to periodic skill reviews as a team-owned risk. **Result:** Retro friction resolved; undecided engineers stopped feeling pressured; velocity gap narrowed as non-adopters used AI selectively for low-risk tasks; company AI policy incorporated the outcome-based framing from our team norms.

The Learning Arc

"I learned that the most useful thing I could do was change what we were arguing about. We were arguing about tools — but the real question was what we owed each other as a team. Once we answered that question, the tool debate became much less important."

IC Level Calibration

senior

Create a safe space for both sides to articulate their concerns, surface the IP concern to management as a legitimate risk that needs a formal answer, and propose a personal tool choice policy that removes the pressure on the undecided engineers.

staff · Primary Target

Set shared outcome norms that hold regardless of tool choice, separate the tool debate from the performance debate, address IP concerns through escalation to the right authority (legal), and create a skill atrophy monitoring commitment that makes the skeptics' concern a team-owned risk rather than an individual objection.

principal

Make the divide visible to leadership as a signal of a broader organizational culture gap — the team is navigating a values conflict that the company hasn't addressed at the policy level. Propose that the company's AI policy process explicitly engage both perspectives rather than assuming adoption is the goal.

Company Calibration

Google

Psychological safety: both sides need to feel heard before they can commit

Amazon

LP: Disagree and Commit — after genuine hearing, commit fully

Airbnb

Technology Radar: team-level tool evaluation as a shared practice