# How I run a platform other teams depend on Source: https://manaienko.com/how-i-work/platforms-other-teams-depend-on/ Author: Artem Manaienko One contract, implemented per platform. Migration enforced by a governance rule instead of a campaign. And a backlog cut down to the capacity that actually exists. ## My principles 06 operating rules 1. [01 Define one contract, implement it per platform](#practice-platforms-other-teams-depend-on-principle-1) 2. [02 Migrate by governance rule](#practice-platforms-other-teams-depend-on-principle-2) 3. [03 Backward compatible by default](#practice-platforms-other-teams-depend-on-principle-3) 4. [04 Buy consistency with flexibility, and say so](#practice-platforms-other-teams-depend-on-principle-4) 5. [05 Cut the backlog to real capacity](#practice-platforms-other-teams-depend-on-principle-5) 6. [06 Build the function before the roadmap](#practice-platforms-other-teams-depend-on-principle-6) ### Define one contract, implement it per platform The platform's product is the agreed interface, not the code behind it. Android, iOS, web, and backend each implement the same expectation separately. The expectation itself gets negotiated once. ### Migrate by governance rule New work may reference the legacy generation but may not add new usage of it. A rule that applies to every incoming change moves a migration further than a project plan for finishing it ever does. ### Backward compatible by default New components ship as minor releases because they are designed not to break consumers. Breaking changes wait for a major, so a consuming team can plan around them instead of discovering them. ### Buy consistency with flexibility, and say so A standardised component is less configurable than the legacy one it replaces. That is the trade: lower variance across products and platforms, in exchange for a stricter contract. Argue it openly instead of smuggling it in. ### Cut the backlog to real capacity A backlog full of work the team cannot deliver is a way of avoiding a decision. Under sustained capacity loss I triaged aggressively instead of preserving the appearance of scope. ### Build the function before the roadmap When a platform team does not exist yet, there is no backlog to inherit. The first job is hiring, an operating model, and finding the shared problems worth owning. With the engineers, not for them. ## What that looked like 02 cases ### A Server-Driven UI engine and a design system, run as one layer Teladoc Health · 2024-2026 **Situation:** My organisation was reassigned to Flow UI, a production-critical Server-Driven UI engine, and later merged with the Pulse design system. One group now owned the engine, roughly 52 newer multi-platform components, 50+ legacy components, two separate web implementations, a Ruby backend, and QA. It served the core product, several business-unit products, and around eight product teams that consumed or updated the platform regularly. Two component generations coexisted. No adoption telemetry existed. And after mergers and layoffs the scope stayed broad while stable capacity fell. **What I did:** - Treated the engine and the design system as connected layers instead of two teams: one expected technical interface, implemented across platforms, integrated into the SDUI engine. - Set the migration rule that carried the transition: new screens use the current path, and may not add new legacy component usage even where they still reference it. - Kept new components backward compatible so they could ship as minors, reserving breaking changes for majors on a roughly nine-to-twelve-month cadence. - Continued extracting engine-specific functionality out of the monorepository into a dedicated Ruby API core. - Triaged the active backlog down hard rather than carrying work the reduced team could not deliver. **Outcome:** Roughly 80% of product screens ran on Flow UI, with about 40% of those using Pulse components and that share rising as new work used Pulse and older screens were progressively rebuilt. The active backlog came down from roughly 400 items to about 200. The platform kept delivering through repeated team replacement and capacity loss. Adoption percentages, component counts, and backlog figures are approximate recollection. No adoption dashboard or dependency inventory existed in that environment. That is itself the first thing I would fix. Component model Legacy generation ### Flexible, and different everywhere - Older parameterisation and backend model, configurable in almost any direction. - Each product surface resolved validation and behaviour locally. - Accessibility and compliance handled per implementation. - Materially more complex to integrate, and inconsistent across platforms. Standardised components ### Stricter contract, lower variance - Parameterised components with standardised UX, validation, and platform behaviour. - Accessibility and compliance handled once, inside the component. - Consumers attach integration behaviour and custom validators at the edges. - Less configurable by design. That is the price of consistency. ### Building the platform function from zero Teladoc Health · 2022-2024 **Situation:** There was no mobile platform team. No backlog to inherit, no roadmap to execute, no dedicated product manager or team lead for most of the period. Just a general sense that product teams kept solving the same problems again in their own stacks. **What I did:** - Hired the initial six-person team and rebuilt it where hires were not the right fit. - Defined the roadmap with the engineers instead of handing one down, because the shared problems were only visible from inside the product teams. - Built shared CI/CD, SDK delivery, PR checks, quality gates, and code standards as the first products of the function. - Took on release governance and deployment architecture across 30+ white-label client applications. - Ran toolchain upgrades, modularisation, and language modernisation alongside the delivery work. **Outcome:** A function that did not exist became the shared delivery path for product teams, with release stability and incident response materially better than the per-team model it replaced. Crash-free usage moved from roughly the mid-90% range to around 99.5%, and modern-language code reached roughly 60% of the estate before the programme was paused. Stability and language-adoption figures are approximate. The metric definitions, platforms, and measurement periods are not preserved, so treat them as direction rather than audited results. The limit I hit The final restructuring added a CRM, content, and translation system to the same group while removing an incoming engineering manager and a QA engineer. Scope kept growing. Staffing authority did not. Next time I would define escalation and exit criteria in advance, for exactly this case: accountability expands and the authority to staff it does not follow.