Engineering Organization Design Recommendation

Vantage Systems — Scaling from 18 to 52 Engineers Over 18 Months

Date: 2026-05-30 · Prepared by: Resolvix · Status: Sample Deliverable
Deliverable type: Operations & Process Design — Org Design Recommendation (~$825)
Industry: B2B SaaS / Enterprise Software

About this sample. This is one example of what a successful Resolvix deliverable looks like at this scope and type — not a template that every engagement follows. Your expert brings their own expertise and judgment to the work: the structure, the emphasis, which angles they dig into, and how they organize their findings will all vary based on your industry, your specific question, and where the research leads. What stays consistent across every engagement is the standard: analysis grounded in evidence, prioritized recommendations, concrete action steps, and a phased implementation plan. All company names, figures, and scenarios in this sample are illustrative.

Executive Summary

Vantage Systems is a B2B SaaS company providing workflow automation software to mid-market professional services firms (primarily accounting and consulting). ARR has grown from $4.2M to $18.7M in 24 months, driven by two new enterprise contracts and a successful move upmarket. The engineering organization currently has 18 engineers organized informally under a single VP Engineering and two senior engineers acting as de facto team leads. The company plans to hire 34 additional engineers over the next 18 months, bringing total engineering headcount to 52.

This recommendation addresses the central org design question: which team structure best positions Vantage to execute product delivery reliably at 52 engineers while preserving engineering quality and avoiding the coordination overhead that kills mid-stage SaaS companies?

Three structures were evaluated:
1. Functional (discipline-based) — teams organized by engineering function (frontend, backend, data, infra)
2. Product-aligned (squad model) — cross-functional teams organized around product areas or customer segments
3. Platform + product-aligned hybrid — a dedicated platform engineering team supporting independent product squads

Recommendation: Product-aligned squads with a Platform Engineering team (Option 3 — hybrid model), phased in as hiring milestones are reached. This is the structure that best balances Vantage's immediate delivery needs, its architectural debt obligations, and the coordination risks inherent in rapid headcount growth.

Company Context

Current engineering state:
- 18 engineers total: 1 VP Engineering, 2 senior engineers (acting leads), 8 backend engineers, 4 frontend engineers, 2 DevOps/infra engineers, 1 data engineer
- Architecture: monolithic Rails application with a growing React frontend; Postgres database; AWS infrastructure; Segment for analytics
- Deployment: weekly release cycle; no feature flags; a single staging environment shared across all teams
- Current delivery pace: approximately 22 story points per week across all teams; no formal team structure means work is assigned ad hoc by the VP Engineering
- Primary technical debt items: authentication/authorization service needs extraction from monolith; observability is minimal (no distributed tracing); staging environment has become a bottleneck

Product areas (as of today):
- Core workflow engine — the primary product surface; automation rules, triggers, workflow templates
- Integrations — API connectors to 37 third-party platforms (QuickBooks, Salesforce, Microsoft 365, etc.)
- Reporting & Analytics — client-facing dashboards and custom report builder
- Enterprise administration — SSO, role-based access control, audit logging, user provisioning

Hiring plan:
- Months 1–6: +12 engineers (priority: backend and platform)
- Months 7–12: +12 engineers (priority: product squads and data)
- Months 13–18: +10 engineers (priority: integrations and frontend)
- Total at Month 18: 52 engineers

Key constraints identified in CTO/VP Engineering interviews:
- Cannot afford a 6-month "org change pause" on delivery; hiring must happen while product work continues at pace
- Two enterprise clients have committed to a product roadmap with deliverables in Month 9 (SSO/SCIM provisioning) and Month 14 (advanced reporting)
- The monolith is a constraint: any team structure must account for the fact that all engineers are currently working in a single codebase, and module boundaries are poorly defined
- Engineering leadership capacity is limited: VP Engineering is the only dedicated EM; the two senior engineers are individual contributors who have stepped into coordination roles and do not want to become full-time managers

Option 1: Functional Organization

Structure

Teams are organized by engineering discipline. At 52 engineers, this would produce:

How it works

Each functional team receives work from product management via a shared backlog. Cross-functional coordination (e.g., frontend and backend for a new feature) is managed through project-level dependencies tracked in Jira. Engineering managers own discipline quality, career development, and craft standards within their function.

Pros

• Deep functional expertise. Engineers work alongside peers in their discipline; knowledge transfer, code review, and mentorship are concentrated.
• Simpler at current scale. At 18 engineers today, a functional structure is essentially what Vantage already has (informally). The transition to formalized functional teams is the least disruptive near-term option.
• Clear career paths by discipline. Frontend IC → Senior Frontend → Staff Frontend is a legible progression.
• Platform work is explicit. Infrastructure and DevOps are a named team with dedicated headcount, rather than being squeezed by feature work.

Cons

• Cross-functional coordination tax becomes severe at scale. Every feature that touches frontend, backend, and data requires synchronization across three separate teams with separate managers and separate roadmap priorities. At 52 engineers working on four product areas, this produces a combinatorial coordination problem. Spotify, Atlassian, and numerous other SaaS companies have documented the breakdown of functional org structures at this scale.
• Features ship in installments, not wholes. A functional org optimizes for component delivery, not user-facing feature delivery. Product management must decompose every feature by function and track completion across multiple teams — a significant PM overhead.
• No team owns a product outcome. If SSO/SCIM is delayed, which team is accountable? Backend shipped their piece; frontend is waiting for a dependency; infrastructure didn't prioritize the audit logging requirement. Accountability diffusion is endemic to functional structures.
• The monolith problem gets worse. In a functional org, backend engineers from the core workflow team and the integrations domain will constantly be in conflict over the shared codebase. Module boundaries are even harder to draw when the org is not organized around them.

Headcount implications

Requires 4 full-time Engineering Managers hired or promoted (one per functional team). At Vantage's current pace of developing internal talent, 2–3 of these would need to be external hires.

Assessment: Not recommended. The functional structure is appropriate for Vantage today at 18 engineers. It becomes increasingly dysfunctional as headcount grows toward 40+. Selecting it now means rebuilding the org in 12–18 months under delivery pressure.

Option 2: Product-Aligned Squads (Full Squad Model)

Structure

Teams are organized around product areas, each as a cross-functional "squad" owning a product domain end-to-end. At 52 engineers:

How it works

Each squad owns its domain from discovery through delivery. A Squad Lead (Engineering Manager) owns the team; a Product Manager is assigned per squad. Squads set their own sprint cadence; coordination between squads is handled through inter-squad dependency agreements and a weekly cross-squad sync. Infrastructure work is handled by embedded SRE/DevOps engineers distributed across squads, with no dedicated platform team.

Pros

• End-to-end ownership. Each squad owns user-facing outcomes, not components. The Enterprise squad is accountable for SSO/SCIM shipping by Month 9 — no diffusion of accountability.
• Speed. Squads can make architectural decisions within their domain without cross-team negotiation. Feature delivery timelines are more predictable because there are fewer external dependencies.
• Strong alignment between engineering and product. Squad leads work closely with their assigned PM; roadmap decisions are made at the squad level within overall company priorities.
• Scales naturally. Adding engineers means adding squads or growing existing squads — no structural redesign required until squad size becomes unwieldy (typically >12 engineers).

Cons

• Infrastructure is the critical weak point. Distributing DevOps/infra engineers across squads with no dedicated platform team means: (a) no one owns the internal developer platform, (b) infrastructure improvements compete with feature work in every squad's backlog, and (c) standards for deployment, observability, and security drift across squads. At Vantage's current infrastructure debt level (minimal observability, single staging environment), this is a high-risk configuration.
• Shared codebase creates coordination friction. With a Rails monolith and no defined module ownership, squads will regularly conflict over shared code. The Core Workflow and Integrations squads will be stepping on each other constantly in a monolith until module boundaries are enforced architecturally.
• 4 Squad Leads required immediately. At the point of standing up squads, Vantage needs 4 engineering managers. It currently has 0. This is a significant hiring and onboarding risk — engineering managers are slow to hire and slower to become effective.
• Cross-squad features are more complex to manage. Features that span domains (e.g., a new automation trigger type that requires workflow engine changes AND a new integration connector AND a new reporting metric) require cross-squad coordination. In a pure squad model without strong inter-squad agreements, these slip.

Assessment: Better than functional, but the infrastructure gap and the monolith problem make a pure squad model premature for Vantage at this moment.

Option 3: Platform + Product-Aligned Hybrid (Recommended)

Structure

A dedicated Platform Engineering team handles the internal developer platform, infrastructure, and the monolith-to-modular transition. Product squads are organized around product areas but are smaller and more focused because platform concerns are extracted. At 52 engineers:

How it works

Platform Engineering operates as an internal service team. Its customers are the four product squads. It owns: the CI/CD pipeline, the staging environment (and the roadmap to multiple per-squad staging environments), feature flag infrastructure, observability tooling, the security and compliance layer, and the architectural work of extracting modules from the monolith. Platform publishes a roadmap like any product team and takes "feature requests" from squads when they need a platform capability (e.g., "we need per-tenant data isolation for the Enterprise squad's SOC 2 requirements").

Product squads work within the platform that Platform Engineering provides. They do not manage their own infrastructure; they consume platform capabilities as a service. This means squad engineers focus almost entirely on product logic rather than operational concerns.

The key design principles:
- Platform Engineering is a service team, not a gatekeeper. Squads self-deploy within platform guardrails; they do not wait for Platform to deploy for them.
- Platform has a published SLA: staging environment availability ≥99.5%; CI pipeline median build time ≤8 minutes; new squad onboarding ≤2 weeks.
- Squad leads have technical authority within their domain; Platform Engineering has technical authority over cross-cutting concerns (security, observability standards, infrastructure cost).

Pros

• Solves the infrastructure gap directly. Platform Engineering owns the problems that would otherwise fall between the cracks in a pure squad model. The staging environment bottleneck, observability gap, and deployment pipeline issues all have a clear owner.
• Enables the monolith transition without blocking product squads. The Platform team leads the modularization work (extracting auth, integrations gateway, etc.) as a deliberate architectural program — not as an informal initiative that competes with feature work in every squad's backlog.
• Product squads ship faster because platform concerns are abstracted. A squad engineer at Vantage should not be debugging Terraform scripts or managing Datadog dashboards. Platform Engineering creates the floor; squads build on it.
• Scales predictably. As Vantage grows beyond 52 engineers, new product squads slot in without structural change. Platform Engineering grows proportionally (typically 15–20% of total engineering headcount is a sustainable ratio).
• Better developer experience retention. DX is a leading indicator of engineering retention. Squads that work on well-instrumented, well-tooled platforms have meaningfully higher retention than squads fighting fires at every deployment.

Cons

• Platform Engineering must be staffed with strong engineers, not residual. The most common failure mode of this structure is that platform engineering becomes a graveyard for engineers who "don't fit" on squads. If Platform is not treated as a high-status, high-quality team, it underinvests in the internal platform and squads lose confidence in it. Platform Engineering Lead must be a senior hire.
• Higher leadership headcount. 5 engineering managers (Platform EM + 4 Squad EMs) is the most of any option — and all 5 must be effective before the org is fully stood up. Hiring pipeline for EMs must begin immediately.
• Requires articulation of the platform-squad boundary. What belongs to Platform? What to squads? In a monolith, this is harder to define than in a microservices architecture. The Platform team must publish clear ownership maps and resist scope creep in both directions (squads building their own platform tooling; Platform absorbing product concerns).
• Slightly more complex to explain to candidates. "You'll be on the Reporting squad, consuming platform services" is a slightly more abstract pitch than "you're a backend engineer on the backend team." Not a serious concern, but worth noting for recruiting messaging.

Headcount implications

Requires 5 Engineering Managers: 1 Platform EM (senior hire; must understand developer platforms and infrastructure deeply) and 4 Squad EMs. Given Vantage's current roster, the two senior engineers who have been acting as informal leads are strong internal candidates for two Squad EM roles — pending genuine interest in the management track (this must not be assumed).

Option Comparison Summary

Recommended Org Chart at Full Scale (Month 18)

VP Engineering
│
├── Staff Engineer (x2, cross-cutting)
│
├── Platform Engineering (EM: Platform Lead)
│   ├── DevOps/Infrastructure Engineers (x3)
│   ├── Backend Platform Engineers (x3)
│   ├── Security/Compliance Engineer (x1)
│   └── DX/Tooling Engineer (x1) [full team: 10 including EM]
│
├── Core Workflow Squad (Squad EM)
│   ├── Backend Engineers (x5)
│   ├── Frontend Engineers (x2)
│   └── QA/Automation Engineer (x1) [full team: 9 including EM]
│
├── Integrations Squad (Squad EM)
│   ├── Backend Engineers (x4)
│   ├── Frontend Engineer (x1)
│   ├── Integration Specialist/Backend (x1)
│   └── QA Engineer (x1) [full team: 8 including EM]
│
├── Reporting & Analytics Squad (Squad EM)
│   ├── Backend Engineers (x3)
│   ├── Frontend Engineers (x2)
│   ├── Data Engineer (x1)
│   └── QA Engineer (x1) [full team: 8 including EM]
│
└── Enterprise Squad (Squad EM)
    ├── Backend Engineers (x4)
    ├── Security/Compliance Backend (x1)
    ├── Frontend Engineer (x1)
    └── QA Engineer (x1) [full team: 8 including EM]

Total: 52 engineers (including VP Eng, 2 Staff Eng, 5 EMs, and 43 ICs)

Phased Rollout

Current state (18 engineers) → Month 6 (~30 engineers)

Do not attempt to stand up 4 squads at 30 engineers. Too many teams at too small a size creates fragmentation without the capacity to execute independently.

Phase 1 action: Stand up Platform Engineering and 2 product squads.

• Hire Platform Engineering Lead (external; senior engineer-manager with infra + developer platform background). This is the single most important hire.
• Platform Engineering team: 5 engineers (Platform Lead + 4 — mix of existing DevOps engineers and 2 new hires). Priorities: staging environment fix, CI/CD pipeline overhaul, observability baseline (Datadog or similar), monolith module mapping.
• Stand up Core Workflow Squad (first squad; most senior engineers): Squad EM from one of the two existing senior engineers (if willing) or external hire. ~8 engineers.
• Remaining engineers form an Enterprise Squad (priority: Month 9 SSO/SCIM delivery commitment): ~7 engineers. Second senior engineer as Squad Lead (interim; can formalize as EM or hire EM externally if not interested in management).
• Integrations and Reporting squads form later (Months 7–12) as headcount permits dedicated squads with meaningful team size.

Month 6–12 (~30 to 42 engineers)

Phase 2: Stand up remaining product squads; Platform Engineering grows.

• Platform Engineering grows to 8 (add 3 engineers from Month 7–12 hiring cohort)
• Integrations Squad stands up: Squad EM hired or promoted; ~6–7 engineers
• Reporting & Analytics Squad stands up: Squad EM hired; ~6 engineers; prioritizes Month 14 advanced reporting commitment
• Enterprise Squad formalizes (EM hired if not yet in place)
• VP Engineering conducts first org-wide retrospective on structure: what's working, what isn't? Adjust before Phase 3.

Month 12–18 (~42 to 52 engineers)

Phase 3: Fill to full headcount; solidify structure.

• All squads at target headcount
• Platform Engineering at 10 (including EM)
• Squad EMs all in place; VP Engineering shifts from tactical to strategic
• Staff Engineers (2) operate cross-cutting: code quality, architectural standards, technical mentorship across squads
• Platform publishes official SLA document and quarterly roadmap
• Conduct external engineering org health assessment (recommended at Month 18 before hiring beyond 52)

Recommendations

Priority 1 — Hire the Platform Engineering Lead before any squad EMs
The Platform Engineering Lead is the structural keystone of this recommendation. Without this hire, the platform team underperforms, squads lose confidence, and the org drifts toward a dysfunctional squad model. This role requires: strong backend/infrastructure background, experience building internal developer platforms at a SaaS company, and genuine interest in an internal-service-team role. Target compensation: $185,000–$220,000 base + equity. Begin sourcing immediately.

Priority 2 — Have honest individual conversations with both senior engineers before announcing the org design
Both senior engineers are currently acting as informal leads. Announcing a squad model that assumes they will become EMs — without confirming their interest — is a retention and morale risk. Meet with each individually. If either is not interested in the EM track, plan for external Squad EM hires immediately and find a Staff Engineer path for them instead.

Priority 3 — Do not split engineers into 4 squads until headcount exceeds 36
A squad of 4 engineers is not a squad — it is a pair of pairs with an EM overhead. The phased rollout above holds to 2 product squads + Platform Engineering until the organization has the headcount to staff squads at 7+ engineers. Resist the temptation to name teams before you have the people to fill them.

Priority 4 — Define and document squad ownership boundaries before squads form
Before standing up any squad, publish a domain ownership map: which parts of the codebase, which API endpoints, which data models, and which user-facing surfaces belong to each squad. This is harder than it sounds in a monolith. The Platform Engineering Lead should lead this exercise in Month 1–2 of their tenure. Vague domain boundaries are the leading cause of squad conflict and coordination friction.

Priority 5 — Fix the staging environment bottleneck in Phase 1, not Phase 2
The shared staging environment is already a bottleneck at 18 engineers. At 30+ engineers across multiple squads, it becomes a delivery crisis. Platform Engineering's first deliverable should be a per-squad staging environment capability (or at minimum, a staging slot reservation system). This is achievable within 60–90 days with dedicated Platform Engineering focus.

Priority 6 — Add a Staff Engineer role before the org exceeds 36 engineers
At 36+ engineers across multiple squads, there is a well-documented risk of architectural fragmentation — squads make local technical decisions that are locally optimal but globally incoherent. Two Staff Engineers operating cross-cutting (no squad allegiance; reporting to VP Engineering) maintain architectural integrity, facilitate cross-squad technical decisions, and provide a senior IC career path that doesn't require going into management.

Priority 7 — Instrument delivery health metrics from day one of squad formation
Stand up a lightweight engineering metrics dashboard (DORA metrics are the industry standard: deployment frequency, lead time for change, change failure rate, mean time to restore) before squads form, not after. This gives squads a baseline to improve against and gives leadership visibility into delivery health without micromanagement.

Action Steps

Implementation Plan

Phase 1: Foundation (Months 1–6, 18 → ~30 engineers)

Objective: Stand up Platform Engineering and 2 product squads with clear ownership; deliver Month 9 SSO/SCIM commitment on track.

Milestones:
- Month 1: Platform Engineering Lead offer extended
- Month 2: Platform Engineering team of 5 formed; staging environment fix underway; domain ownership map drafted
- Month 3: Core Workflow Squad and Enterprise Squad formally constituted; Squad EMs in place
- Month 4: DORA metrics baseline established; per-squad staging environments in progress
- Month 6: Phase 1 retrospective held; staging environment issue resolved; SSO/SCIM on track for Month 9

Success criteria — Phase 1:
- Platform Engineering Lead hired by Month 2
- Zero delivery impact from org transition on Month 9 SSO/SCIM commitment
- DORA metrics baseline: deployment frequency ≥1/week per squad; lead time for change <5 days
- Domain ownership map published and agreed by all senior engineers

Phase 2: Squad Expansion (Months 7–12, ~30 → ~42 engineers)

Objective: Stand up Integrations and Reporting squads; Platform Engineering at operating scale; all Squad EMs in place.

Milestones:
- Month 7: Integrations Squad formed; Squad EM hired or promoted
- Month 8: Reporting & Analytics Squad formed; Squad EM hired
- Month 9: SSO/SCIM delivered (Enterprise Squad)
- Month 10: Platform Engineering at 8 engineers; per-squad staging environments live for all 4 squads
- Month 12: All 5 EMs in place and past 90-day mark; Staff Engineers (2) hired; Phase 2 retrospective held

Success criteria — Phase 2:
- All 4 product squads formed with ≥6 engineers each
- Month 14 advanced reporting commitment on track (Reporting & Analytics Squad)
- Platform SLA published: CI build time ≤8 min; staging availability ≥99.5%; squad onboarding ≤2 weeks
- Engineering retention rate: ≥90% (annual basis) — a sign the org structure is working for engineers, not against them

Phase 3: Optimization (Months 13–18, ~42 → 52 engineers)

Objective: Fill to full headcount; validate structure under full load; prepare for next growth phase.

Milestones:
- Month 14: Advanced reporting delivered (Reporting & Analytics Squad)
- Month 15: Platform Engineering at full headcount (10)
- Month 18: All squads at target headcount; external org health assessment conducted; recommendation for next growth phase (beyond 52) prepared

Success criteria — Phase 3:
- DORA metrics at Month 18: deployment frequency ≥3/week per squad; change failure rate <5%; MTTR <2 hours
- Month 14 reporting commitment delivered on time
- VP Engineering operating strategically (not tactically); tactical engineering management fully delegated to Squad EMs and Platform EM
- Board-level engineering reporting: monthly DORA scorecard available to CTO/CEO/board

Prepared by Resolvix. This sample represents the depth and specificity of analysis delivered at this scope. Actual engagement outputs reflect your specific data, systems, and context.