Two teams building the same service

"Two teams are building the same thing. Neither wants to stop. You have no authority over either."

What the question is actually testing

This is the canonical staff-level influence question, and it is testing whether you can operate without positional power. Specifically:

Whether you check the premise. "The same thing" is usually an oversimplification. Two services that look identical from outside often solve genuinely different problems, and a staff engineer who forces a merge without checking has destroyed value.
Whether you make the cost visible rather than arguing about correctness. Nobody changes course because you were right. They change course when the cost of not changing becomes legible to the person who pays it.
Whether you find the decision-maker. With no authority, your job is not to decide, it is to get the decision made by someone who can, with good information.
Whether you can lose gracefully. If the decision goes against your recommendation, what you do next is being scored more than your argument was.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: verify the duplication is real

Before proposing anything, read both. Two hours, not two weeks:

What does each actually do? Not the README, the code and the API surface.
Who consumes each, and how much traffic?
What was each built for? There is usually a reason, and it is usually a real constraint that one team had and the other did not.
Where do they genuinely differ? Latency profile, consistency guarantees, deployment model, data residency, tenancy.
What would it cost to consolidate, honestly, including migration and the features one has that the other does not?

The outcome is one of three, and they need completely different responses:

Finding	Response
Genuinely identical	Consolidation is right; the question is which one and who migrates
80 percent overlap, different constraints	The common part is a shared library or platform capability; the differences stay
They only look similar	Say so publicly and stop. Forcing a merge here destroys value and costs you credibility

The third outcome happens more often than the framing of the question suggests, and being the person who says "actually these are different, here is why" is worth more to your reputation than winning a consolidation.

Then: make the cost visible, in the currency that matters

Arguing "duplication is bad" is arguing about aesthetics, and aesthetics do not move roadmaps. Quantify:

Direct cost
  2 teams x 1.5 engineers of ongoing maintenance = 3 engineers/year
  Infrastructure: two clusters, two pipelines, two on-call rotations

Consumer cost (the one nobody counts, and the one that lands)
  7 downstream teams currently integrate with one or the other
  4 of them have integrated with BOTH, because different features
  Every new consumer must ask which to use; nobody has a good answer

Divergence cost
  Two implementations of the same business rule. They already disagree
  on how partial refunds are handled, which is a live correctness bug
  nobody owns.

Opportunity cost
  The 3 engineers/year is the whole cost of the thing the director said
  last quarter we did not have capacity for.

That last line is the move. Translate the duplication into something the decision-maker already said they wanted, so consolidating becomes the way to get the thing they care about rather than a tidiness project.

The divergence bug is the second-strongest item, because it converts an abstract inefficiency into a specific correctness problem with a customer impact.

Then: find the person who can decide, and give them a decision

With no authority, your leverage is framing the decision for someone who has it. That is usually the lowest common manager of both teams.

Do not walk in with "team A should stop". Walk in with a written document:

The situation. Teams A and B both operate a notifications service. Seven downstream teams consume one or both; four consume both.

The cost. Roughly 3 engineer-years annually in duplicated maintenance, plus a live correctness divergence on partial refunds, plus every new consumer paying an integration decision tax.

The options.

Consolidate on A. A has the better delivery guarantees; B has templating that A lacks. Roughly 6 weeks to port templating, 2 quarters to migrate B's 3 consumers.

Consolidate on B. B has better ergonomics; A has the throughput. Porting throughput work is roughly a quarter and carries more risk.

Extract the common core as a shared library, keep both services. Cheapest, and it does not fix the consumer confusion or the on-call duplication.

Do nothing. Costs stated above, ongoing and rising.

Recommendation. Option 1, with A's team owning templating delivery and B's team owning migration of its consumers, so both teams have work rather than one being told to stop.

What I need from you. A decision by the 20th, and a statement to both teams that it is decided, so this stops being a debate.

Four properties. It is written, so it can be circulated and cannot be misremembered. It gives real options rather than one dressed as four. It names what each team keeps, because "your work is being deleted" is why people fight. And it asks for one specific thing: a decision and an announcement.

DACI is the vocabulary to offer if asked how to run it: one Driver (me), one Approver (the shared manager), Contributors (both tech leads), Informed (the seven consumers). The value is the single named approver, because decisions requiring committee agreement do not get made.

Talk to both teams before the decision, not after

Take both tech leads for a coffee separately, before writing the document, and be straight about what you are doing:

"I think we're paying for two of these and I'm going to write it up for [manager]. Before I do, I want to make sure I've got your side right, and I want to know what you'd need for a consolidation to be acceptable to you. I'd rather your position was in the document accurately than have you read it and disagree with my summary."

Two effects. The document becomes accurate, which makes it more persuasive. And neither team is ambushed, which is what turns a technical disagreement into a political one. A staff engineer who surprises people with documents stops being included in things.

Give the losing team something

The single most useful move in the whole scenario. The team whose service is retired has spent a year on it and is being told it was wasted. Fix that explicitly:

They own the migration, so they are doing work rather than being done to.
Their distinctive features get ported, and they specify them.
Their tech lead is named in the decision as a contributor, and the announcement says so.
The retirement is framed as a consolidation both teams achieved, not as one team winning.

None of this is manipulation; it is accurate. Their work informed the outcome, and saying so is both true and what makes the consolidation actually happen rather than being nominally agreed and quietly ignored.

Where this goes wrong

Skipping the verification. Forcing a merge of two things that only look similar destroys value, and your credibility with it.

Arguing correctness instead of cost. "This is duplicated" is a statement nobody disputes and nobody acts on. Three engineer-years, a live correctness bug, and seven confused consumers is a statement people act on.

Trying to decide it yourself. With no authority, attempting to adjudicate makes you a participant in the conflict rather than the person resolving it. Your job is to make the decision easy for someone who can make it.

Going to the manager first. Both teams hear about it second-hand, conclude you went over their heads, and now it is political. Talk to the leads first, always.

Winning and then leaving. A decision without a migration plan, an owner and a deadline decays. Six months later both services are still running and the decision is folklore.

Not letting it go. If the decision goes the other way, the correct response is to support it visibly. Re-litigating a decided question is the fastest way to stop being consulted, and you will need the credibility for the next one.

Interviewer follow-ups

"The manager says 'you two figure it out'." That is a refusal to decide dressed as delegation, and it will not resolve, because neither team can concede without looking like they lost. I would go back once, in writing, with the cost quantified and a specific ask: "Both leads have made their case and neither can unilaterally concede. I need a decision from you by the 20th; here's my recommendation and here's what happens if we don't decide." Naming the cost of indecision is the lever. If they still will not decide, I would take option 3, extract the shared core as a library, because it captures some of the value without requiring authority nobody is willing to exercise, and I would document that we chose the second-best option because the decision was not made.

"One team has a director who will fight for them." Then it is a political problem and the technical argument alone will not win it. Two moves. Make the cost visible to the director's peer, so the conversation happens between people who can actually trade. And find the option where their team wins something real: they own the consolidated service, or their features are the ones that survive. Most of these fights are about status rather than technology, and an outcome where nobody is publicly diminished is achievable much more often than it looks.

"You're wrong and consolidation is a bad idea." Then I want to find that out in the verification step rather than after the migration starts, which is why it comes first. If I find it during, I say so publicly and quickly: "I pushed for this and I was wrong about X; here's what I missed." Being the person who reverses their own recommendation with evidence is worth more than being right the first time, and it is the behaviour that makes people trust your next recommendation.

"How do you influence with no authority in general?" Three things, in order. Information: be the person who has actually read both systems and can quantify the cost, because the person with the best data usually gets their way regardless of title. Framing: convert the technical issue into the currency the decision-maker manages, usually capacity, risk or customer impact. And relationships built before you needed them, because influence is mostly the accumulated willingness of people to take your call. None of that works if you have spent your credit on being right about small things.

"What if both teams agree but nothing happens?" That is the most common outcome and it is a planning failure rather than an agreement failure. Consolidation loses to whatever is on the roadmap every sprint, because it has no customer asking for it. The fix is that it needs an owner, a date and a place on someone's roadmap, plus a visible metric: number of consumers migrated, published monthly. Without that, "we agreed to consolidate" is a sentence people say for two years.

Production evidence

Tanya Reilly's The Staff Engineer's Path treats influence without authority as the defining staff-level skill, and specifically the practice of writing things down so a decision can be made by someone else with good information.

The DACI and RAPID decision frameworks exist precisely for this shape of problem: the value is a single named approver, because decisions requiring consensus among peers with equal standing do not converge.

Amazon's two-way door framing helps size the argument: consolidating two services is closer to a one-way door (the retired service's team disperses, its knowledge decays), so it warrants the written document and an explicit approver rather than an informal agreement.

Conway's law explains why the duplication exists in the first place: two teams with a communication boundary between them will build two systems, and the consolidation is as much an organisational change as a technical one. Which is why the answer involves a manager rather than an architecture review.

Interview delivery note

Open with the structure and with the premise check, because that is the part most candidates skip: "First move, information I'd gather, line I wouldn't cross. And my first move is to verify they're actually the same thing, because 'two teams building the same service' is often two teams solving different problems that look alike from outside. If that's what I find, saying so is the most valuable thing I can do."

Then the influence mechanics: "Assuming it's real, I don't argue that duplication is bad, because nobody disputes that and nobody acts on it. I quantify: three engineer- years of maintenance, seven downstream consumers and four of them integrating with both, and a live correctness divergence on refunds that nobody owns. Then I translate it into whatever the decision-maker already said they wanted capacity for, so consolidating becomes the way to get that."

Then the part that shows you have done it: "I'd talk to both tech leads before writing anything, so neither is ambushed and so the document is accurate. And I'd make sure the team whose service is retired owns the migration and gets its distinctive features ported, because 'your year of work is deleted' is why these things get agreed and then quietly not done."

Close with the line: "The line I wouldn't cross is trying to decide it myself. I have no authority, so my job is to make the decision easy for someone who does, and then support whichever way it goes, including if it goes against me."

The Staff & Team Lead Interview Reference