Building an application platform and a team that could own it

Teladoc Health

I was Engineering Manager at Teladoc Health from April 2022 to May 2026. I joined to create a mobile platform team and later led up to 12 people across iOS, Android, Web, Ruby backend and QA. Roughly eight product teams regularly used or contributed to the systems we owned.

I wanted the team to take more responsibility without having to wait for me. The difficult part was helping that happen while our scope, staffing and place in the organisation kept changing.

Starting the team

There was no team or roadmap to inherit. I hired engineers and worked with them and the product teams to find shared problems worth solving. For much of the early period, I had no dedicated PM or team lead, so I combined people management, technical direction and delivery.

We started with shared CI/CD, SDK delivery, repository checks and modernisation. Later my group took over Flow UI, a Server-Driven UI engine, and the Pulse component system. After mergers and layoffs, the scope stayed broad while the team lost capacity. I cut the backlog from roughly 400 items to about 200 so people could see what we would actually work on.

The final restructuring also added CRM, content and translation systems while removing an incoming engineering manager and a QA engineer. Product teams still depended on our contracts. Security, quality and controlled releases remained requirements throughout.

Running the shared platform

How product teams used the platform

1. 01

   Product requirements

   Around eight product teams regularly used or updated the shared platform.

2. 02

   An agreed component interface

   We agreed one component interface across platforms, alongside the screen contract rendered by Flow UI. Validation, accessibility and compliance belonged inside the component, rather than being decided again by each product team.

3. 03

   Platform implementations

   Android, iOS, Web and Ruby backend implemented the shared expectations separately.

4. 04

   Compatible releases

   Additions shipped as minor releases. Breaking changes waited for a major, and new screens could not add new legacy usage.

   Release rules

The newer components were less flexible than the legacy ones. We accepted that to keep UX, validation and accessibility more consistent across products. I needed to explain the trade-off and work through the integration problems with the consuming teams.

By my recollection, roughly 80% of product screens ran on Flow UI, and about 40% of those used the current Pulse component generation. The share grew as new screens used it and older screens were rebuilt. We did not have an adoption dashboard, so those are approximate figures.

Helping engineers grow

The contractor engineers had no formal promotion path or promotion-linked review system. I measured growth through scope, autonomy and judgment. Bounded tasks led to more ambiguity, end-to-end ownership and direct stakeholder contact, as delivery and review quality showed the person was ready. Deep specialist work counted alongside broader ownership.

Three engineers, different paths

03 cases

• Taking an integration from start to finish

  Case

  An Android engineer could solve problems but needed help with requirements, code quality and review.

  My decision

  I gradually increased the difficulty, asked him to review his own work first and helped him get advice from principal engineers while keeping responsibility for the result.

  Result

  Over about four years, he grew into complex SDK integrations from start to finish. I considered his work senior level, even though there was no formal title change.

• Building on a strength in accessibility

  Case

  An iOS engineer wanted to improve and showed a clear strength in accessibility.

  My decision

  I helped him build on that strength, asked for possible approaches before stepping in, and introduced a reviewed AI workflow for integration work.

  Result

  He became the person we turned to for accessibility, and his integration work improved.

• Owning an unclear problem

  Case

  Another engineer worked well from detailed tasks but needed support when the problem was unclear.

  My decision

  I asked him to think through the product and technical choices and take responsibility for how the system would be maintained.

  Result

  He grew into framing and delivering work independently and became the most AI-fluent engineer on the team.

I kept primary ownership explicit. Secondary owners, scoped rotations and cross-review helped with resilience and growth, while the primary owner kept the system context and responsibility.

When I left, people thanked me for defending the team and keeping the backlog, priorities and operating expectations clear through repeated restructurings. That is qualitative feedback from my recollection, not a formal performance measure.

Removing repeated work with AI

Before integrating a component, several engineers spent two hours or more comparing a specification with the behaviour already shipped on four platforms. Integration then took another two to four days. I wanted to give them more time for the work that needed their judgement.

I built a workspace with repository context, architecture notes, platform constraints and instructions for each stage. It prepared the initial analysis and contract proposal before the meeting. Engineers reviewed that proposal and kept responsibility for the code.

The component workflow

1. 01

   Read the spec and existing code

   The workflow compared the requested behaviour with Android, iOS, React and Ruby implementations.

2. 02

   Prepare a shared contract

   Engineers reviewed a proposal instead of reconstructing all the differences together in a meeting.

3. 03

   Implement and check

   Per-platform instructions supported implementation, demos and triage. Production changes still went through normal PR review.

   Human review

4. 04

   Introduce it gradually

   I used it myself, then piloted with two engineers and onboarded people individually before a company-wide demo.

The meeting dropped to no more than about thirty minutes. I estimate that the overall component-integration workflow became roughly 3x faster, saving around 120 developer-hours per month across about 12 daily users. The broader figures are reconstructions; I did not instrument the full baseline.

An earlier Copilot rollout had damaged the team's trust in AI. I needed to show useful work before asking people to try it. The tools were Cursor, Markdown instructions, Figma MCP and our normal GitHub review process. Platform engineers had no PHI access. A separate design-to-code experiment failed, and I kept that experience in the write-up too.

My part in the work

What I would change

• Measure the workflow and platform adoption before changing them.
• Keep a written record of growth in scope and autonomy when no formal review system exists.
• Keep experimental AI work clearly separate from workflows the team already relies on.
• Escalate earlier when scope grows while staffing authority disappears. The final restructuring added another system and removed people; prioritisation alone could not resolve that.

Technologies