Platform API Deprecation
Retiring a platform capability that other teams depend on, with the migration burden treated as the platform's problem rather than theirs.
Deprecation is where platform teams lose the trust they spent years building, because the failure mode is asymmetric: the platform team saves maintenance effort, and every consuming team pays migration cost they did not plan for.
The mechanics that keep trust intact are unglamorous. Know exactly who is using the capability before announcing anything — telemetry on usage, per consumer, is a prerequisite and is missing far more often than teams admit. Give notice proportionate to the effort you are imposing, expressed in release cycles rather than dates. Ship the replacement before deprecating the incumbent, with a migration path that is documented and, wherever possible, automated as a tool or bot-raised change. And run the two in parallel long enough that migration can be scheduled rather than dropped into someone's sprint.
The tell of a healthy platform is that deprecations are boring. The tell of an unhealthy one is teams pinning old versions indefinitely and building private workarounds — which is what everyone does after being burned once, and it is very hard to reverse.