You join a platform group and find four teams have each written their own retry-and-backoff library, with different defaults, and a fifth team has none. Everyone knows this is duplicated. Nobody has consolidated it. What is the diagnosis, and what do you change?

The first three things I would look at

1. When each library was written, and by whom. Four independent implementations within a short window is a gap in the platform. Four spread over five years is a platform that existed and was not usable.
2. What the defaults are. Four retry policies with different jitter, caps and budgets is not merely duplication; it is four different behaviours during an incident, and the aggregate is a system whose overload response nobody can predict.
3. What happened to the last attempt to consolidate. There is almost always one. The reason it failed is the actual finding.

The diagnosis

The duplication is a symptom; the cause is that adopting someone else's library costs a team more than writing their own. That cost is usually concrete and boring: no owner answering questions, no versioning story, a dependency on a shared artifact whose release cadence the team does not control, an API that fits the author's service and not theirs, and a migration nobody has time for.

The second half of the diagnosis is incentives. No team is measured on removing a library, and consolidation is a quarter of work whose benefit accrues to the platform group. Everyone agreeing it should happen is consistent with nobody being the one it happens to.

The fifth team with no retries at all is the most informative data point: it says there was no default. A library that is not in the service template is a library people must go and find.

What to change, in order

1. Make it arrive rather than be adopted. The retry policy belongs in the service template and the client library that every service already uses to make calls — often the mesh, the generated client or the HTTP wrapper. Nobody adopts a retry library; they adopt a scaffold.
2. Pick one behaviour and write down why. Exponential backoff with full jitter, a per-request retry budget rather than a fixed count, retries only on idempotent operations, and a deadline propagated from the edge. Publish the numbers, because a standard without defaults is a document.
3. Migrate by doing it yourself for the first two teams. The platform group writes the pull requests. This is the only step that reliably works, and it is also how you discover which requirements the existing libraries were serving.
4. Delete on a schedule, publicly. The old libraries get a deprecation date and an owner. Unremoved alternatives are the reason the next consolidation also fails.
5. Measure adoption as a percentage of services on the template version, reported monthly. Choose one number and show it, or the effort dissolves into goodwill.

The misleading signal

Everyone's agreement that this should be fixed. It reads as a mandate and it is the reason nothing happened: agreement is free and the work is not. Treat unanimous agreement plus no progress as evidence that the cost is on the wrong side of the transaction.

When this is the wrong answer

If the four libraries encode genuinely different requirements — one service talks to a third party with a published rate limit and a retry-after header, another is internal with a strict deadline — then consolidation into one policy would be a regression, and the right output is a shared library with three named profiles. And if there are eight engineers in total, this is not worth a programme: paste the good implementation into the template and move on. Platform work earns its cost at the scale where the coordination it removes is bigger than the coordination it adds, which is usually somewhere north of ten teams.