MVB Field Guide  ›  Structure

Part 2: Structure. How We’re Organised

Strategy set the direction: optimise for adaptiveness, design the system rather than exhort the people. Structure is where that direction first becomes concrete, because how we group people determines most of what they can and cannot do before anyone writes a line of code.

Layers of Structure

There are four levels of structure within our company: Corporate (the whole company), Departments (our Product R&D and Platform Departments), Value Streams (a team-of-teams), and the single Team. Each level has its own roles, artefacts, and events.

Corporate

The Corporate layer includes everyone in the company. Describing this layer in detail is not within the scope of this handbook.

Departments

This handbook binds two departments: Product Engineering (the software product R&D organisation) and Platform Engineering (the enabling infrastructure organisation). When you adopt it, substitute your own department names. Department leadership has control over these departments and a varying but increasing degree of influence on the broader organisation.

This layer is the primary interest and “home” of our CTO, VP of Engineering, VP of Delivery, and Enterprise Performance Coach, who support the entire department.

Where this handbook needs to name a second executive owner alongside the CTO (for prioritisation conflicts, expedited work, and due-date approval), we use the CMO (Chief Marketing Technology Officer). Substitute whichever executive shares demand-shaping authority with your CTO; the design requires exactly two named executives so that escalation always has an answer and never has a committee.

Value Streams

Value Streams are teams-of-teams that create value for end users.

Mature Value Streams typically contain 4–8 teams. They rarely depend on other Value Streams to deliver value but will sometimes depend on our Platform team. We maintain a canonical Teams sheet listing our current Value Streams, Capabilities, and Teams.

We seek to eliminate dependencies so we can eliminate wasteful dependency-management Processes.

We minimise product-related dependencies between Value Streams, and between Value Streams and our Platform Department.

We currently prioritise all large requirements across Value Streams because we need to control demand for a few shared bottleneck teams and the Platform Department. Our goal is for every Value Stream to gain platform capability: the CI/CD, cloud infrastructure, security, observability, and incident tooling that Platform Engineering provides today are capabilities to evolve and distribute, not a problem to remove. As we federate those skills out to independent Value Streams, each Value Stream can be prioritised independently, and the people who built the platform become the seed of that capability everywhere. Until then, the platform team remains a shared constraint, and Part 3’s demand-governance rules exist largely to protect it.

Every Value Stream has a Value Stream Owner, who is the primary software product authority for that Value Stream.

The Value Stream Owner is responsible for prioritising all work for their Value Stream’s teams on the Value Stream’s Backlog (described in Part 3). However, in specific cases, such as launching a new brand or market, a Corporate-level requirement on the Department Backlog may require the CTO to explicitly override the Value Stream Owner’s priorities to ensure concurrent delivery.

Capabilities

Where a Value Stream contains two or more teams working in related domains, we group them into a Capability: a set of teams that share a Backlog and can each pull from it. For example, a “Core” Capability might contain three teams (Core:1, Core:2, Core:3) that plan against one shared queue. Not all Value Streams need Capabilities; they exist only where the natural structure of the work warrants them. Their purpose is to widen the group of people who can pick up the most valuable work, which is the structural prerequisite for consolidating Team Backlogs (see Part 3).

Teams

Output-oriented team vs outcome-oriented team

In the Org Topologies grid from Part 1: TASKS- and CAPS-level archetypes are output oriented; PART- and WHOLE- archetypes are outcome oriented.

The distinction has commercial teeth. The Org Topologies authors state it bluntly: more output does not mean more outcomes. More output usually means more holding and coordination cost, which can lower profit (an outcome). Investing to increase outcomes is justified, while “investing” to increase output is suspect (Krivitsky, Larman & Flemm, Org Topologies Primer, 2025). Feature bloat is the visible symptom of an organisation optimised for output. When a team can articulate its velocity but not the customer outcome its last iteration served, this is the section to reread.

To the extent possible, we create end-to-end, cross-functional teams.

Our standards for a well-formed team are:

  • Deeply accountable for their domain, fully owning the design, development, deployment, and maintenance of their features or services. Responsible for customer outcomes, not task outputs.
  • Eager to master all necessary skills within their domain and proactively reduce external dependencies.
  • Within 3 time zones of one another, ensuring effective real-time collaboration without excessive overhead.
  • 100% dedicated to the team, with no part-time members or resource-sharing across multiple teams.
  • Formed more than 3 months ago, with rare changes to composition (no additions/removals in the last 4 weeks), allowing the team to stabilise, refine workflows, and improve over time.
  • Possess all necessary skills to deliver customer value, with deep expertise in key areas and broad competence across the stack, ensuring no single point of failure.
  • Fully self-reliant within their scope, eliminating the need for functional sub-teams (no separate “QA team,” “ops team,” or “architects”).
  • Collaborative yet protective of autonomy, interfacing with other teams at well-defined boundaries, including teams outside the department, while avoiding excessive inter-team dependencies.
  • Diverse in key dimensions (age, gender, seniority, experience) to improve decision-making, adaptability, and resilience.
  • Psychologically safe, where team members feel comfortable asking questions, admitting mistakes, and raising concerns without fear of embarrassment or retribution. A team where no one raises concerns is a team that isn’t safe to speak up.

Few teams meet every standard on this list every quarter. A team that cannot (a part-time specialist it cannot absorb, a composition change forced by attrition, a time-zone spread inherited from a reorganisation) has not failed; it is carrying a structural constraint. Name the gap at the Department or Value Stream Retrospective and escalate it as an org-design finding. The standards describe the target the organisation designs toward, and leadership owns the gap, not the team.

Larman & Vodde highlight that “cross-functional feature teams reduce the overhead of specialised subgroups and dependencies, allowing a single team to learn and deliver truly end-to-end solutions.” A well-formed team can shift focus or scope as market needs evolve while retaining the skills and autonomy to handle development from design through deployment.

Rather than binding a team to one domain indefinitely, we emphasise business outcomes and adaptability. In the future, we will create a “team(s)-of-teams” structure (PART-3 up to potentially WHOLE-4) which borrows heavily from the above criteria but reduces a team’s rigid domain ownership in favour of greater cooperation against fewer, perhaps even only one, true Product Backlogs.

We reduce overhead by combining skill sets on each cross-functional team and minimising “single-function” roles.

As Larman & Vodde note: “Multi-skilled workers help avoid single-skill bottlenecks, reduce overhead, and speed up the flow of work.” Comb-shaped skills also enable teams to take on broader scope mandates, moving from task-level execution toward owning full outcomes. AI tools accelerate this: they make it practical for individuals to develop competence across disciplines that previously required years of specialisation.

Rather than appointing a separate “Architect,” “Testing Manager,” or “UI designer,” each team member is empowered and expected to grow comb-shaped skills and collaborate on architecture, coding, UX, and QA. This cuts sign-off steps and handovers and increases shared ownership. We still maintain a few critical unique roles (for instance, a Value Stream Owner) where they clearly add value, but we avoid splitting teams into narrow specialties that slow us down.

Most teams have a Product Manager who reports to the Value Stream Owner. This Product Manager has responsibility for and authority over their Team Backlog.

The PM role is evolving with the system, not being declared wrong. Be honest about what the role carries today before asking it to evolve. A working inventory: resolving stakeholder ambiguity into buildable Stories at refinement (the largest single item, and substantive work rather than administration); coordinating launches whose external deadlines compress toward the end; UAT coordination; the release-notes rotation; cross-cover when a peer PM is out; and continuous backlog hygiene. Almost none of this appears on any plan, and all of it costs time and attention. The evolution described here only works if that coordination work is named, budgeted, and progressively automated or redistributed, never treated as overhead the PM should somehow do less of while outputs stay constant.

As we move closer to the product-level archetypes (PART-3/-4), we will decouple PMs from individual teams and have them act broadly across the Value Stream or the whole department, and the distinctive PM value shifts from writing stories toward strategic direction, financial modelling, and domain navigation. The message to every PM reading this: the system is evolving, and your role evolves with it, from team output owner toward Value Stream product leadership.

Engineering Coaches are present for each team. Their role is not that of a manager but of a coach: they do not tell the team what to do or how to do it, but seek to develop all people on their team to their fullest potential.

See Appendix B: Manager vs Coach.

We do not recognise any hierarchy within the team itself. Although each team has an Engineering Coach available, the coach will not assign Stories or Checklist Items to people, unilaterally dictate architecture or solutions, or prioritise work (except P0 Incidents). As with any Builder, they can propose Stories to the Value Stream Owner, who would be wise to consider their suggestions thoughtfully. Our Enterprise Coach helps Engineering Coaches transitioning from traditional management backgrounds become better coaches, through one-on-one mentoring, coaching, and referrals for further training as needed.

Summary of Roles

  • Department
    • CTO: Owns the organisational design described in this handbook, jointly owns the Department Backlog with the CMO, and holds final authority on expedited work and due dates.
    • VP of Engineering: Leads technical execution across Value Streams; enables quality, scalability, and velocity; partners with Product and Coaching to align delivery with enterprise goals.
    • VP of Delivery: Owns the cross-Value-Stream planning and refinement schedule; hosts Joint Backlog Refinement; first escalation point for WIP overload.
    • Enterprise Performance Coach: Guides adaptive organisational design and strategic flow; develops transformational leadership; stewards this handbook, the work-management tool configuration, and the reporting built on it.
    • IT Director: Oversees infrastructure and Tier 1 support (not a patching unit for dysfunctional systems).
  • Value Streams
    • Value Stream Owner (VSO): Leads personas, problem statements, backlog management, innovation, requirements, user scenarios, release planning, and reviews for a Value Stream.
    • Product Manager (PM): Supports the Value Stream Owners in their activities within and across Value Streams; drives refinement and supports UAT.
    • Engineering Coach (not “Manager”): Develops the Builders to their fullest potential. See Appendix B.
  • Teams
    • Only Builders: no “front-end developer” vs “tester” distinctions (these are skills, not roles or titles). No hierarchy of any kind (such as “team leads”).

As AI matures, we expect a team of 1 PM and 8 engineers to converge toward 2–3 Builders with complementary specialisations and shared end-to-end capability. We are experimenting with smaller, builder-heavier teams now rather than waiting. Internal titles follow the Builder naming convention (“Senior Builder in Engineering,” “Staff Builder in Product,” “Senior Builder in Engineering Management”), benchmarked against conventional market titles for compensation purposes (see Part 4).

Process →