Do we always need engineers to build products?
5 reasons why building without engineers can super-charge your product development in Series B startups
Software development has changed a lot in the last couple of years. I used to think you couldn’t build a good product without an engineer, or without knowing how to code. I have changed my mind since then.
In this article, I want to explore how specialization, and the need for engineers to do all engineering work is a thing of the past, and instead, small companies should leverage the freedom granted to us by new tools spanning product development to data engineering allow more teams in the company to build, accelerating product development.
The advantages include creating an empowered team, lowering costs, better code(!!!) and importantly leveraging the talent and ideas across the company.
Why should we even consider building without engineers?
1. Cost
Engineers are expensive. In fact, most engineers cost almost 2x as much as a data analyst, growth marketer or operations analyst:
On top of that, every startup and company is always looking for more engineers. This puts you into a vicious cycle of trying to compete for the best talent with half the budget of a big tech company.
2. Product Development Growth
If only engineering builds products, your product development is capped by the number of engineers you have.
According to this article, engineers form about 50% of the workforce of a Series B startup (higher than I thought!). Let’s say our Series B startup (Company A) has 100 employees, and every engineer can do 1 release a week (in reality, its usually less than that as there are code reviews, prioritization, etc, etc). This company can release at most 50 products a week:
On the other hand, another series B company (Company B) also with 100 employees per week that leverages the entire workforce to build products can build 100 product features a week.
Company A is capped at 50 product releases a week, whereas Company B can build 100 product features a week. Exactly, that 2x as many as Company A, at half the cost (based on point 1 above). Doesn’t that make building without engineers a no-brainer?
3. Better Code
How possibly can building without engineers lead to better code?
The first time I built my now defunct site LMNS, I thought I needed to build it from scratch. This required learning how to code, hours trying to understand how to hook Sendgrid up to my email capture and tons of frustration trying to understand what stack overflow forums were telling me.
After weeks of heads down work, I was finally prepared to use the LMNS site for our first marketing competition. Everything broke. All participants that tried to submit their work wrote disappointed emails about their poor experience. I was gutted. My hours of hard work were totally unappreciated, and they didn’t even create a delightful customer experience.
Fast forward a couple of weeks later. I built a landing page on Squarespace in a couple of hours, seamlessly hooked it up with Mailchimp and put it to work. This time, no errors, nothing broken, superior user experience.
You see, I would argue that not building everything yourself frees you from the constraints of having to deal with infrastructure. Mailchimp has teams of people ensuring their mail service run well, you have, well yourself!
4. Up-leveling your workforce
Part of the reason engineers get paid as much for what they do is because their work is hard. It requires a lot of technical skill that required hours of learning.
Asking your employees to use more tools to do their jobs is equivalent to growing their skills, and therefore, you they too can increase their value on the job market. Imagine if a startup, facing a looming recession wants to hire 1 growth marketer. Does it prefer the growth marketer that has only worked with agencies to run ads, or the marketer that has a portfolio of creatives they have designed in addition to running ads?
Does that mean we should always build without engineers?
No. Rather, it’s about putting our super valuable engineers on projects where their unique expertise can create exponential company value. Is that really updating that one line of HTML to update copy?
Additionally, it’s also a question of resources. As companies grow, they can afford to specialize. The risk however for Series B, is that specialize too early, stunting their growth. I have written an article on how companies can make decisions about buying or building here.
Ok, how do I start this in my organization?
2. Empower Designers and product managers: Using Webflow for front-end design
A lot of the time, front -end engineers build upon the design specs designers have given to them. This effectively means we are doubling design work. What if there was a tool that could automatically transform these designs in HTML? Well there is. Webflow, is perfectly suited for designers as it allows them to build sites in an Adobe style interface
3. Empower Analysts: Use DBT to build data models without data engineering
DBT is just awesome. When I used to write pipelines (and they were terrible) they broke consistently no matter how hard I tried. DBT has abstracted the pain of python operators empowering the analyst, with SQL in their hand to build data pipelines. Sure, there is still some engineering knowledge that helps set dbt up, but their awesome documentation means any one can do it.
Subscribe to DDIntel Here.
Visit our website here: https://www.datadriveninvestor.com
Join our network here: https://datadriveninvestor.com/collaborate
