- Injecting Amazon DNA into a startup by hiring Amazon alumni is a common tactic, says one alumnus.
- Adjusting some of Amazon’s processes can help startups with similar business needs, such as logistics.
- But the alum warns that forcing startups to adopt other bits of Amazon culture could be harmful.
Dave Glick joined Flexe in April 2019 as Chief Technology Officer. He is the former vice president of fulfillment technology at Amazon.
There has been a lot of coverage of Amazon’s recent exodus. Reports say more than 50 vice presidents and even more executives have left Amazon for startups in recent years. Many are bringing Amazon leadership methods to their new businesses.
I should know. I’m one of those people from Amazon who left to work for a smaller company. And I’ve seen what works and what doesn’t in the “Amazonification” of startups.
The most important lesson: Just because something worked at Amazon doesn’t mean it will work at your startup. Your startup is not Amazon.
Before you join the logistics startup Flexe as Chief Technology Officer, I worked at Amazon from 1998 to 2018, building and leading one of the largest technical teams in the company. At that time, Amazon grew from $700 million in revenue and a few thousand employees to $210 billion in revenue and was the second largest employer in the world.
Amazon’s success is driven by its customer obsession, big thinking, execution and, most importantly, the internal mechanisms it has built over decades to make it the engine it is today.
Some of these mechanisms and infamous jargon are well documented: make six-pagers, or narratively structured memos instead of PowerPoint presentations. To develop core principles: that stimulate decision-making at the ground level.
There are also “two-pizza teams” and single thread leaders that bring focus and allow teams to move quickly. And bar-raisers, the practice of using interviewers from different teams as objective third parties.
The list goes on. These mechanisms allowed Amazon and its people to create systems that maximize accuracy and collect the necessary data for in-depth inspections and analysis.
But most businesses, especially startups, lack the infrastructure, systems, and metrics needed to do this.
When I got to Amazon, it was a startup, and none of these mechanisms existed! Bar raisers came in at about $800 million in revenue in 1999. Six-pagers were implemented in 2005 with sales of $8.5 billion, and the principles arrived in 2006.
Here’s the point: All of this took time to develop. You can’t just read Bill Carr’s “Working Backwards” and implement all these mechanisms. The key is to understand which Amazon mechanisms should be introduced when; no matter what, they should match the needs of your new company’s unique culture.
When I first joined Flexe, I planned to write six-page stories. I soon learned that my customers (sales and operations teams) were not interested in reading and processing six pages in real time. So we went back to presenting slides. This is more productive for Flexe.
I did include Amazon’s single-threaded leadership, the most important project management tool I’ve learned. A leading indicator of whether something is actually being done is that a leader is only focused on it.
For example, we had a major technology project to merge codebases and improve our core technology platform. It required coordinated efforts from many teams. We flashed the first quarters and didn’t make enough progress.
We then assigned our most senior program manager to the project and gave him a simple metric to achieve: Increase the percentage of revenue running on the converged platform. He created a roadmap, started to disable features and migrated customers to the new platform at the same time.
Since we hired a single-threaded leader, we’ve exceeded our project goals every quarter.
We’ve also implemented the Amazon two pizza rule: each in-house team must be small enough to be fed two pizzas and have clearly defined areas of ownership. This allowed us to limit the responsibilities for each individual engineer and give our teams ownership. Not only are our engineers more productive, they’re also set for success because they don’t need to know the entire code base.
A lot has gone into making Amazon what it is today, and mechanisms are just one part. These mechanisms are not inherently good or bad, nor do they apply to every business and situation – the key is to know which tool is right for the job.
I believe that any successful business, especially a logistics company, would benefit from some Amazon DNA. It would be foolish not to rent from Amazon if you can – and I certainly did. But former Amazonians can’t expect to just come in and implement the “Amazon playbook” without regard to context.
Those who succeed outside of Amazon aren’t the brightest or strongest; they are the most adaptable.