If you run a software business, you are either an engineer yourself or have hired engineers. While hiring engineers can be challenging for many reasons (multitude of choices for them for jobs, salary requirements, etc), I think there are some common mistakes made when hiring engineers that when remedied can help us hire better.
When I was at HotPads we hired a four person growth engineering team. This team sat on the regular product engineering team, but the focus of the team was to work on growth initiatives coming from my team – SEO, email, and content initiatives.
Hiring a growth team was a small gamble, though we had seen the model work at other companies, and negotiation between heads of teams was required to make sure that the growth engineers would be integrated with the rest of the engineering organization so that their code was reviewed properly and everything we did fit within the overall product vision. I’m not saying we did it perfectly, but the results spoke for themselves.
Chart via SEMrush
Today I want to talk about hiring growth engineers. First we’ll talk about the traits of a typical product engineer, then why growth engineers are different, and finally what traits to look for as you are hiring a growth engineering team. You might also be asking yourself why I’m writing this post here on Credo. Well, I am fully convinced that one of the reasons why businesses aren’t successful working with agencies is that the business is not set up for success. There are no resources to implement audit recommendations, execute on content, and whatever else is needed. While some agencies can do a lot of this for you, there is always an investment required by the business to get things done on their end.
Table of Contents
The Typical Product Engineer
I live in San Francisco, the epicenter of today’s technology world. As such, I know a lot of engineers and product people.
Engineers become engineers because they like solving problems. If you look at a lot of tech startups, they almost always have a technical cofounder, and that person has usually come up with the idea because they want to solve a problem and do it with software, and they have the skills to build it. So they start writing code and creating something, whether it’s a mobile app or a web app.
Building a product is a lot of work, and building a company is even harder. Because you are working hard to get traction with customers, product engineers like to keep moving forward and building more features. Sometimes this is because the features have not been done before and are hard to make, therefore it is a fun problem to tackle and solve. Once that problem is solved and the feature put out into the wild, the engineer then wants to move on to the next problem.
One of the biggest challenges I had working inhouse as a growth person was working with engineers who didn’t want to be working on growth initiatives. Largely, they had been hired to build new product features and that excited them, not going back and refactoring.
In my experience, most product engineers hate going back to refactor features that they worked on before, because the next new feature is way more interesting to create than running tests and optimizing what you already built to make it work better. The thinking is “The feature is there, now it’s up to the user to figure it out”, which from my product and growth perspective drives me crazy. But, as a semi-technical founder myself I completely understand this. I’ve built Credo almost completely myself, and once I roll out a new page or a new feature I don’t want to go back and tweak it all the time; I’d rather move on to new features that I think will move the needle.
Why Growth Engineers Are Different
Growth engineers necessarily have to be different from product engineers. While product engineers are hopefully building what their customers need (which is usually learned by a product manager or researcher doing customer research to identify pain points), growth engineers are necessarily driven by metrics.
The tasks worked on by growth engineers are usually driven by a growth PM or marketer whose job includes closely monitoring metrics, understanding what moves the needle for the business, and then creating hypotheses around why metrics are not where they should be and how to get them there. The process looks something like this:
The growth PM is responsible for setting goals alongside business and finance. They own the current metrics. Then they come up with hypotheses why the current metrics aren’t meeting the goals set. They then design new tests and work with the growth engineers to implement them. As they are rolled out to the public, the growth PM or their team then measures the effectiveness of those new tests. They compare these against goals and the process repeats.
This process would drive a normal product engineer insane. Why are you building something that might not get you the results you need? My answer as a growth person (can you tell I have dueling thoughts in my mind all the time as I build a company?) is that we do not know what is going to work. We can only come up with informed hypotheses and let the data tell us what works.
Because a business has to balance both new features (which are SO important. Please don’t think I am dogging on them at all. I love new features and so do customers) and optimizing existing features, I believe every business needs to have someone dedicated to the continual optimization of features to hit the needed metrics.
Traits of Great Growth Engineers
Now let’s talk about the traits of growth engineers. I was happily able to be an integral part of hiring five growth engineers in my last role, and then as I worked on other brands I was also able to interface with more engineers who had to straddle both product and growth initiatives. These are the traits that I look for in growth engineers, or that engineers who are working on growth initiatives and happy tend to have:
Very collaborative
Growth engineers are collaborative. Instead of seeing themselves as a product manager cum engineer, they see their function as a support role supporting the business. While they have very good input on how something should be built, or what needs to be built before they are able to tackle the growth feature, they also value what growth people and their metrics-driven mindset brings to the table. The best growth engineers I worked with are also creative and help come up with hypotheses for why something might not be working.
Happy with iteration<
Growth engineers get joy from incrementally moving the needle and working towards a specific metric goal. This goes along with collaboration, as iterating on features requires rapid ideation, building, testing, and tweaking.
Like variety in what they are working on
This is a trait that product and growth engineers sometimes share. Because growth can happen many places across a product and the companies that grow fastest develop a high-velocity testing culture that lets them test many things all the time, the growth engineer has to love working on many different projects at once.
Not afraid to tackle new parts of the code base
In tandem with variety, growth engineers have to be insatiably curious. Instead of being apprehensive about tackling new areas of the codebase, they have to be excited about the discovery part. And because real growth in tech companies comes from leveraging technologies in new ways, they also have to be creative. Don’t know how to use Twilio? No problem, they are excited to learn. No Stripe API experience? Not a problem.
Manage expectations well
The final trait that I see as necessary in growth engineers is the ability to manage the expectations of stakeholders well. Mostly, this revolves around scoping work and keeping their growth counterpart in the loop about issues they run into that may cause the new feature test to be delayed. They ask questions if they are unsure and also let their growth counterpart know when shifting requirements will make a feature take forever. Ideally, they’ll also think of creative alternatives that can speed up the process of development.
What do you think? Are you an engineer who loves working on product features but also has to work on growth? Are you a business owner who is frustrated by engineers not liking to go back and refactor? Or are you a growth person who is struggling to hire the right engineers to work on your projects? I’d love to hear your comments; let’s start a revolution!
