Product teams in B2B SaaS need to stay close to customer problems, with a small platform function supporting the shared technical work underneath them. As the organization grows, day-to-day delivery usually moves to a VP of Engineering so the CTO can stay focused on architecture and longer-term technical direction.
The pressure often shows up during enterprise deals. A customer may ask for SSO or data residency while product teams are already committed to the roadmap. If ownership is unclear, the request gets picked up wherever capacity appears, priorities move around, and the CTO is pulled back into delivery.
The structure needs to change when the number of teams outgrows the conversations one leader can hold, which makes a better trigger than a funding round or an ARR figure. A company selling into regulated industries tends to reach each stage earlier than a self-serve product.
In the earliest stage the company has one team where everyone ships everything, and the CTO runs delivery directly. A senior engineer usually looks after infrastructure part-time alongside feature work.
The next stage starts when that single team splits into several product teams, each with a tech lead. The engineering management layer starts to take shape, and a large enterprise deal often brings a SOC 2 request along with the need for clear security ownership. This is where structural problems start to show up: a founding CTO who still reviews every pull request becomes a release bottleneck, while tech leads never get enough room to make decisions on their own.
Once managers start reporting to managers, a VP of Engineering often becomes useful for owning delivery and management structure. Product teams get grouped into areas under directors, and a platform team forms to own the shared infrastructure those teams keep rebuilding.
Larger organizations split further, with several product groups and a platform function broken into sub-teams. SRE and security become separate functions, security sometimes under a CISO, and the CTO's job narrows to architecture and technical strategy.
After a VP of Engineering starts, the CTO's staff meeting gets smaller. The core becomes the VP and the security lead, with a principal engineer or architect joining for design reviews, and the Head of Platform stays on the CTO's side only if platform work is mostly architecture. Engineering managers who used to bring sprint problems to the CTO now take them to the VP, and that change is often harder for the CTO to accept than for the managers.
The division gets tested the first time a large customer asks for a feature by the end of the quarter. The CTO decides whether it fits the current architecture or needs a new service, and the VP decides which team drops what to build it and gives the account team a real date. If both of them end up on the call negotiating that date with the customer, the split hasn't landed yet.
Performance reviews and promotions often become a breaking point. A CTO who overrules the VP on a single staff engineer's promotion teaches every manager that the real decision sits one level up, and they start routing around the VP.
Some B2B SaaS companies skip the separate VP and give one person a combined CTO or CPTO title. It holds while that person enjoys management and still knows every engineer by name. Later, architecture is what slips. A customer escalation has a renewal date and an account executive attached to it, a database migration has neither, and so the migration keeps moving to next quarter.
Industry guidance varies widely, with some sources recommending a VP of Engineering at around 12 to 35 engineers and others waiting until 40 or more. Headcount alone won't settle the question.
Four signals tend to show up together:
When several of these appear together, the company is already feeling the cost of delaying the hire.
Product teams should map to something a customer would recognize, such as a billing workflow or a product module, and each team should own its slice from database to UI. Matthew Skelton and Manuel Pais call these stream-aligned teams in Team Topologies, and they treat them as the default: every other team type exists to take load off them.
The alternative is component teams (a frontend team and a backend team, say), which feels tidy on an org chart and slows everything down in practice. A single customer request for a new approval step in a billing workflow ends up as three tickets in three backlogs, and the customer waits for the slowest one. Mel Conway made the underlying point in 1968: a system's structure ends up mirroring the communication structure of the organization that built it. A company organized by layer ends up with a codebase where adding one feature means negotiating with every layer's owner.
B2B SaaS often brings enterprise requirements that cut across several product areas, including SSO and SCIM provisioning, granular permissions, audit logs, data residency and admin consoles. Spreading that work across every product team means each one rebuilds permissions slightly differently. Once enterprise deals make up a large share of the pipeline, a dedicated enterprise or identity team can own those capabilities as a shared product, with a roadmap tied to the deals sales is working.
Skelton and Pais define a team as a stable group of five to nine people, and debates over the exact number rarely change outcomes. Scope per team deserves more attention, since a team that owns three unrelated modules will quietly let two of them rot.
A platform team earns its place when product teams keep solving the same infrastructure problems separately. The usual tell is four different ways to deploy, alongside a CI pipeline only one person understands. Before that point, a senior engineer with infrastructure as part of their job is enough.
Google's 2024 DORA research gives a useful warning here. 89% of respondents said they used an internal developer platform, and organizations with a dedicated platform team saw a 6% productivity gain at the team level. The same research found an 8% drop in throughput among platform users compared with non-users. In a separate finding, DORA reported weaker results when teams were required to use the platform across the whole application lifecycle. Taken together, that suggests the gains depend on product teams picking the platform because it saves them time, and they shrink once adoption is forced.
A Head of Platform usually becomes necessary once several product teams depend on shared infrastructure that nobody owns full-time. That point can come earlier in a multi-tenant architecture with per-customer isolation, because tenancy decisions affect every product team. Reporting line depends on the CTO/VP split. If the platform is mainly about developer experience and delivery speed, it sits under the VP of Engineering. If it carries long-range architecture decisions like the move to a new data store or a cell-based deployment model, it often reports to the CTO.
Security in B2B SaaS usually arrives through the sales team. A prospect's procurement group sends a security questionnaire and asks for a SOC 2 Type II report, and the deal sits in legal until someone can answer both. At first that someone is a senior engineer or the Head of Platform filling in spreadsheets between sprints. A dedicated security lead reporting to the CTO follows once questionnaires arrive every week, and later a CISO, who may report to the CEO or CFO instead. Some companies keep security outside the VP of Engineering's line to separate release pressure from security oversight.
Reliability often starts inside the platform team and splits out once contracts begin carrying uptime SLAs with service credits, since an outage now shows up as a discount on the customer's invoice. An SRE group can set on-call standards and run incident reviews while product engineers keep the pager for services they wrote. Take that pager away and SRE ends up debugging billing code at 3 a.m. that nobody on the team has ever read.
Data engineering is easy to misplace. A typical "data team" answers to finance, who want monthly revenue dashboards, and to product managers, who want a usage report inside the app that customers can export, and the two groups rarely agree on what comes first. The customer-facing report belongs to the product team that owns that workflow. Internal analytics can then sit with a Head of Data reporting to the CTO or, in some companies, the CFO.
For AI features, a small applied AI group can work as what Team Topologies calls a complicated-subsystem team. It owns model evaluation and inference cost controls, so a product team adding AI-drafted invoice summaries doesn't have to build its own evaluation setup or find out about the token bill at month end. If the group ends up building every AI feature itself, product teams queue behind it and the features ship without input from the people who know each workflow.
Structural problems tend to surface as delivery problems, and a CTO who reads them as individual performance issues will reorganize too late.
Frequent reorgs carry their own cost, because teams have to rebuild working relationships before the new structure has had time to settle. Moving one or two team boundaries at a time keeps that cost down.
It can, under a CPTO title, and it works best in developer-tool and infrastructure SaaS where the buyer is technical. In SaaS sold to business users (finance or HR teams, for example), a separate CPO who sits in customer calls every week is better placed to own the roadmap. The combined role also makes the CTO's span harder to manage once engineering grows into several product groups.
Only when the two segments use meaningfully different products. If enterprise customers use the same core product with extra controls, a segment split duplicates the codebase in all but name. The enterprise or identity team described above usually covers the gap without a full segment split.
Each team should sit within a few hours of overlapping working time. A team split across San Francisco and Bangalore can end up operating as two teams sharing a name, with handoffs at the end of every day. Keeping a whole team, or a whole product area, in one location can remove that daily handoff.
One workable split gives headcount and team-level spend to the VP of Engineering, since hiring plans are part of delivery, and keeps cloud architecture and major vendor contracts with the CTO because they commit the company for years.
