Background & Introduction
I am a software engineer, who recently switched companies from Amazon to Uber. I have worked for 6.5 years at Amazon across multiple organizations and geographies. For the past one month, I have been working with the Data R&D organization of Uber at Seattle.
This post addresses the question my friends and colleagues have asked me, “What is the difference in working at Amazon vs. Uber?”
What this post is not!
Engineering culture of a company cannot be defined in broad strokes as it is unique to every team and every org. The thoughts presented in this post are based on my observation working with specific teams and organizations and do not represent the broader company culture.
This post does not reflect upon my rationale to make the first company switch in my career and hence, the content should not be interpreted as such.
From Amazon to Uber
There are multiple commonalities and contrasts between the work culture at both the companies. Some of these can be attributed to the relative size of the companies while others are inherent & unique to the DNA of companies themselves. I am going to outline some noteworthy differences that I have encountered.
DevOps hustle
DevOps hustle is everywhere. Trying to maintain high availability for your services while not impeding rapid pace of innovation & continuous production releases is a hard problem to solve. Even more so, when we are talking about the massive scale at which Amazon & Uber operates. Both companies have a laser sharp focus on operational excellence, but while Amazon has long established, mature processes towards addressing the problem, Uber is still still experimenting with what strategy works best for them.
Amazon might be notorious (unfairly if I may add, see SIDENOTE#1) for heavy ops burden on software engineers with round the clock pager duty & on-call support, the reality is (IMO) that every company with a little ounce of customer obsession would take the reliability of its systems very seriously and Uber is no exception to that. Hence, DevOps hustle at Uber is no different than at Amazon, maybe even more, owing to rapid growth of the newly minted platforms & loosely structured operational processes.
Open source
Usage of OSS is perhaps the biggest difference that jumped out as a surprise to me when I joined Uber. Uber is an open source first company. This is reflected from its choice of internal tools and technologies to its impressive track record of giving back to the community [see SIDENOTE#2].
Building the internal infrastructure around open source technologies gives developers freedom to choose the right tool for the job and spend their energy in solving business problems where innovation is required. This also means that you have a diverse network of developers over the internet to help when stuck trying to debug an issue with a third party library. In contrast, working at Amazon which relies mostly on in-house developed infra & tools, narrows down your list of options to choose the correct tools and limits the amount of support options you have when stuck with an issue.
Instead of building every developer productivity tool itself (for monitoring, dashboarding, paging, recruiting), Uber licenses a lot of tools from companies which provide Software As A Service. These smaller companies with a focused portfolio tend to have better software for their domain that any in-house developed tooling. As a developer, this gives you the latest & the greatest tools to boost your productivity and improve software development lifecycle. This also frees up developers to focus on developing software for business problems & features unique to Uber.
Transparency
At Uber, there is a weekly hands-on with the company leadership where the execs answer questions from employees. In addition to that there are periodic all-hands at every level of the executive chain.
As a developer, this gives you transparency around the rationale behind the decisions made that impact you & your work. This helps you align your work more closely with the company objectives and ensures that you are spending your energy trying to solve the right problems. It also gives you visibility into the challenges that exist beyond your immediate team or org. Coupled with the strong emphasis on documentation, this gives you an opportunity to get the answer to every “why” that you might have around any decision (technical or not) made. As a hypothetical example, if I have a question on “Why is Uber leaning towards Go over Java? or Why is my org structured the way it is?”, there would be a document which is accessible to me explaining the reason in great detail.
Such degree of transparency pertaining to every decision whether technical or not is refreshing and is extremely helpful during on-boarding to your team & understanding the state of the existing infrastructure. In contrast, at Amazon, the level of transparency was exposed on a need to know basis.
No AWS
I miss the days of getting an auto scaling, fully managed MySQL compatible database on the click on a button. While working at AWS, I underestimated the simplicity that the cloud Infrastructure As A Service (IaaS) has brought in the development lifecycle of a software engineer. Using the cloud services comes at a cost and, at Uber, while you can use any technology that you need to get the job done, you have to justify the cost of paying a cloud vendor vs. managing/developing on your own.
Social interaction at workplace
Due to the small headcount at the Seattle engineering office of Uber, the work place feels tightly knit where you personally know people other than co-workers in your immediate team. The social events during lunch hours and the cultural site-wide events play an important role in bringing the feeling of togetherness as a unit. In contrast, Amazon operates in small functional units where your social interaction is limited to your two-pizza team (unless you make an extra effort to join company wide events which are always overcrowded).
Engineering challenges
Both the companies are not very different in the kind of engineering challenges that you would solve. In either case, you would have a business use case which cannot be solved by existing solutions due to the scale and availability requirements (perhaps the requirements for AWS might be greater than Uber’s in different domains). The business problems at these companies might be different but from an engineering perspective, at the end of the day, you are designing systems which work at a larger scale, are more robust, simpler to use and faster than the existing solutions. These solutions are tailored to fit the exact business use case which can be complex and diverse across these companies. Perhaps, the contrast lies in the number of engineers dedicated to solve a problem. A two pizza team working on a problem at Amazon would probably have a single developer working on the solution at Uber.
Involvement in strategic decisions & roadmap
At Amazon, this is a topic which is heavily influenced by the org you are working on and the direction set by the executive leadership. I have experienced involvement ranging from no visibility into the data behind a top down mandated project requirement to having complete involvement via an engineering led round table discussion for the 2–5 year plans for a technical product. At Uber, every decision associated with the internal product that I own rests with me, right from identifying the gaps to defining success metrics. With my limited exposure at Uber, this seems to be the norm in my org (not a product org, it is a platform org) rather than an anomaly and ties to the point of a single person having more ownership at Uber than at Amazon.
Working in a remote office
At Amazon, I used to work at the HQ in Seattle where all the stakeholders, partners and upstream dependencies were accessible in person with a 10 minute walk, whereas at Uber, my stakeholders & dependencies are distributed across geographies. This particular point is very specific to the teams I worked with at either companies, but is nevertheless a big change I felt in terms of my work. With remote dependencies and stakeholders, one has to make extra effort to bring together the synergies. Video calls do not fully substitute the advantages of in-person meetings & discussions. Neither do occasional cross office visits replace the home advantage of having everyone you work with within the same office space.
Ground up innovation
Uber encourages the software engineers to seek and solve problems outside their immediate work domain and team’s charter. If you identify an engineering problem that you want to tackle and it would benefit Uber, the management is very likely to allow you to spend time in solving that problem even if that problem scope is outside the team’s ownership. In contrast, at Amazon, it is difficult to get visibility of the challenges being faced at other orgs and hence, difficult to work on a problem without actually moving to a different team.
Lunch/snacks at office (It matters!)
Amazon does not provide free lunch to its employees and its offices do not have cafes where you can purchase wholesome lunch daily, while Uber has company provided free catered lunch with rotating daily cuisines. No matter how I try to justify that this difference doesn’t matter in the grand scheme of things, the truth is that, having the option to eat lunch at office & availability of on-demand snacks throughout the day has boosted my productivity. No more spending half hour hunting for food in crowded downtown restaurants or the pangs to go home early because you are feeling hungry.
Looking forward
As I graduate from being a nUber and getting some experience under my belt at Uber, I am starting to appreciate how do the company’s core values/tenets manifest in the day to day work, something which Amazon excelled at. As a developer, these tenets help in the process of decision making and bringing alignment in discordant views across an organization. I would write more about this once I have a better understanding of this and other realization that come only with experience.
Meanwhile, you can follow me on Twitter to get updates about my software engineering journey at https://twitter.com/divijvaidya
SIDENOTE#1 : Being oncall for the systems that I own has perhaps been the best teacher for me in my career. This has guided me towards writing operationally sound and secure systems from ground up and I truly believe that every company should adopt Amazon’s model of oncall & operational processes.
SIDENOTE#2 : Cadence, M3, Ludwig, Fx, Marmaray etc..
Disclaimer: All opinions and thoughts expressed in the article are my own and do not reflect the opinions of my past or present employer
Top comments (0)