← All work
File 05 · Head of Engineering & Platform · Scaling storyMatt’s own history · an inside role, not a client engagement

The team tripled. The complexity didn’t.

One of the leading platforms in its category needed an engineering organization built for the company it was becoming. So I went after the thing tying every new customer to more engineering effort.

3×

Engineering team growth across the tenure

Billions

Transactions processed per day

2

People on the core application team when Matt arrived

GrowthLoop is one of the leading platforms in its category. It moves customer data from cloud data warehouses out to an ever-growing list of marketing destinations. I joined in April 2021 as a part-time contract advisor, and engineering was small and fast, which is how the company had won its position. The core application was effectively a two-person team. Integrations were another two people. CI/CD was only starting to mature, and knowledge of the platform lived in a handful of heads.

GrowthLoop had optimized for speed, and it worked. The next stage of growth needed something else. My initial mandate was to get the platform ready for it: rewrites, major upgrades, the architectural problems, and an honest read on what would have to change for the company to scale. Within eight months the contract role became Head of Platform, then Head of Engineering & Platform. The scope came from being useful everywhere.

Standing
A leader in its category
Industry
MarTech · marketing automation on the cloud data warehouse
Tenure
Apr 2021 to Jul 2024 · part-time contractor to Head of Engineering & Platform
Scale
Company grew to eight figures across the tenure
Philosophy
First-principles fixes before more infrastructure
What they thought

“Scaling means hiring. More customers bring more destinations, more integration variants, more engineers, more complexity, and slower delivery.”

What we found

“The architecture had wired growth to engineering effort. Rebuild it and the wire comes out: the team grew 3×, transactions grew to billions a day, and infrastructure costs stayed low.”

The default plan at that stage is to hire your way through it. And the architecture guaranteed hiring would never keep up, because every new customer added work in the same places:

  • Every new integration was a bespoke build. More customers meant more destinations, more integration variants, more maintenance, more edge cases.
  • Systems had grown through copy-and-paste patterns, so each addition made the next one harder.
  • Knowledge lived in individual engineers. Lose one and you lost the only map of a subsystem, and if they’d walked, that subsystem was screwed.

Follow that curve and engineering effort grows linearly with the business, forever. That’s a massive tax on winning. The problem wasn’t the team’s speed. It was the relationship between growth and effort.

  1. 01

    Rewrite the scaling model, starting with integrations

    We rebuilt the integration system around a plugin-style architecture with standardized extension points, so a new destination or capability plugged into machinery that already existed. The whole point was to cut the wire between customer growth and engineering effort. From outside, adding a destination started to look like magic.

  2. 02

    First principles before infrastructure

    The same philosophy ran through the platform: before you buy more infrastructure to compensate for something being expensive, find out why it’s expensive and take the reason away. The industry default is to throw hardware at the bill, and mostly that’s nonsense. It’s how the platform got to billions of transactions a day while infrastructure costs stayed deliberately low.

  3. 03

    Make engineering measurable

    Velocity measurement, more automated testing, stronger frameworks and logging, and less dependence on knowledge held by single developers. The organization stopped being a set of individuals who each knew a piece and became something you could look under the hood of.

  4. 04

    Create room to discover

    Quarterly hackathons let engineers step outside the roadmap. Looking back, some of those experiments were wild for the time: natural-language-to-SQL, early AI-assisted code generation, new ways to visually orchestrate customer journeys. Anthony Rotio, then Head of Data and now Co-CEO, was among the earliest people inside the company pushing on what generative AI could make possible, and engineering’s job was to be an organization that could turn that ambition into working product. The question was “what friction can this eliminate that we assumed was unavoidable?”

20212024
IntegrationsBespoke build per destination, two peoplePlugin architecture with standard extension points
ScaleA fast startup platformBillions of transactions per day
Engineering teamSmall, knowledge held by a few3× the size, with velocity measured
KnowledgeHeld by individualsHeld in frameworks, tests, and logging

The culture work was part of the performance work. Sustainable velocity came from asking engineers what was in their way, giving them what they needed, and making the team a place where it felt safe to experiment and to challenge an assumption. At one point the CEO described me as a litmus test for what was good about GrowthLoop’s culture. Several of the hackathon experiments later showed up in the product’s direction around AI-assisted audience creation, activation, and journey orchestration.

On the record

GrowthLoop and the roles are Matt’s own history, public on his profile. The scale figures are from inside the tenure. Before-and-after timings for the integration rewrite weren’t logged to this page’s standard, so the architectural claim stands without them rather than with numbers that aren’t real.

Some of the technologies the team experimented with have since become commonplace, and that’s almost beside the point. What lasted was an engineering organization that could absorb change (new customers, new integrations, new technologies, new ideas) without its complexity multiplying along with it. The default answer to growth is more headcount, which just runs the old coupling on steroids. Change the relationship between growth and effort, fix the architecture before adding headcount, and the same team takes you much further. The culture and the performance came out of the same work.

What’s growing faster in your company: revenue, or the effort it takes to support it?

The Next Version finds where the money is actually stuck (starting with whether your numbers are even real) and names each move, what it’s worth, and who runs it. You keep the roadmap either way.