I've been asked on numerous occasions what differs a "great" growth engineer from just a "good" growth engineer. In my mind it came down to doing three things incredibly rigorously:
Org Growth is the summation of all it's moving parts.
If like myself you've worked in startups, you'll come to realize all the little inefficiencies and manual operations currently in practice. As a growth engineer enabling others will grow the company much faster than your experiments will.
For example, at Qatalog we needed a way to build landing pages at scale for our SEO, and after building 10-15 pages using our CMS, I realized that adding new component to a single page type took 2-3 minutes of manual CMS management. That's a problem, because if we scaled to 100 pages that equates to 5 hours of CMS editing time.
I resolved this issue by creating one singular template page for each page type in the CMS and used a Google Sheet to interpolate values onto that template (like how an email template renders first name and last name). Now all the editors have to do is copy and paste in the values for new pages/components. Hours saved.
The pretense of knowledge is our most dangerous vice, because it prevents us from getting any better - Ryan Holiday
Opinions are a growth engineer's pet peeve because they're not grounded in research. A truly data-driven startup doesn't waste time on opinions but rather aims to answer questions using experiments or research.
It all starts with a question that you cannot answer with the data you currently have available (often times you'll realize that you're not tracking the product correctly).
As a growth engineer, you should learn about sample sizes, AB or multivariate tests, statistical significance, and growth models. It's up to you to enforce creating experiments with good background research and clear learning outcomes.
Slow is smooth smooth is fast - US Navy
Startups move so fast that they often don't take the time to look deeply at their own data and customer research.
As a growth engineer, being proficient in SQL is a hard requirement because at some point you'll need to dig into the data beyond what Heap and other analytical tools will offer you.
Alongside data scientists, you'll be working on creating dashboards to provide analytical learnings for yourself and the rest of the company (enablement).
I can't stress how ill prepared a lot of startups are in building dashboards and tracking the correct metrics.