From Catch-All Team to Platform Org

Senior Engineering Manager, Application Platform·2026·22 months·25 people·4 min read

Grew a flat 9-person catch-all team into a 24-person, 4-team platform organization with 100% voluntary retention and 7 promotions.

Overview

Took over an undefined, catch-all engineering team at a Series C cybersecurity company and rebuilt it into the foundational platform layer.

Problem

The team had no clear ownership boundaries and was absorbing whatever work didn't fit elsewhere. As the company scaled, that ambiguity became a bottleneck: nobody could say definitively who owned core deployment, the ETL pipeline, or the sharded database infrastructure underneath every other product team.

Constraints

  • Hiring had to keep pace with 3x team growth without lowering the bar.
  • Two related systems, ephemeral infrastructure and the pentest runtime, sat under separate reporting lines (IPT and APT), forcing cross-team coordination on every meaningful change.
  • Growth had to happen without disrupting delivery on active platform work.
  • Any org redesign needed buy-in from leadership on both sides of the affected teams.

Approach

Partnered with product and company leadership to design 4 sub-teams around distinct business and technical priorities, rather than growing the original team as a single undifferentiated unit. Grew headcount through a mix of internal promotion and external hiring, developed 3 engineering managers along the way, and merged two structurally split teams into one to fix a specific ownership gap.

Key Decisions

Split the org into 4 sub-teams around business priorities instead of scaling one flat team

Reasoning:

A single 25-person team with no internal structure would have reproduced the same ownership ambiguity at a larger scale. Organizing around distinct priorities, core platform, data infrastructure, enterprise licensing, and integrations, gave each area a clear owner and made hiring plans traceable to specific business needs.

Alternatives considered:
  • Continue scaling as one flat team under a single manager.
  • Split by technology layer instead of business priority.

Merge APT-Core Attack and IPT-Ephemeral into a single team (CRPT)

Reasoning:

The ephemeral infrastructure layer and the runtime workloads it hosted were a single vertical system in practice, but split across two reporting lines. Nearly every change required cross-team coordination, and incidents had no unambiguous owner. Combining them under one mandate, from op start to op scraped, fixed both problems at once.

Alternatives considered:
  • Keep the teams separate and invest in a formal cross-team coordination process.
  • Add a dedicated liaison role between the two teams.

Fill 2 of 3 new engineering manager seats by promoting from within

Reasoning:

Promoting engineers who already understood the systems and the team preserved institutional knowledge and gave the broader team a visible growth path, at a lower onboarding risk than hiring every manager externally.

Alternatives considered:
  • Hire all new engineering managers externally.

Tech Stack

  • Ashby
  • BrightHire
  • CoderPad
  • Confluence
  • Jira
  • Rippling

Result & Impact

  • 9 to 25 people across 4 sub-teams
    Team size
  • 100% through 3x growth
    Voluntary retention
  • 7 across the team
    Promotions
  • 3 (1 external hire, 2 promoted from within)
    Engineering managers developed
  • 200+ across concurrent hiring pipelines
    Interviews conducted

The team's scope grew from an undefined catch-all to roughly 80% of the product's essential services, including core customer deployment, the full ETL pipeline, and the primary and customer-sharded database infrastructure every other product team depends on.

Learnings

  • Splitting a team along business priority lines, not technology layers, made ownership and accountability unambiguous.
  • Promoting from within is possible at pace, if career frameworks are defined before headcount grows rather than after.
  • Merging two systems that are coupled in practice should be treated as an org design decision, not just a technical one.

Starting Point

The team inherited in mid-2024 was 9 people with no defined charter, absorbing backend work that didn’t have a clear home elsewhere. That worked at a small scale. It stopped working once the company’s roadmap started depending on services this team happened to own, without anyone having designed it that way.

Designing Around Priorities, Not Headcount

Rather than growing the existing team as-is, the redesign started from the business priorities the company needed covered: core platform services, data infrastructure, enterprise licensing and access control, and external integrations. Four sub-teams took shape around those priorities, each with its own charter defining mission, ownership boundaries, and initiative scope.

Fixing a Split-Ownership Problem

One gap stood out during the redesign: the ephemeral infrastructure layer, which provisions cloud environments for each pentest, and the runtime workloads that ran inside them were a single system in practice but sat under two different teams and reporting lines. Every meaningful change required cross-team tickets, validation handoffs, and reconciling two competing backlogs. Merging the teams into one, with a mandate spanning the full op lifecycle, removed the coordination tax and gave the combined system a single owner for reliability.

Result

By the time the org reached its full 4-team structure, headcount had nearly tripled with no voluntary attrition, 7 people had been promoted, and 3 new engineering managers were running teams, 2 of them promoted from inside the org. The team that had once absorbed undefined work now owned the foundational platform layer.

All projects