As I’ve mentioned before, after 12.5 years at Amazon, I decided to move on and do something different. You may ask first why I left Amazon. I’ll get to that some other time. I want to first start with how is life outside Amazon. More specifically, how is life on a small mid-aged startup (6 years, past Series C) where the headquarters is in a different city where I’m working, and most people in the company have been doing software for less time than I have. That’s Sift Science, if you don’t quite know what I’m talking about.
TL; DR: it’s great! But this answer has quite a few dimensions to it:
- People: Sift is made of a lot of genuine people, open to feedback and learning. Amazon had a lot of those too, but for the most part Amazon’s culture focused the attention on people that were aggressive owners: they cared a lot about what they were trying to deliver and that sometimes created a little bit or us vs. them behavior.
- Visibility: Sift’s business is “simpler” and way more transparent to all employees than Amazon’s. Part of it is some level of maturity of the processes and staffing that Amazon has that led to a more complicated interaction between the parts of the business. And part of it is also the size of the product and the required siloing of the decision process. But, for the most part, there is some institutional distrust of people having too much information and that information potentially leaking to competitors. Back to the “people” aspect above, there is no distrust anywhere, so information flows everywhere (sometimes a little too freely, as I can see all closed deals, and ones that fell through).
- Software Maturity: that’s where probably there is a lot more to do at Sift than there was at Amazon. That’s expected for a fairly new company with reasonably young software developers. While the overall landscape of knowledge around availability, scalability and development best practices in the software industry has improved tremendously in the last decade, there are some components of the way software is being written that remind me of Amazon 12 years ago: monolithic structures focused on standardization and code reuse with the cost of complexity and unexpected dependencies (e.g. a table around metrics was broken and that prevented work on a job that only did a backfill for ip-to-geo mapping data).
- Problem space: in this one it’s a little hard to compare. At Amazon I was either working for projects that affected other teams (e.g. catalog projects to support category launches, or website feature launches), or things that directly affected customers (Amazon Go). At Sift I’m helping other companies scale their operations by externalizing the concerns about fraud detection. While we have the ability to have very close contact with those customers, in the end the impact to their business is only something we can guess or approximate. So measuring impact can be a little harder. Qualitatively, though, it’s a very important problem space, probably more important than any project that I’ve ever worked with at Amazon (unless Amazon Go actually takes off and causes a change in the way physical retail works – no signs of that yet). Getting feedback from some of our customers saying that they were only able to expand to different geographies because they trusted Sift to be able to detect fraud they were not experienced with and keep their focus on the actual “positive side” or their business is invigorating and not a rare feedback to receive.
I’m not going to deny that Amazon is an amazing company. It is honed with building processes and investments necessary to deliver things and learn from it. If that’s what you like to do and you are ready to sell your soul to get things done, I strongly recommend Amazon. Yes, it’s a large company, which means that there are pockets of everything, but in general it’s a relentless environment focused on business optimization and delivery.
Sift is not that. It is passionate, quirky, but in general sees problems in a more software-centric route. There is no strong business and process culture, but a culture of looking at the software that we’ve developed and the models that we’ve created, and making them better. That sometimes means trying some things that don’t necessarily take you anywhere, but there is no feeling of loss when that happens. We just try something else.
I don’t think I can right now claim is better or worse. It just opened my eyes to doing things differently. Internally I’m still struggling with the adjustment to it, but I can’t deny that we have very happy customers at the end of the day, so it’s certainly not the wrong way to do anything.
Maybe I’ll checkpoint my thought process again in another 6 months!