Adoption Barrier Diagnosis

Three notification services and four schedulers did not appear through indiscipline. Each was locally rational: a team needed something, the existing option did not fit or was not discoverable, and building took less time than negotiating.

Duplication is therefore a measurement of the adoption barrier, and consolidating without removing that barrier reproduces the duplication within eighteen months — usually with a different set of teams.

Why it matters

Rationalisation programmes are expensive and frequently fail. The failure is almost always the same: a chosen system, a mandate, partial migration, and an estate that now contains both the old systems and the new one.

Implementation patterns

• Inventory using usage telemetry, not a survey. The instances nobody admits to are the informative ones.
• Interview the teams that built their own. They have already done the analysis of why the shared option did not fit, and it is usually two or three specific capabilities.
• Assess against the union of real requirements, identifying which teams have needs the others do not, since those needs are the reason several exist.
• Choose one and acknowledge the choice is partly arbitrary, tie-breaking on operational maturity and the owning team's capacity rather than on a feature comparison.
• Build the capabilities that caused the divergence before asking anyone to migrate.
• Fund the migration. Asking teams to absorb it from their own capacity is the step that most often kills the programme, because it loses every comparison against their own delivery commitments.
• Close the door so new instances cannot be created — otherwise four become five.
• Leave alone what is cheap to run and expensive to consolidate. Rationalisation is an investment with a return, and some instances have none.

Industry example

Multi-product organisations such as Freshworks accumulate this predictably, because each product line has enough autonomy to build and enough difference to justify it. The pattern that distinguishes successful consolidation is that the surviving system became genuinely better first and migration was funded and tooled — rather than a mandate issued and compliance measured.

Failure scenarios

• Consolidating without removing the adoption barrier, so it recurs.
• A mandate producing compliance theatre: minimum migration, old system retained for what the new one cannot do, both now in the estate.
• Feature-comparison tie-breaks, which pick the most complete system rather than the best-operated one.
• Unfunded migration, which does not happen.
• Pursuing uniformity where the return is negative.

Trade-offs

Building the divergence-causing capabilities into the surviving system makes it larger and more complex, sometimes absorbing requirements that only one team has. That is a genuine cost and occasionally the right answer is to keep two systems permanently for two genuinely different use cases.

The discipline is deciding that explicitly rather than arriving at it by failing to consolidate — a deliberate two is manageable, an accidental four is not.

Interview question

"Your organisation has four job schedulers. Before you propose consolidating them, what would you want to know, and what would make you recommend keeping two?"