Rebuilding Engineering Capability at Series B Scale

Rapid growth breaks things that were working fine at the previous scale. For a B2B SaaS company that raised a $12M Series B and grew from fifteen to fifty-two people in eighteen months, what broke was the engineering organisation. Features were taking three times longer than they used to. The VP of Engineering had quit. Investors were watching delivery velocity as a proxy for Series C readiness. Nematix stepped in as interim CTO.

The outcome over nine months: delivery velocity increased 2.4 times, deployment failure rate fell from twenty-eight percent to four percent, and a permanent VP of Engineering was hired and fully onboarded with a functioning team underneath them.

The Situation

The company built workflow automation software for professional services firms. Their product was genuinely useful — net revenue retention was 118%, and their existing customers were expanding aggressively. The problem was shipping new features for the sales pipeline: the product roadmap was increasingly a source of commercial risk rather than competitive advantage.

At fifteen people, the engineering team had been tight, fast, and self-organising. Everyone knew the codebase. Reviews happened informally. Decisions were made in conversation. At fifty-two people, those patterns had become liabilities. Nobody had a complete picture of the system. Changes in one area of the product broke things in another area that nobody had mapped. The informal processes that worked in a small team had simply not scaled.

When the VP of Engineering resigned — citing misalignment on direction — the founders were left managing engineering directly alongside everything else. They needed senior technical leadership immediately, and they needed to hire a permanent VP without creating a gap of six to twelve months in leadership while the search ran.

The Challenge

The diagnostic Nematix conducted in the first four weeks surfaced a set of compounding problems:

Architecture: The product had been built as a monolith. Four hundred thousand lines of code with no module boundaries, no domain separation, and minimal test coverage (11%). Changes to the billing module broke the reporting module. Changes to the API layer affected the embedded form renderer. Nobody had mapped the dependencies.

Process: There was no code review requirement — engineers merged their own work. There was no CI pipeline with automated tests — tests were run manually before release, inconsistently, by whoever happened to be available. Deployments happened on Fridays, frequently broke production, and consumed engineer weekends.

Structure: Twenty-two engineers reported to the two founders through informal channels. There were no team leads, no squad ownership of product areas, and no clear accountability for any part of the system. When something broke, it was unclear whose responsibility it was to fix it.

Culture: There was anxiety beneath the surface. Engineers were being asked to move faster on a codebase they didn’t trust, with no process for making changes safely. Several had started looking for other roles.

Our Approach

The engagement was structured in three phases across nine months.

Months 1–2: Diagnostic and stabilisation

Before restructuring anything, Nematix conducted a full technical assessment: codebase analysis, one-on-one interviews with every engineer, a review of the deployment history and incident log, and a mapping of the product’s technical architecture.

The output was a priority-ranked list of interventions, separated into immediate stabilisation actions (things that would stop the bleeding within weeks) and structural changes (things that required planning and change management).

Immediate actions: mandatory code review for all merges, CI pipeline with a test gate (blocking merges when tests failed), no Friday deployments, and a rotating on-call rotation so incidents stopped being everybody’s problem and nobody’s responsibility.

Months 3–5: Restructure into product squads

The twenty-two engineers were reorganised into three squads: Growth (acquisition and onboarding flows), Core (the primary workflow product), and Platform (infrastructure, integrations, and internal tooling). Each squad had a designated tech lead — promoted from within, based on capability and interest.

Each squad owned a defined area of the codebase. Ownership meant accountability: the Growth squad was responsible for incidents in the growth features, the Core squad for the core product. Cross-squad changes required the receiving squad’s review.

Architecture Decision Records (ADRs) were introduced: any significant architectural choice was documented before implementation, reviewed by the relevant tech leads, and stored in the codebase alongside the code it documented.

Months 6–9: Hire and hand off

With the structural changes in place, the company was in a position to hire a VP of Engineering into an organisation that was functioning rather than one that was on fire. Nematix supported the search: defining the role based on what the organisation actually needed at this stage, reviewing candidates, and conducting technical interviews.

The VP joined in month seven. The handover ran over two months — the VP and Nematix’s interim CTO worked in parallel, with a structured knowledge transfer covering architecture, team dynamics, open decisions, and the roadmap for the next six months. By month nine, the handover was complete.

Outcome

The VP of Engineering hired in month seven remained in role through the company’s Series C process. The engineering organisation — restructured, with clear ownership and functioning processes — was presented in investor due diligence as a strength rather than a risk.

Key Takeaways

Stabilise before restructuring. The instinct when an engineering organisation is struggling is to reorganise. The right first move is to stop the immediate bleeding: bad deployment practices, unclear on-call responsibility, and unreviewed code. Fixing those takes weeks, not months, and creates the stability that makes restructuring possible.

Promote tech leads from within. External tech leads take time to build context and trust. The engineers who were given squad lead roles had both — and the responsibility changed their relationship to the codebase and to their teammates in ways that an external hire couldn’t replicate quickly.

Hire into a functioning org. A VP Engineering joining a chaotic team inherits the chaos. A VP Engineering joining a team that has structure, process, and clear ownership can add strategic direction immediately. The nine months of interim leadership were an investment in the permanent hire’s ability to succeed.

This engagement draws on our Strategy & Transformation and Expertise as a Service capabilities. Talk to us if your engineering organisation is struggling to scale.