Practice vocabulary for communicating platform roadmaps to developer teams: quarterly plans, backlog language, deprecation notices, and migration guide communication.
0 / 5 completed
1 / 5
A platform engineer presents to developer teams: "In Q3 we plan to ship self-service database provisioning and a unified secrets management API." What communication purpose does 'in Q3 we plan to...' serve?
'In Q3 we plan to...' is roadmap language that communicates direction without over-committing. Developer teams need this signal to plan ahead — they might delay a decision knowing a better platform solution is coming. The word 'plan' is intentional: it sets expectations without locking the platform team into a hard commitment. Compare to 'will ship' (commitment) vs 'plan to ship' (intention with caveats).
2 / 5
A platform team tells developer teams: "The new observability stack is in our backlog — it will not be in scope for Q2." What does 'in our backlog' communicate?
The backlog is the holding area for future work. When platform teams say 'it is in the backlog,' they are communicating three things: we have captured the need, it is not currently prioritised, and it may come later. This prevents developer teams from assuming the feature is coming soon or has been forgotten. A healthy platform team reviews the backlog publicly, shows why items are prioritised or not, and is honest about items that may never leave the backlog.
3 / 5
A platform team sends a notice: "The v1 deployment API will be deprecated on December 1st. All teams must migrate to v2 before this date." What makes a good deprecation notice?
Good deprecation notices follow a formula: enough lead time (typically 3-6 months for internal APIs, 6-12 months for public APIs), clear deadline, reason for deprecation, the migration target, and a migration guide. The notice should be sent through multiple channels (email, Slack, documentation). Teams need time to plan migrations around their own delivery commitments — a 2-week deprecation notice for a widely-used API causes real disruption.
4 / 5
A platform team publishes a 'migration guide for teams' alongside a deprecation notice. What should a good migration guide contain?
A migration guide enables self-service. Without it, every team blocks on the platform team for help — which does not scale. The gold standard: concrete before-and-after code snippets, a runnable example repository, clear explanation of any behaviour changes (gotchas), testing instructions, and a FAQ section for common migration questions. Teams should be able to complete the migration independently using only the guide.
5 / 5
During a platform roadmap review, a developer team asks: "Is the current Kubernetes abstraction layer going to be supported long-term?" How should a platform team respond to indicate long-term commitment?
Developer teams need stability signals to make architectural decisions confidently. If a platform team cannot commit to long-term support, teams will build workarounds or avoid the platform entirely. Platform roadmap communication should clearly distinguish: stable core capabilities (long-term commitment, full deprecation process), experimental features (may change or be removed), and deprecated features (being phased out). 'This is a core platform primitive' is a strong stability signal.