On referrals, product engineers, and bootstrapping 💡
Monday Ideas — Edition #103
🔍 Graphite — the code change stack
One of Refactoring's most popular articles ever is about code reviews.
Back then I commented on this new tool, still in private beta, which allowed teams to do stacked pull requests, like the teams on Facebook, Uber, or Google did.
The tool’s name was Graphite. Fast forward today, Graphite is a staple of thousands of engineering teams, and I am happy to promote it in the newsletter.
Graphite takes care of the whole code change workflow:
Create — it helps you make small stacked code changes easy on GitHub.
Review — stacked changes are smaller and easier to prioritize, review, and merge.
Merge — lots of small changes means your company ships more than ever.
Check out the Asana case study below 👇 it made engineers save 7 hours per week, and ship 21% more code.
1) 🏅 Reward good referrals
Referrals are the best way to bring in high quality candidates. Full stop. If you are a growing startup, they will naturally be your strongest hiring channel for a long time.
So you may want to encourage referrals by setting generous rewards for people who bring them in.
How generous? A head hunter usually takes 15-20% of the yearly gross salary. Within your team, you may settle around ~10% after the probation period, and make the formula simpler by defining fixed amounts based on the role of the candidate.
Pamela Gotti, CTO, uses referrals to make engineers participate actively in the hiring process 👇
We do encourage everyone in the engineering team to be owner of the hiring process, meaning that referrals are really encouraged, and everybody is aware that the responsibility of growing the team is not HR's only.
The [hiring] process for referrals is the same, except that the first [screening] step is not done by HR but by whoever reaches out to the candidate.
The flip side of referrals is that they may hurt diversity. By relying too much on them, you risk creating a workforce with too much of the same background. You should pair referrals with a good outbound strategy.
I wrote more about channels and hiring strategies in this previous piece 👇
2) ✨ Product engineers are the way
You can find more and more stories today of teams being able to create incredible products with an incredibly small number of PMs, compared to engineers:
When you look at how these teams work, the common thread is they give engineers more ownership and autonomy than what most companies think it’s possible.
Engineers are effectively product engineers — they own full-stack features and entire slices of the product. They do their own project management, leaving PMs to focus on strategy, direction and support.
Compare this to a traditional agile team with product owners:
Product Owners have mostly tactical responsibilities. They groom the backlog, write user stories, prioritize what to do next, and attend all the agile meetings. Their focus is short to mid-term.
Product Managers have strategic responsibilities. Unlike POs, they are responsible for the product vision and success. They focus on outcomes and leave engineers in charge of the actual tasks. Their focus is mid to long-term.
This shift is healthy because it promotes ownership and reduces coordination headwinds.
I wrote more about it in this previous piece 👇
3) 💸 VC vs Bootstrapping
There is a lot of confusion online about when it makes sense to raise VC money for your project, vs when it is better to stay bootstrapped.
This is fueled by a lot of myths about working with VCs vs staying independent, and strong identities by people in the two camps who often bash each other.
I have done both in my life: been a VC-backed founder for ~10 years, and a bootstrapped solopreneur right now, with no plans to raise money.
Here is my take:
The VC route makes sense when you are obviously and inescapably bottlenecked in a way that only money can solve, and you know exactly how.
Based on your product, you can meet this bottleneck at different stages. It may be very early if you are doing e.g. OpenAI and need money for GPUs. Or it may well be after product-market fit — people may love your product but margins are low, so you need economies of scale which only money can buy.
Generally, bottlenecks are not absolute. Chances are you can continue to grow, just slower.
VCs just put you on an accelerated growth path, so, oftentimes, the big question is how fast you want to grow:
Can you grow slowly, at all?
Is slow growth an existential risk to the business? E.g. other will catch up and it’s a winner-takes-it-all market.
VCs and freedom 🦜
Among indie hackers there is also this strong bias against VCs because they supposedly take away your freedom.
In my experience, this is false.
VCs, especially good ones, rarely interfere with the things you do, except for very few items, like funding and M&A. Good VCs invest in you and your team before they do so on the business, and understand that you know your space better than them.
On bootstrapping 🎒
This is not an absolute rule, but chances are the more you can progress in bootstrapped mode, the better. As long as your product stays on a growth trajectory, delaying fundraising means having better chances of succeeding on it, and on better terms.
Also, the leverage you have with AI and good tooling today is completely changing expectations about what you can build even with a scrappy team of one. The bar you need to clear to raise funds is higher than it was a few years ago.
On niches and small businesses 🏢
A final consideration about niches and small vs big businesses. VCs notoriously look for big wins, which, apparently, takes a lot of product ideas off of the table when it comes to funding.
I have found this to be not exactly true. Most small products can find ways to niche up and expand their scope over time, because that’s how internet works: you solve a problem and then you find other 3-4 adjacent problems that you are well-positioned to solve.
However small your starting niche, your fundability rather depends on your ability to deliver a credible story about how you will go past that niche to become, eventually, a large business.
More ideas on whether you should start a startup in this recent piece 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the paid version — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca