“We’ve had these new landing pages mocked up for the last two months! All of our research says the new pages will be a huge conversion lift. Can you talk to the engineering team and see what the holdup is?” The marketing director was frustrated, and rightly so.
It’s not uncommon to be bottlenecked on engineering at pretty much any stage of a start-up. In part, the problem stems from a “FAANG-level hiring bar” that is common in engineering teams.
As the Head of Growth / Marketing, your job is finding ways to unblock your team from making progress while playing nice with Engineering.
Here’s what I’ve seen work:
Hire Mechanics instead of Engineers
Getting the engineering team to lower their bar is a fool’s errand. Getting them to hire more engineers just for you is refighting a battle you’ve already lost.
The easier move is to reframe the problem. In car terms, you work with a team of engineers that are out there tuning your company’s Formula 1 racer, but all you need is an oil change on your Prius.
You don’t need engineers - you need mechanics. In the tech world, these are people that can do html/css and a bit of javascript (the best ones will also have a decent design sense), but fall outside of the engineering world for the purposes of hiring or reporting. I’ve seen a few names for this role inside companies - “webdevs” seems like an innocuous enough title for html mechanics.
Where do webdevs report?
I’ve seen three options; they all work.
- Webdevs could sit in design, especially if they are of the school “designers with enough HTML to be dangerous.” -
- Alternately, webdevs could also sit in of marketing directly, reporting to a director that is able to keep an eye on their work.
- Finally, they could be part of an external contracting agency, in which case their management chain is inside their agency, and the agency has an account manager checking in with the Head of Growth/Marketing.
How is their work prioritized?
It’s kind of crazy, but mostly I’ve seen webdevs jump on things immediately after being asked, delivering changes in minutes. There is also usually some sort of task tracker (something simple like Asana, or whatever marketing uses) in case multiple stakeholders are asking for things and the webdev needs their manager to tie-break and prioritize.
There is no sprint planning, which means marketing counterparts are able to be a bit more agile in deciding when they need help.
Where do webdevs come from and what does their career trajectory look like?
Most webdevs I’ve met learned HTML & CSS on their own, and ended up doing a bunch of freelance front-end work online, or for neighborhood small businesses. Working at a fancy start-up is an exciting step up.
In most cases, webdevs will start as contractors, and go full-time if things are going well. Career progression will vary across their various strengths, going full-time into design, performance marketing or software engineering; alternately, they could end up managing a team or webdevs or starting their own agency.
Subscribe to Engineering Growth
Stay up to date on new essays and updates on Growth Engineering.
How do you keep Engineering happy with this new dual-class structure?
Webdevs won’t be contributing to the primary code base or critical surface areas. The webdev tech stack (mostly landing pages) will be entirely separate, and engineering is not accountable for it.
You’ll also want some oversight, via a strong front-end engineer or EM to have check-ins with the webdev team to see what kind of help they might want / advice they might need. However, there is no requirement that these webdevs need to be “managed” by engineering.
The existence of webdevs will reduce the pressure on engineering, since a number of the asks marketing would normally have will be handled internally.
Constraints
Unlike a silver bullet, webdevs are not a silver bullet.
- Slightly Riskier - ultimately, part of the benefit of “A Player” engineers is a process that tries very hard to avoid bugs, through things like automated testing, a separate staging environment, and code review. A typical webdev workflow will skip most if not all of those steps in the name of speed and scrappiness. The good news is, if something breaks, the webdev can revert it just as quickly.
- Limited Scope - over time, you’ll want to try some fancier landing page experiences around interactivity, as well as changes to other parts of the purchase flow. Once you start getting fancier, you’ll start running into code “owned by engineering,” and need to go back to the more traditional planning and resourcing processes.
- Thought Partnership - webdevs tend to focus on speed of execution (the how), and will generally be more deferential around roadmap (the how). This feels great early on; however, one of the benefits of working with a strong engineer is that they’ll get involved in the underlying business problem, and suggest approaches you hadn’t considered or didn’t consider feasible.
If you find yourself bottlenecked and haven’t yet brought in at least a couple of webdevs, try it out and let me know how it went
Tags: #growth-eng