In one of my previous articles, I wrote about three things that small companies shouldn't copy blindly from big tech. I promised to write another one that would bring the opposite – what could be taken from the FAANG playbook but for some reason is not that commonly used in the industry.
Disclaimer: the ideas in this article are based purely on my personal experience working in big tech and smaller companies over the years and multiple conversations I’ve had with other people working in FAANG. Not all big companies out there do the things I describe here, and some smaller companies do adopt such practices too.
Overall, smaller companies actually take a lot of inspiration from big tech. When I only started my career, it was quite common to see ideas coming from what was believed to be Google or Facebook's best practices – like open-space office layout, adopting design documents or building universal design systems. And it's not far from the truth – most FAANG things do make a lot of sense, even at a smaller scale. We can easily mention other pieces like having clear core values, roadmapping based on long-term planning or following well-organized release cycles. However, in this article, I would like to focus on three top things that seem to be less obvious but in my opinion could truly help smaller companies be better.
1. Experimentation and A/B Tests
I have a whole article on that topic. There are useful tips on how to extract the most value from experiments, and the top advice I gave was to always have a clear hypothesis.
But the problem with smaller companies is not even making mistakes in hypotheses, it is rather relying on product intuition much more often than on metrics. I have seen so many companies – ranging from smallest to large – that build things solely based on their founder's, product manager's or designer's vision.
This could also be caused by proper experimenting being actually not that trivial to set up – you need a whole list of things to consider:
Clear hypothesis.
Supporting multiple implementations in code and being able to switch between them.
Properly dividing users into balanced groups.
Logging how the users use the product.
Mapping those metrics to each experimentation group (control vs test groups).
Decision-making framework to make a conclusion based on statistically significant outcomes.
I would still argue that having this in place to make informed incremental steps greatly outweighs the cost of taking care of all those things – especially given today we have tools that simplify setting it up, for example, Firebase which gives us Analytics and Remote Config out of the box.
The product intuition, that gut feeling, can be a good source of vision and direction, but you can't fool the data.
2. Balance of Talent
I think this point was the trickiest one to name, but I'll try to explain. By having a well-balanced distribution of talent in the company, I mean that in big tech it's common to have teams, even the ones working on the most complicated cutting-edge projects, that include people of all levels – from juniors to experts.
I've seen companies throughout my career that are one of the two extremes: either most of the employees are students or graduates who still don't possess much experience and need constant guidance from a handful of directors and senior engineers, or everyone hired to the company is already a lead engineer, and the task of changing a button color can be up for grabs for weeks.
A healthy thing is to have a mix of contributors of different levels of experience and skills. What this brings:
A balanced team that can perform any kind of task – from simple to extremely complicated.
Ability to foster mentorship and growth mindset – more senior people pass the knowledge to others who learn quickly and then can lead projects on their own.
New joiners let you see the world from a fresh perspective – they can bring recent best practices from the outside.
3. Internal Testing
Larger companies often have employees routinely testing their own services. Maybe it's easier if your app is Netflix (who wouldn't want to binge-watch a TV show) or Amazon (shopping won't do it on its own) – something that has become such a widespread part of people's lives. But even with that, the employers in such firms would usually give free access to the whole service or provide the necessary hardware.
What benefits internal testing gives:
Faster feedback loop (bugs, wishes) that leads to higher quality and being able to ship more frequently.
Lowers the chance the manual QA and automated tests miss a bug.
More people familiar with the product bring more ideas for improvements.
Even if it looks like the products your teams are working on are not that overwhelmingly needed to be regularly used by colleagues, some measures to drive that testing participation still exist – such as giving free gift cards for testing payments, having contests for filing the best bug report or organizing dedicated bug bash sessions.
Conclusion
I hope the recommendations here will be useful to someone who is looking for ideas on how the workflow in their company might benefit from bigger companies' best practices. Please do let me know in the comments what you think about this list.