# How I run a platform other teams depend on Source: https://manaienko.com/how-i-work/platforms-other-teams-depend-on/ Author: Artem Manaienko I run shared platforms as internal products. That means agreed contracts across teams, predictable release and migration rules, and explicit choices about reliability, flexibility and the scope we can support. ## My principles 04 operating rules 1. [01 Agree on the behaviour across platforms](#practice-platforms-other-teams-depend-on-principle-1) 2. [02 Give teams a migration path they can follow](#practice-platforms-other-teams-depend-on-principle-2) 3. [03 Be honest about what standardisation costs](#practice-platforms-other-teams-depend-on-principle-3) 4. [04 Keep the scope manageable](#practice-platforms-other-teams-depend-on-principle-4) ### Agree on the behaviour across platforms Android, iOS, web and backend have different implementations. I want us to agree on the interface and expected behaviour together, so consuming teams do not have to resolve the same differences for every component. ### Give teams a migration path they can follow We kept the legacy generation working while new screens used the current components. Existing legacy references could remain, but new screens could not add new legacy usage. Backward-compatible additions shipped as minor releases; breaking changes waited for a major. ### Be honest about what standardisation costs Our newer components were less flexible. In return, they shared validation, accessibility and behaviour across products. I needed to explain that trade-off and work through the cases where a product needed something different. ### Keep the scope manageable I cut the backlog when we lost capacity. Eventually the scope kept growing without the authority to staff it, and I could not keep solving that through prioritisation alone. I would escalate that situation earlier next time. ## Building and running the platform 02 cases ### Bringing the UI engine and design system together Teladoc Health · 2024-2026 **Situation:** My group took over Flow UI, a production-critical Server-Driven UI engine, and later the Pulse design system. We owned roughly 52 newer components plus 50+ legacy components, two web implementations, a Ruby backend and QA. Around eight product teams regularly used or updated the platform. After mergers and layoffs, we had fewer people supporting the same broad scope. **What I did:** - Ran the engine and component system as connected layers, with a shared interface implemented across platforms. - Kept new screens on the current components, with no new legacy usage. Existing references could remain until migrated. - Kept additions backward compatible and reserved breaking changes for majors, on a roughly nine-to-twelve-month cadence. - Continued extracting engine functionality into a dedicated Ruby API core, and cut the backlog to fit the remaining team. **Outcome:** The platform kept delivering through team changes and capacity loss. Roughly 80% of product screens ran on Flow UI, and about 40% of those used Pulse. We reduced the active backlog from roughly 400 items to about 200. The adoption, component and backlog figures are approximate recollection. We had no adoption dashboard or complete dependency inventory. I would build those earlier next time. Component model Legacy generation ### More flexibility, more local decisions - Broad configuration options. - Validation and behaviour resolved by each product. - Accessibility handled separately in each implementation. Newer components ### Shared behaviour across products - Standard UX, validation and accessibility within each component. - Consuming teams add integration behaviour and custom validators. - Fewer configuration options to keep behaviour consistent. ### Starting the platform team Teladoc Health · 2022-2024 **Situation:** There was no mobile platform team when I joined. Product teams were solving similar problems separately, and we had to find which ones were worth taking on together. For much of this period, I had no dedicated PM or team lead. **What I did:** - Hired the initial six-person team and made changes where hires were not working out. - Defined the roadmap with the engineers around CI/CD, SDK delivery, repository checks and quality controls. - Took responsibility for shared releases and deployment across 30+ white-label client applications. - Ran toolchain upgrades, modularisation and language migration alongside delivery work. **Outcome:** Product teams gained shared delivery tools and support. By my recollection, release stability and incident response improved over the separate per-team model. Crash-free usage moved from roughly the mid-90% range to around 99.5%. Modern-language code reached roughly 60% before that programme was paused. The stability and language figures are approximate. The original metric definitions, platform breakdown and measurement periods are not preserved. Where I reached the limit The final restructuring added a CRM, content and translation system while removing an incoming engineering manager and a QA engineer. I still owned the delivery, but could not staff it. Next time I would agree earlier on when to escalate, what scope to drop and when I could no longer take responsibility for the arrangement.