CTO Team Structure: Engineering Org Models Compared

A CTO can organise engineering in four common ways: by discipline (functional teams), by product or customer outcome (cross-functional stream-aligned teams), around a shared platform with product teams on top, or in a matrix with guilds or communities for craft. Most startups should begin with one or two cross-functional teams and add structure only when coordination, not headcount, becomes the problem.

This guide compares those models, explains Conway's law and the Team Topologies team types from their original sources, shows how structure usually changes with stage and gives a decision process. DORA and Bessemer Venture Partners supply the only sourced thresholds and findings; the comparisons and recommendations are our editorial judgement and are labelled. For headcount-driven suggestions, use the free engineering org chart tool.

What are the main ways to structure an engineering team?

The four common models are functional, cross-functional product teams, platform plus product teams and matrix. None is correct in general; each fits a stage and a kind of product. The table is our editorial comparison, with sourced notes beneath it.

Two sourced points inform the table. DORA's research on loosely coupled teams recommends cross-functional teams with product, development, test and operations representation so teams can work autonomously, and says organisational and technical structures are predictors of continuous delivery (DORA, loosely coupled teams). DORA's research archive also records, from its 2019 report, that communities of practice outperform centers of excellence (DORA research), which supports the guild or community approach in the matrix model over a central authority.

What does Conway's law mean for your engineering structure?

Conway's law says that any organisation that designs a system will produce a design that copies its own communication structure. Melvin Conway published it in Datamation in 1968. For a CTO the consequence is practical: if three teams must coordinate to ship one feature, your architecture will tend to show three tightly coupled parts.

The law cuts both ways. Conway's own page states that because the first design is almost never the best possible, the prevailing system concept may need to change, which means the organisation must be able to change its structure as well (Melvin Conway). DORA's guide describes the deliberate use of this idea as the "Inverse Conway Maneuver": designing team structures to produce the architecture you want (DORA).

Three practical uses:

1. Start from the architecture you want and shape teams around the boundaries you would like in the system.
2. Treat repeated cross-team coordination as a design signal. If two teams are always in the same meeting, either merge them or redraw the boundary.
3. Do not reorganise to fix an architecture problem alone. Changing teams without changing interfaces moves the pain.

What are the Team Topologies team types?

Team Topologies, by Matthew Skelton and Manuel Pais, defines four fundamental team types and three ways teams interact. Its site describes them as follows, and the table adds our note on when a startup is likely to need each.

Source for both tables: Team Topologies, key concepts. The site also states a principle that matters for sizing teams: "Teams can only handle so much complexity before breaking down." Cognitive load is a better test of whether a team's remit is too large than a fixed headcount. Our free CTO resources guide lists the book alongside other reading on organisation design.

How does team structure change as the company grows?

Structure follows headcount and complexity, and the changes arrive in steps. Bessemer Venture Partners' Atlas guide gives the sourced breakpoints: up to about 10 engineers a hands-on technical leader with engineers reporting to the CTO, at least one manager beyond 10, and a decision around 20 about whether the CTO or a VP or SVP leads the larger organisation. It also advises making a deliberate choice between per-team DevOps and a dedicated quality team, because that choice quickly becomes culture (Bessemer Atlas).

The headcounts after 20 are not sourced; they are our rule of thumb and vary widely by product. The scaling an engineering org guide covers the breakpoints in more depth, and when to hire your first engineering manager covers the first management layer. The CTO's own job changes at each step; see CTO vs VP of Engineering.

How do you choose a structure?

Choose by the constraint you are trying to remove: slow delivery, unclear ownership, duplicated work or a skills gap. A short process works better than a model borrowed from a famous company.

1. Draw the current flow. Pick three recent features and note every team and hand-off each one touched.
2. Name the main constraint. Is it waiting on another team, duplicated tooling, no owner for a customer problem or overloaded teams?
3. Pick the smallest change that removes it. Moving one person or redrawing one boundary beats a full reorganisation.
4. Check cognitive load. Ask each team whether it can explain and operate everything it owns. If not, shrink the remit before adding people.
5. Decide the interaction modes. Between each pair of teams, agree whether they collaborate, consume a service or facilitate.
6. Write down who owns what. Ownership of services, on-call and customer issues should have a named team.
7. Set a review date. Structures are hypotheses; review them after a quarter.

For the AI-specific question of where machine-learning engineers sit, see managing AI teams.

How do you know whether the structure is working?

Look at delivery flow and coordination, not at the org chart. DORA suggests tracking, for example, the percentage of deployments that require coordination with other services, though it gives no benchmark values. Pair that with the five DORA delivery metrics and a short team survey about clarity of ownership and workload. Our engineering metrics for CTOs guide shows which measures to show which audience.

If lead time rises and cross-team coordination increases after a reorganisation, the structure is probably adding friction. Give it a quarter before judging, communicate clearly while it settles, and be ready to adjust. Reorganisations hit morale, and engineers want to know why, what changes for them and what stays the same.

What mistakes do CTOs make with team structure?

Four mistakes recur. Copying a company's published model without its context, since the conditions that made it work may not apply to you. Reorganising too often, which resets trust each time. Creating a platform team before there are repeated needs, so it builds for imagined users. And forgetting that structure is only half of the problem: interfaces, ownership and communication must change as well.

Frequently asked questions

What is the best engineering team structure for a startup?

Usually one or two cross-functional teams that can ship end to end, with the CTO hands-on. Bessemer Venture Partners advises a hands-on leader up to about 10 engineers and at least one manager beyond that. Add platform or specialist teams only when repeated work or risk justifies them.

What is Conway's law?

Conway's law states that any organisation that designs a system will produce a design whose structure copies the organisation's communication structure. Melvin Conway published it in Datamation in 1968. In practice it means team boundaries shape system boundaries, so changing one without the other rarely works.

What are the four team types in Team Topologies?

Stream-aligned teams, aligned to a flow of work from a segment of the business domain; enabling teams, which help others overcome obstacles; complicated subsystem teams, for areas needing deep specialist expertise; and platform teams, which provide an internal product. Team Topologies also defines three interaction modes: collaboration, X-as-a-Service and facilitation.

When should a company create a platform team?

When several product teams repeat the same infrastructure or tooling work and that duplication is slowing them down. Team Topologies describes a platform team as providing a compelling internal product. Creating one before there is repeated demand risks building something nobody uses. This is our judgement rather than a sourced threshold.

How many engineers should be on a team?

No authoritative number exists in the sources we used. Team Topologies stresses cognitive load: teams can only handle so much complexity before breaking down. Size a team by whether it can understand and operate everything it owns, and treat any fixed headcount as a rule of thumb.

Sources

1. Key concepts: team types and interaction modes Team Topologies, 2026
2. Conway's Law Melvin Conway, 1968
3. Loosely coupled teams (capability) DORA, 2026
4. DORA research programme and report archive DORA (Google Cloud), 2026
5. Scaling your engineering team from one to 50 and beyond Bessemer Venture Partners (Atlas), 2026

How we source and check figures: Methodology.