Workstreams are large areas of work, not restricted to a single code repository but with a focused area of concern. Workstreams maintain a multi-month technical and product view, while quarterly product priorities determine their active capacity allocation and ordering. FOC product milestones guide workstream prioritisation and inform their direction, but workstreams maintain a view of work beyond immediate milestones so engineers always have something meaningful to be working on, even when it's not yet part of product prioritisation.
Product and engineering leadership must continually work to ensure appropriate prioritisation between workstreams, to maximise the impact of individual team members toward overarching FOC product goals.
Engineers would typically be part of more than one workstream, shifting their priorities depending on FOC product needs and workstream demands. Workstreams should allow for greater knowledge sharing and reduction in bus-factor. As AI coding agents allow engineers to range much further than their historical core competences—across languages, codebases, and areas of the stack—we expect greater end-to-end system understanding and more overlap in knowledge and capability across the team. The traditional cost of context-switching between areas of a complex stack has been a limiting factor for cross-cutting team structures; that cost is materially lower in 2026, and this model is designed to take advantage of that shift.
Membership of a workstream is not exclusive. Expertise will be required from outside a workstream's membership, so engineers may be brought in for specific design concerns, to assist with unfamiliar codebases, or for other bespoke knowledge.
Each workstream should have a primary lead who is responsible for ensuring the workstream has a coherent target and maintains momentum toward that target. This includes maintaining a stack-ranked backlog, owning weekly reporting, flagging risks, and solving them promptly. Workstream leads, along with at least some members, are expected to participate actively in FOC product research and direction-setting, or to stay actively informed of these areas.
There exist critical codebases in the FOC stack where quality must be maintained. Workstreams are expected to impact many codebases rather than being codebase-focused, so we establish clear codeowners for core repositories. Codeowners will be assigned automatically as reviewers for all pull requests (via the GitHub CODEOWNERS mechanism) and it is expected that at least one designated codeowner sign off on any non-trivial change. We may relax or tighten this requirement depending on throughput impact. The aim is not to create a bottleneck but to ensure:
Codeowners are expected to actively monitor for review requests and engage promptly. They are responsible for managing their own prioritisation between delivery work and review obligations. Multiple codeowners will be assigned to core repositories so the burden does not fall on a single individual. Where prioritisation is unclear, assistance from engineering leadership should be sought.