The team tripled. The complexity didn’t.
A marketing-automation platform needed to go from a small, fragmented engineering team to an organization that could support a rapidly growing SaaS product. The lever wasn’t headcount. It was changing the relationship between growth and 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 a marketing-automation platform: it moves customer data between cloud data warehouses and an expanding ecosystem of marketing destinations. In April 2021, when Matt joined as a part-time contract advisor, engineering was small and moving fast. The core application was effectively a two-person team. Integrations were another two-person team. CI/CD was only beginning to mature, turnover had been high, knowledge of the platform was fragmented, and no one person understood the entire system.
Like many startups, GrowthLoop had optimized for speed, and it worked, until the shortcuts started making the next stage of growth harder. The initial mandate was simply to help fix things: rewrites, major upgrades, 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 wasn’t handed over with an org chart. It was earned by being useful everywhere.
- Industry
- MarTech · marketing automation on the cloud data warehouse
- Tenure
- Apr 2021 – 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
“Scaling means hiring. More customers bring more destinations, more integration variants, more engineers, more complexity, slower delivery.”
“Growth was coupled to engineering effort by the architecture. Rebuild the architecture and the coupling breaks: 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. But the architecture guaranteed that hiring would never keep up:
- Every new integration was a bespoke build. More customers meant more destinations, more integration variants, more maintenance, more edge cases.
- Systems had evolved through copy-and-paste patterns. Each addition made the next one harder.
- Knowledge lived in individual engineers. Losing one meant losing the only map of a subsystem.
Follow that curve and engineering effort scales linearly with growth, forever. The problem wasn’t the team’s speed. It was the relationship between growth and effort.
- 01
Rewrite the scaling model, starting with integrations
The integration system was rebuilt around a plugin-style architecture with standardized extension points. New destinations and capabilities could be added without duplicating the underlying machinery. The objective was never cleaner code for its own sake. It was to decouple customer growth from engineering effort.
- 02
First principles before infrastructure
The same philosophy ran through the platform: eliminate the reason something is expensive before buying more infrastructure to compensate for it. That’s how the platform reached billions of transactions a day while infrastructure costs stayed deliberately low.
- 03
Make engineering measurable
Velocity measurement, expanded 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.
- 04
Create room to discover
Quarterly hackathons let engineers step outside the roadmap. The experiments look prescient now: natural-language-to-SQL, early AI-assisted code generation, new approaches to visually orchestrating customer journeys. Anthony Rotio, then Head of Data and now Co-CEO, was among the earliest inside the company pushing on what generative AI could make possible; engineering’s job was to be an organization capable of turning that ambition into working product. The question was never “how do we add AI?” It was “what friction can this eliminate that we assumed was unavoidable?”
| 2021 | 2024 | |
|---|---|---|
| Integrations | Bespoke build per destination, two people | Plugin architecture with standard extension points |
| Scale | A fast, fragile startup platform | Billions of transactions per day |
| Engineering team | Small, fragmented, high turnover | 3× the size, with velocity measured |
| Knowledge | Held by individuals | Held in frameworks, tests, and logging |
The culture work wasn’t separate from the performance work. Sustainable velocity didn’t come from pushing people harder; it came from asking engineers what was in their way, giving them what they needed, and making the team a place where experimenting and challenging assumptions felt safe. At one point the CEO described Matt as a litmus test for what was good about GrowthLoop’s culture. Several of the hackathon experiments later became visible in the product’s direction around AI-assisted audience creation, activation, and journey orchestration.
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. The lasting achievement was an engineering organization that could absorb change (new customers, new integrations, new technologies, new ideas) without multiplying complexity along with it. Great engineering organizations don’t choose between performance and culture, and they don’t scale headcount to compensate for architecture. Change the relationship between growth and effort, and the same team takes you much further.
What’s growing faster in your company: revenue, or the effort it takes to support it?
An X-Ray 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 map either way.