At a 500-person company, growth is a department. A lifecycle marketer, a product analyst, a data engineer, a front-end engineer, and a PM who coordinates all four.
At a 25-person company, growth is one person. Sometimes the founder. Sometimes the one engineer who will touch marketing.
At 120 people, it is still that one person. But now they need to perform cross-functionally across multiple teams to ship effectively.
Most people read the small company as the weaker setup. Fewer people. Less specialization. No dedicated resources. That reading is wrong across most of the range. The small company removes the largest cost in growth work: the coordination tax.
So the question is not how to escape the many hats. The question is how long you keep the advantage before scale takes it.
The Actual Surface Area
Growth engineering at a small or mid-size company is not a narrow job with a broad title. The surface area is large. In one week, the same person could:
instrument events so the funnel is measurable at all
build or fix the marketing site
ship an onboarding flow change
wire up attribution so paid spend has a denominator
stand up an internal dashboard, because nobody can answer a basic question
test pricing page copy
automate a manual process that someone in sales repeats forty times a week
That is front-end, back-end, data, and marketing in one sprint. It looks unfocused. It is not. Every task above asks the same question: where does the funnel leak, and what is the cheapest system that stops it?
Why Fewer Hands Move Faster
A large growth org moves slowly. The cause is not talent. The cause is the coordination tax between the layers.
Run a conversion experiment at an enterprise. Marketing writes the brief. Design mocks it. A PM prioritizes it. An engineer builds it. Data instruments it. Analytics reads the result. Six handoffs. Each handoff degrades the intent and slips the calendar.
Run the same experiment at a 30-person company. One person writes the hypothesis, writes the copy, ships the code, confirms the event fired, and reads the result on Monday.
That is the whole argument. The growth engineer is not a better engineer. The growth engineer closes the loop without waiting on anyone.
What Changes As You Scale
The hats do not disappear as you grow. The binding constraint changes.
10–40 people | 40–150 people | 150+ people | |
|---|---|---|---|
Who owns growth | Founder or one engineer | One or two growth engineers | A growth pod |
Binding constraint | Clarity: what to fix/grow | Hours: too much to fix/grow | Coordination: access to fix/grow |
Handoffs per test | 0 | 0–2 | 5–6 |
Right move | Instrument, then fix activation | Build systems that outlive the person | Protect the growth engineer's access |
Most companies lose the advantage in the mid-size band. It is rarely a headcount decision. It happens through access. A platform team owns and deploys. A design system governs the marketing site. A data team owns the warehouse. Each decision is reasonable alone. Together, they turn a zero-handoff role into a four-handoff role, and nobody decided to do it.
At 150 people, defend the access, not the headcount. Access means commit rights, product data, and experimentation infrastructure. Remove those, and you keep the title but lose the mechanism.
The Failure Mode
Many hats fail in one specific way. Nothing compounds.
Week one is a landing page. Week two is a Zapier chain. Week three is a dashboard that nobody opens. Six months later, there are forty small artifacts and no system. The person is busy, and the metrics are flat.
The number of hats is not the problem. The question is whether each hat leaves a system behind. That is the premise of The Architecture of a Growth Engineering System.
A landing page test that leaves no instrumentation behind is a one-off. Run the same test on an experimentation setup you built once, and it becomes the second data point in a series. Same effort. Very different return.
Ask it of every task: after this ships, is the next version cheaper? One question, run a test. Repeated problem, build a system.
The Build Order
Small and mid-size companies build these layers in the wrong order. They start with acquisition, the most visible layer, and skip the layers that make acquisition legible.
Instrumentation first. Events, user properties, one source of truth for the funnel. Not a full warehouse. Enough to see where users drop. Without it, every later decision is a guess in a confident tone.
Activation second. The gap between sign-up and first use of a key feature is usually the largest leak. It is also the cheapest to fix, because it sits inside your product.
Conversion third. Pricing page, upgrade flow, trial-to-paid. Now you have traffic worth converting, and data that tells you whether it worked.
Acquisition fourth. Content, SEO/AEO, paid. Most companies start here. This layer rewards the previous three, because only then can you see which channel produces users who stay.
Retention throughout. Not a phase. Watch it from day one. Act when the shape of the curve is clear.
Most teams do this in reverse. Which framework you run inside those layers matters less than the order. The 4 Product Growth Frameworks cover how to pick one.
When To Add A Second Person
The signal is not headcount or revenue. The signal is the same bottleneck, week after week.
Add someone when the experiment backlog grows faster than it is cleared, and the items are already well specified. That means the constraint is hours, not clarity. Add someone when a surface, data, lifecycle, or the site needs a person who only handles that. Add someone when the growth engineer has stopped building systems and only maintains them.
Hire before that, and you buy specialization for a funnel that nobody understands yet. That is the expensive mistake. It is more common than under-hiring.
Final Thought
Many hats look like what you tolerate until you can afford specialists.
Between 10 and 150 people, the opposite is true. One person who sees the whole funnel and can change any part of it does something a five-person team cannot. They close the loop between hypothesis and result without asking anyone.
The mistake is not staying in that model too long. The mistake is accidentally dismantling it on the way to 200 people.
The hats are not the problem. Hats with nothing underneath them are.
FAQ
Does a small company need a growth engineer, or can the founder do this?
Early on, the founder usually is the growth engineer, and that works. It becomes a hire when the founder's time is worth more elsewhere, and the funnel work runs continuously rather than occasionally.
What if we are not product-led?
The layers do not change. Only the contents change. Sales-led companies still need instrumentation. They still leak between demo and close. They still benefit from someone who builds the internal tooling and attribution that sales and marketing run on.
Is this a marketing hire or an engineering hire?
An engineering hire with marketing-adjacent scope. Without commit access and product data, the role collapses into marketing ops. Marketing Engineer vs. Growth Engineer covers where that line sits.
Can one person really cover front-end, back-end, data, and marketing?
Not at a specialist's depth in each, and the job does not require that. It requires enough depth in each to ship a complete change end-to-end without a handoff. That is a different skill from excellence in any one of them.
We are at 150 people, and growth work has gotten slower. What happened?
Usually, access, not capacity. Count the approvals needed to ship a conversion experiment today, then count what it took a year ago. If that number went up, you have reintroduced the handoffs you were fast without.
What's the one thing to do this week?
Take the largest drop-off in your funnel and instrument it properly. Don’t fix it. Instrument it. You cannot optimize what you cannot observe.
The Growth Engineering Handbook covers systems, frameworks, and tools for building scalable growth. Subscribe here.