Book reflection: Competing with Unicorns
How the World’s Best Companies Ship Software and Work Differently
Competing with Unicorns by Jonathan Rasmusson was a relatively short read compared to many software engineering books. Brevity seemed appropriate given the content and I appreciated the authors ability to get to the point.
Non-unicorn company vs unicorn company takeaways
There are a few big non-unicorn company vs unicorn company takeaways that I got out of reading Competing with Unicorns.
Enterprise development vs startup development
Jonathan stresses the importance of the distinction between the traditional enterprise development process and the development process of successful startups. There are a few case studies which allow us to deduce some general similarities amongst successful tech giants.
Traditional enterprises are prone to value up-front planning over iteration which tends to be opposite for startup companies. Also, startups value discovery and learning over estimation which is not the case for most large enterprise companies.
Now the reasoning behind these company values makes sense to me. Established non-unicorn companies tend to spend a lot of time developing for an internal audience by automating domestic processes to better support their customers whereas startups might not even know who their customers are yet!
Projects vs missions
The idea is that team members perform better when working for a higher purpose rather than checking somebody elses boxes. The author posits that a small autonomous team that's on an ongoing mission tends to produce better results than a constrained team on a finite project.
While I agree with his hypothesis generally, I'm not sure all of the author's assumptions fit the bill for every project team. There can be project teams in traditional enterprise companies with the autonomy to get the job done correctly and efficiently without being micromanaged and obligated to original requirements. That being said, I understand the purpose of the polarity here in order to make the point.
I also agree that people tend to cut less corners when they will maintain the system they build. Throwing a system over the wall to another team after meeting a deadline doesn't give engineers much incentive to sacrifice precious time to make that system as robust as possible.
Corporate hierarchy vs flat reporting structure
The value of a relatively flat reporting structure is something that I've witnessed first hand. At least for me, there's tremendous benefit in working with your company rather than for your company.
In the book, Jonathan highlights team organization where he worked at Spotify. Small autonomous squads work together in chapters, tribes and guilds to make an impact on the company1. These squads should have as little dependence on others as possible and are usually comprised of engineers, a product manager and a data scientist or two.
The importance of data scientists is one of my biggest takeaways from this book. It definitely makes sense to have a person dedicated to gathering, cleaning and analyzing sensitive company data in order to drive key success metrics and facilitate efficient scalability.
Main takeaway: unicorns continuously improve
Unicorns continuously deliver using techniques such as feature flags and release trains. The feedback loop between the builders and the users is as tight as possible. They instrument their product to track user behavior in order to gain insight into the product usability. They use this and other data to determine results of A/B tests which are basically permutations of feature flags for subsets of the user base. These unicorns are also analyzing data with data scientists and machine learning.
This continuous improvement is what sets unicorns apart from the competition.
Competing with Unicorns is not the best book if you're looking to learn about transitioning from a traditional enterprise to operating like a startup. However, this is a great book to learn how some successful startups are organized and how they operate.