Why 2019 Is The Year Of Growth Engineering In SaaS

Over the past few years, we've seen a new role emerging at within scaling startups - the growth engineer.

In short, we observe that Head, Director & VP of Growth titles are becoming more abundant, as are consultants around growth hacking but the "growth hacker" title is fading away.

But there's an urgent need for technical resources within growth teams. The explosion of SaaS tools (and with it, data silos) together creates a need for a cross-functional, operations role to support go-to-market teams.

These roles are filled by engineers that roll up to the CMO/COO (not CTO) as part of a growth team. Their job is to enable go-to-market teams through "joining the dots" between tools, teams & data, optimizing the business rules that drive growth.

In this post, we're going to share where growth engineers come from and why they're here to stay. But first, we need to set some context (albeit from the perspective of B2B SaaS).

Selling has changed since Predictable Revenue was published

In 2002, Aaron Ross's Predictable Revenue playbook from his time at Salesforce was published. It shared the repeatable process to operationalize sales, particularly sales development. For many in sales, this is the root of the playbooks they follow today.

It made sense then. But what does it mean now? What's changed?

Firstly, in the past five years, there’s been an explosion of technology companies — Scott Brinker’s team at ChiefMartec produce the dizzying Martech supergraphic each year. And this is just one industry (albeit, an industry we all buy from).

Second, cloud-hosted SaaS apps meet “consumerized” technology buyers via a freemium sales models. But with more abundant buyers and vendors come more tool purchases. And with that, more data disintegration.

Third, we're seeing an abundance of customer data. Not only do companies have more tools that can host lead & customer profiles, but there are more services than ever to enrich data, calculate intent, run predictions, warehouse data, and so on. Customer data is scattered everywhere.

By default, these tools don’t talk to each other. And most combinations don't arrive with a neat set of instructions to tie them all together. Siloed tools mean siloed data and siloed teams.

Here comes the problem with the Predictable Revenue playbook...

Business buyers are consumer buyers too - they’re used to an elevated experience outside of work. Ad tech and our B2C peers have been able to precisely profile and engage consumers for years.

In comparison, blind, cold (albeit targeted) outbound feels completely analog here - especially if every vendor is copying the same playbook. If you go to any conference discussing outbound sales techniques, (lack of) engagement comes up again and again. But the comparisons are made with other successful sales techniques (local maxima), not what's possible elsewhere.

But those in B2B who can “join the dots” about their leads & customers from their data can deliver a far better consumer-grade experience compared to cold targeted outbound. We've Spotted the trends, tactics & techniques from sitting deep in the data layer of scaling SaaS teams. Customer data integration enables powerful, precise messaging. And it is customer data integration that is a competitive advantage that’s hard to replicate.

But it appears that the people getting the most value from martech and customer data are not marketers any more.

Trend #1: The most effective users of martech are engineers

Customer data is cross-functional; not just specific to a particular team (sales, marketing, support) within an organization.

For example, as a lead is nurtured and converts to become a customer, you might need to:

  • Integrate payments (Stripe)
  • Integrate sales CRM (Salesforce)
  • Integrate email marketing (HubSpot)
  • Integrate ad audiences (Facebook).

These tools don’t all natively talk to each other, which takes point-and-click solutions out of the game — this is an engineering task, not marketing.

Casey Winter's recent post shared why he believes MarTech will die out, arguing it has only ever been a response to a lack of engineering resources. Martech is for engineers, not marketers.

In short, I hate martech, and think martech will decline as a category, and most martech businesses will not be very successful. [...] The marketing function in technology companies is usually a response to engineering constraints

Casey WintersGrowth Advisor at Greylock

For sales and demand gen teams, they have to work with what they’ve got to hit quota and pipeline goals. Month-to-month, quarter-to-quarter. Compared to those immediate goals, they lack the reward and responsibility to build tooling and enable long-term value-creating opportunities for themselves and the rest of the team (like joining up their data).

This is why scaling teams appear to build dedicated sales & marketing operations teams - "revenue operations" - to enable their lead & customer-facing teams with the tools & data they need.

The problem with traditional sales & marketing operations is they're constrained to:

  • Silos within an organization - customer data is cross-functional, yet modern revenue operations & enablement needs a complete picture of the customer (and buying) journey.
  • Silos within their martech's ecosystem - whatever your stack, the tool's native ecosystem & capabilities will always hold some constraints.
  • Silos within their skillsets - the capabilities of your data are limited to the non-engineering skillsets and the GUI capabilities of any tool.

In the past 4 years, we’ve seen dramatic growth in the number of marketing tools as sales & marketing (and "rev ops") buy solutions to each of their problems.

But what most people miss... at the same time, we’ve seen 10X growth in the number of data and growth engineers - people whose job it is to integrate & maintain systems of tools, teams & data.

It appears to be the engineers who are driving value from martech, not just through building their own but by using (and integrating) existing systems.

Trend #2: Growth is not marketing; Growth is operations.

They say marketers ruin everything. What’s happened is marketers have adopted “growth” and “growth hacking” and applied it to marketing.

At some point, someone has to write the copy. Someone has to create a campaign. Someone had to define the brand. This is marketing. This is not new.

But marketing holds many of the operational levers in an organization that drives growth. The principles of "growth hacking" and the scientific method of hypotheses, experiments, measurement have been around for at least 100 years.

  • In 1923, Claude C Hopkins published "Scientific Advertising" sharing how to optimise results through testing & measuring coupons and ad copy from direct response campaigns.
  • By 2000, cookie-based A/B testing on web birthed the "Conversion Rate Optimization" industry. Same process, different medium.
  • In 2010, Sean Ellis coined the term "Growth Hacking". Again, it's the same process being applied over more elements of the customer journey.

They might have focused on different areas, but applying the scientific method to marketing is not new. So what is new?

Is growth about "marketing", or is it about enabling marketing (and beyond marketing)?

Our observation is growth enables marketing, product, sales and other teams across the organization. It sits at an operational role, supporting multiple teams across the company, and rolls up to Operations or the CEO.

Brian Halligan, CEO, and JD Sherman, COO, at HubSpot did a really good job at giving us basically a startup within a larger company. They made sure we had the space, headroom, and air cover to explore and screw up and try a bunch of new things that were so different from HubSpot’s core playbook.

Brian BalfourFormer VP Growth at HubSpot

This is not about managing marketing activities that have to happen every day. Growth is far more concerned about moving levers behind the sales & marketing activity instead of the functional practices of campaigns, brand, and so on.

"Growth hacking" has grown up. At Hull, we come across plenty of Head, Director, and VP of Growth. But just 10% of all time demo requests to Hull with "growth" in their title are "growth hackers" (and that appears to be trending down).

The real "hackers" (in the technical sense) tend to hold a more traditional title suffix like "growth engineer".

It seems marketers ruined the term "growth hacker" for engineers (marketers ruin everything after all). But this time "growth engineer" is unequivocally technical.

Who are growth engineers?

Growth engineers are a response to the two trends above:

  1. The most effective users of martech are engineers
  2. Growth is not marketing. Growth is operations.

Growth engineers are technical teams with either a professional or formal background in engineering - they learnt to code on a job or in school. They tend to be more improvisers than planners, and grounded in the day-to-day problems instead of dreaming up big future ideas. Less grand architect, more MacGyver. Some say... "MacGrowther".

An aside: Not that marketers need more jargon and acronyms, but we find it helpful as internal shorthand at Hull. ;)

Unlike product-focused engineers, growth engineers must have domain expertise around the business and marketing problems they're trying to solve. Their job is to enable & optimize their sales, marketing & revenue-focused teams by "joining the dots" between a myriad of different tools & data spread across different teams.

Their goals and KPIs are unlikely to be related to metrics concerning a CTO (like application performance), but more likely related to those of a COO or CMO (like the number of qualified leads). For this reason, they often fall under the budgets and organization structure of COOs and CMOs where they support or replace traditional revenue operations teams.

Common ares of ownership we often see include:

  • Payment operations - integration billing, subscription, accounting, and sales opportunity data
  • Content operations - integrating content assets, content sources, (meta) content management systems, code repositories, and deployment tooling. (See GatherContent's manifesto)
  • Customer data operations - integrating tools, tracking & databases, data enrichment, cleansing & transformation, and end-to-end data flows

Within each of these sets of systems lie business rules which drive growth. For instance, pricing, sales compensation, lead qualification & assignment. These business rules shared three common characteristics:

  1. Objective - There is nothing subjective about pricing or how much sales reps get paid. It is what it is.
  2. Codified - in a documented process or in code so it runs the same way repeatedly. This means you're not making one decision, but potentially hundreds, thousands, millions of decisions over time all at once.
  3. Independent - no matter how big or small, the rule stays the same. You might tweak as you grow, but you're tweaking the rules, not the output.

By focusing on optimising business rules, there's a distinct separation between traditional (ongoing) sales & marketing, and those who are architecting, implementing & optimising the rules behind this.

On the Hull growth team, we think of this as "rules-based growth". See this Hull presentation from Turing Fest 2018:

We've spotted lots of teams thinking like this:

  • Drift's Growth team building out intent-driven automation
  • Dogpatch Advisors on building "relevance at scale" for sales enablement
  • DigitalOcean on using in-product triggers to enable consultative, helpful outreach to engage
  • InVision on scoring & signalling buying intent at account-level from a composite of known leads & users' behavior

All these teams are thinking of how to radically optimize business rules - particularly around sales and sales enablement where very little of the original Predictable Revenue playbook remains.

But the challenge everyone (even these teams) are trying to solve for is how to engineer their business rules.

How to empower growth engineering in your organization

Think of three elements you need to work together - tools, teams & data.

Let's start with teams - and there's good news! We've spotted a common pattern to sourcing for growth engineering resources within organisations. In Part 7 of The Complete Guide to Customer Data, we shared the best practices & pitfalls we see in customer data management & operations.

To unlock growth engineering resources, you need technical teams to be assigned to cross-functional, cross-team projects on a permanent basis. This is common amongst projects like payments integration and data warehousing - where these resources can be extended to work on more growth engineering projects. (Check the guide to learn more).

If the teams can be sourced, they need tools and infrastructure to manipulate the data. Engineers will approach this with a different mindset to marketers (who have had their thinking & solutions constrained by their martech). Engineers will seek to abstract and centralize repeated logic, create stateless (not stateful) programs, and seek solutions that can be logged, debugged & audited easily. Typically this thinking extends beyond the limits of a traditional marketing tool.

For customer data engineering, services like Salesforce, data warehouses and email marketing tools are each a system of record that store data in a structured way. However, these tools can't natively talk to each other. They need a "system of intelligence" - a brain - to tie them all together natively else you get a similar issue with.

Non-engineering revenue operations teams try to coerce core "systems of record" to behave as the "system of intelligence". With abundant plugins, customization, and years of iteration, you can slowly plug square pegs in round holes.

If you've worked with any complex martech for any length of time, you've probably seen tools like Salesforce (for customer data) and Wordpress (for content) bent out of shape to make it function as a system of intelligence between many tools. But this is clunky - and a familiar problem for developers with other technologies. Look at web development...

Web developers had the same issue. As single page JavaScript apps became ubiquitous, the complexity of building a rich web app and handling all this interaction without a central place to manage the state of the app became obvious. Look at the move from jQuery to React and Redux.

Romain DardourHull

So we've seen this type of paradigm shift before.

As with other technology trends before, it must start with a new developer-first infrastructure to your systems of record - something to sit between them all and act as your single source of truth within each domain.

This is why payment platforms like Stripe, "meta CMS" content management systems like Contentful and Prismic and "meta CRM" customer data platforms like Hull are becoming popular amongst growth engineers. Look at how these platforms are talking.

We believe that payments is a problem rooted in code, not finance. We obsessively seek out elegant, composable abstractions that enable robust, scalable, flexible integrations.


It’s the cure for the common CMS. Update once and publish everywhere, so teams build digital products faster.


Use consistent, up-to-date data across all your tools to orchestrate your perfect customer journey and experience end-to-end.


Centralized domain-specific systems of intelligence are the way forward for growth engineering. These become the all-day, everyday tool of choice for growth engineers.

2019 is the year of the growth engineer

Growth engineers are on the rise thanks to the three key trends:

  1. Most effective martech users are engineers
  2. Growth is not marketing. It is operations => rules-based growth
  3. Rise of "systems of intelligence" to enable growth engineering tasks

Since this is a post about engineering, here's the obligatory "we're hiring" plug, including growth engineers. Take a look at our active job posts.

If you're interested in getting started with Hull's customer data platform, take a look at our customer's most common playbooks for data-driven sales & marketing (it is not 2002 any more) and our guide to getting started with customer data integration.

And if you enjoyed this post, we'd appreciate a share or upvote on HackerNews, GrowthHackers, Twitter, or LinkedIn.

Ed Fry

Prev 'Ed of Growth at Hull, working on all things content, acquisition & conversion. Conference speaker, flight hacker, prev. employee #1 at inbound.org (acq. HubSpot). Now at Behind The Growth

If you've questions or ideas, I'd love to geek out together on Twitter or LinkedIn. 👇