Designing a Scalable Release‑Train Development Process at Tubi

In the tech world, software development methodologies spark endless debate, from waterfall to agile and Kanban, often with inconsistent interpretations.

As the Tubi team grew, engineers felt lost in prioritizing, identifying key tasks, and spotting gaps, so a group voluntarily launched a three‑month trial to build a system that fits their current needs and can scale with the company.

Key Observations

Even a small task can be completed in a day

Estimating development time is notoriously hard; teams tend to underestimate difficulty, leading to pressure, frustration, and missed deadlines.

Deadline‑driven development is doomed

For a company like Tubi, setting strict deadlines for every task is meaningless because most work improves core products rather than serving external customers; the best answer to “when will this be done?” is “as soon as possible.”

However, when external dependencies exist, deadlines still provide value.

Release Frequently

Frequent, rhythmic releases suit a user‑focused startup. While sprint‑based agile was considered, rigid weekly/bi‑weekly cycles felt too stiff, causing pressure near sprint ends and encouraging conservative estimates.

Roles Vary Across the Team

Inspired by Paul Graham’s “Maker’s Schedule, Manager’s Schedule,” every engineer contributes, while the R&D lead handles meetings, prioritization, and cross‑team coordination. Individual contributors need long focus periods and clear product goals.

Team Needs Differ

Running a video‑streaming service at Tubi’s scale requires extensive infrastructure; machine‑learning teams need research time, while iOS/Android teams push updates via app stores, and backend teams can release multiple times daily.

From these considerations, Tubi defined three clear development goals:

Maintain a regular, predictable release rhythm with high quality.

Focus on high‑impact work to guide prioritization.

Enjoy the work by fostering a learning‑oriented culture.

They also listed what to avoid:

Using KPI metrics like lines of code to measure engineer output.

Over‑engineering estimation for trivial tasks, while still performing reasonable risk assessments for large projects.

Excessive meetings; only essential ones should remain.

A unique constraint is the 15‑hour time difference between the Beijing and San Francisco offices, making daily stand‑ups impractical.

Adopting the Release Train Concept

The team introduced a Release Train analogy: completed, QA‑passed tasks join a queue; the train departs on schedule regardless of new features, and unfinished features wait for the next train. Schedules need not be synchronized across teams—backend may ship daily, mobile every three weeks.

Prioritization queues, borrowed from Kanban, let engineers pick the highest‑priority tasks, reducing bottlenecks and preventing over‑commitment.

Team leads drive queue ordering, but each team can decide how to keep their queue up‑to‑date, either centrally or collaboratively.

Tooling Support

After moving from JIRA to ClubHouse, the team embraced its clean UI/UX and GitHub integration, even open‑sourcing a CLI tool that uses the ClubHouse API to create temporary tasks.

After a year of using this methodology, the overall sentiment is positive, though not perfect.

What Works Well

Client teams release more frequently, predictably, and with higher quality.

Fewer meetings burden the engineers.

Small projects are planned and executed efficiently.

Small tasks receive proper attention.

Priority queues give engineers flexibility to tackle what they deem most valuable.

Task status automatically updates with code changes, PR creation, merges, and releases.

Areas for Improvement

Backend teams struggle to stick to fixed schedules, sometimes needing ad‑hoc releases.

Meeting count could be reduced further.

Better planning is needed for large, cross‑team projects.

Large multi‑team initiatives still feel chaotic.

Maintaining the priority queue is more difficult than expected.

Tools need enhancements to handle backlog tasks.

If you are interested in joining a team where the process serves the engineers—not the other way around—and want to focus on building great software, consider applying to Tubi.