A lesson I’ve learned the hard way is to not have a singular idol, whether that’s a person or a company. In one way or another, you will be disappointed. Instead, I pick and choose my favorite learnings from individuals and organizations.
I had to remind myself of this as I started to read “Working Backwards: Insights, Stories, and Secrets from Inside Amazon“. It’s hard to ignore the impact Amazon has had on the environment and economy—however there’s a lot to learn from things the company does really well.
The book focuses on Amazon at large, but to make the takeaways useful for my situation, I apply them at the team level… but really the idea is that these concepts scale up and down as needed.
Codifying principles and culture for your team early on is important. Once your team starts growing, it’s impossible to retrofit culture. Amazon has 14 leadership principles and having been through Amazon’s recruitment process during my MBA program, they truly do reinforce that in their hiring process. Perhaps at Amazon scale, you can get away with having 14 principles, but personally 3-5 guiding principles sounds about right to begin with, especially for a small team or organization.
While my intuition is to only capture “non-intuitive” principles or principles that might be a radical departure from common understanding, over time I’ve realized that the definition of common understanding is so varied. For example, “Be kind” to me sounds like a no-brainer in a work environment, but that’s not necessarily true for everyone. As a leader or a founder, it becomes essential to determine the things that truly matter to you, and then embody them in every work interaction.
Dependencies are a drag on teams. I have experienced this at pretty much every company I’ve ever worked at with over a thousand employees. While I’m skeptical that Amazon has truly solved this problem (please confirm or deny if you work at Amazon), the authors of the book describe a model of single threaded leaders (STLs), which is a fancy of way saying make one person responsible for a single focus area and nothing else. Then, give them what they need to be successful.
I’m not surprised this works, given that leaders are normally overwhelmed with too many initiatives and too little time. However, failures in this scenario can be long-drawn out and expensive. I guess it takes a culture like Amazon where long-term thinking is rewarded for this to work. And from the sound of it, efforts like Kindle and Alexa were born from this model.
The written narrative culture at Amazon is pretty well known at this point. No presentations, only six-page (loosely) documents. Google is doc-heavy as well, although not as rigid as Amazon since we don’t have an outright ban on presentations. In any case, I love the proliferation of this writing culture across the tech industry.
For one thing, people who skate by on charisma or political clout can’t hide behind a poorly reasoned documented. I know there’s some debate about the merits of commenting on documents as a form of feedback, but I tend to think it’s a good practice as it allows for more voices to be heard. Otherwise, it’s just a deluge of the loudest, senior-most people in the room giving their input, and I’ve often found it difficult to meaningfully participate.
On a related topic, this was a passing tidbit in the book but something that I really liked – the most senior folks involved in any decision making should give input last so that they a) don’t bias the room and b) let others be heard.
Amazon uses the Press Release (PR)/Frequently Answered Questions (FAQ) format before funding a new product. It’s an interesting way to make sure the customer facing features are thought of first (hence the name of the book “working backwards”). Every organization I’ve been at has a version of this, although the discipline around customer-centricity varies. In general, it feels worthwhile to think through details like features, feasibility, pricing etc. ahead of writing a single line of code. It is a lot of work, but it’s better to do it before a fully-built product sinks.
This might not be a novel idea but it’s my favorite takeaway from the book. Controllable input metrics > output metrics. Metrics like revenue, profitability, and usage can be lagging indicators. Really, what you want to keep a close eye on are input metrics aka factors that drive revenue, profit, and usage in the first place!
For example, let’s say you notice a dip in revenue. That information in itself isn’t helpful to answer why. The next step might be to dig into items in stock. Perhaps they were fewer items available to purchase, leading to loss of revenue. Now, the idea is, wouldn’t it make more sense to actually measure this controllable input metric instead? By doing so, you basically skip one step ahead on your data analysis, and can stay more plugged into your customer/user experience.
Lastly, when looking at data, you have to filter out signals from the noise. Small variations are normal and digging into each one is a waste of time BUT you can only recognize what is a true variation vs a regular one if you look at the data often. This is my note to self to look at data more frequently.