‹ Field Notes
Conflict resolution

Volvo says it has "completely changed" into a "full-tech stack company". The question that tests whether you can work the seams.

On October 15, 2026, TechCrunch reported that Volvo is expanding its nearly decade-long partnership with Nvidia, and that the automaker will use three pieces of Nvidia hardware and software in future vehicles to deliver an automated driving system for urban streets and highways. The pieces are Nvidia's Hyperion sensor and compute architecture, the Alpamayo driving software stack, and the Halos safety evaluation layer, combined with Volvo's own vehicle safety systems and engineering. Ali Kani, who heads Nvidia's automotive division, described Alpamayo to TechCrunch as "redundant and diverse": a family of AI models running alongside classical software that uses machine learning and camera and radar perception. "The point is we run these two stacks at the same time, and we have multimodal sensors in our philosophy because it’s a safer product that way," Kani said, adding that the open source Alpamayo software has now been downloaded by more than 650,000 developers. Volvo didn't disclose the value of the deal or name the first model that will carry the stack.

The line worth sitting with belongs to Alwin Bakkenes, Volvo's head of software development, and it is about organization rather than silicon. "Automakers used to be very much like car-line-based development and working with various suppliers, etc. and we have completely changed and migrated into being a full-tech stack company," he told TechCrunch. Take that at face value. When work that used to be bought from a supplier is brought inside, the boundary doesn't vanish. It becomes a seam between internal teams, and the disagreements a contract used to settle now have to be settled by people who share a building and a roadmap. Kani's two stacks describe the same condition from the engineering side: a safety case built on keeping two different approaches running side by side, which in any organization means two sets of people who think differently about the same problem. That is the terrain on which cross-team conflict grows, and it is why an announcement about sensor architecture is also the setup for one of the most common questions a senior hiring loop asks.

The interview question
“Tell me about a conflict between your team and another team. How did you resolve it?”

Why they ask it

Past a certain level, almost nothing ships inside a single team's boundary. The interviewer isn't asking whether you have ever disagreed with another group; everyone has. They are asking what you did when the other team's legitimate priorities collided with yours, and whether the resolution came from understanding or from force. Three things get listened for. Whether you can state the other team's position accurately and without contempt, because a candidate who can't probably didn't resolve the conflict so much as win it. Whether you escalated at the right moment, neither as a first move nor never. And whether the resolution held. A fix that lasted a sprint and then reappeared under a new name is not a resolution. It is a ceasefire.

The trap

The most common weak answer is the villain story. The other team was unreasonable, the candidate was patient, and in the end sense prevailed. It sounds like a conflict story, but it is a character reference the candidate has written for themselves, and experienced interviewers discount it on sight. The second weak answer is the non-conflict: a misunderstanding about an interface, a meeting, handshakes. It is too small to show anything. The third is escalation dressed as resolution. "I brought in my director and we aligned" describes a transfer of the problem, not a resolution of it, unless the candidate can say what they tried first and why it wasn't enough. A strong answer picks a disagreement in which both sides were right about something, names what each was protecting, and ends with a change to the structure that produced the conflict, not just to the mood.

Applying STAR-T

Situation. Our infrastructure team owned the deployment pipeline for every service in the company. The payments team needed a release cadence the pipeline couldn't support, and had quietly built a side channel to push configuration changes around it. We found out when an unreviewed change took a checkout path down for part of an afternoon. Both teams were angry, and both had a point: they were being blocked, and we were being bypassed.

Task. As the pipeline's owner, I needed the bypass to stop. I also needed it to stop without a decree, because a decree would have moved the argument onto two directors' calendars and left the underlying need exactly where it was.

Action. I asked the payments lead to write down, in their words, what the pipeline was costing them. The answer was narrower than the shouting suggested. They didn't need to ship features faster; they needed to change a handful of configuration values within minutes when a processor misbehaved. That reframed the conflict from speed versus safety to a missing product. Together we designed a fast lane for a defined class of config changes, with its own review and rollback rules, and we wrote the policy with both leads' names on it. I took the proposal to my director already agreed, not as a dispute to adjudicate.

Result. The side channel was retired, the fast lane became the sanctioned path, and the conflict didn't return the following quarter because the seam now had an owner and a rule. The payments lead later asked us to extend the same lane to another team.

Trade-off. The fast lane carried more risk than the main pipeline, and we accepted that explicitly, with a tighter rollback standard to pay for it. Saying so out loud is what separates a resolution from a concession.

The follow-up that breaks weak answers

The question that exposes a rehearsed villain story is simple: "If I asked the other team's lead to describe that conflict, what would they say?" A weak answer either repeats the candidate's own framing with the names swapped, or reaches for something flattering. A strong answer is specific and a little uncomfortable. The other lead would say we had been slow to notice their problem, that the pipeline's defaults were built for our convenience rather than theirs, and that the fast lane should have existed a year earlier. If you can't produce that paragraph, the interviewer will assume the resolution was one-sided, and they will usually be right.

Score your answer against the director’s bar

Q: Tell me about a conflict between your team and another team. How did you resolve it?

Ready when you are

Choose the one cross-team conflict where you can argue the other side's case better than they did, bank it, and rehearse it until that follow-up has no edge. Try it free →

Rehearse this in L8 Loop →