I've been working at Uber, in Amsterdam, in our European HQ since mid-2016. When I joined, there were 25 of us in tech: engineers, product managers, data scientists, designers, UX researchers. We've doubled since every year: we're at 130 people at the end of 2018. Next year will be no different.
This post is to share my personal experience, working at Uber Amsterdam.
Above: Dara visiting the Amsterdam engineering office earlier this year. When we asked what he'd like to see in a year, he told us to double our size and double the impact.
We're getting there, on both counts.
What we work on
We build the next generation of payments experiences, at scale. This means two things. First, it is about innovation, experimentation and building innovative things. This can mean building new things or building things at a scale that previously did not exist. Second, it means making an impact, at scale. Payments are not some nice-to-have things on Uber. It's pretty much the only thing that if it goes wrong, it has a wide-ranging impact. It is an interesting challenge to make sure things work as they should 99.99% of the time.
Innovation within payments is a surprisingly fun area. Payments is not exactly the most innovative thing that one would think of. Which is why it's nice to work at a place where we challenge this thinking. Things that my team has launched since I've been here include rewriting the Uber rider app, the Uber driver app and redesigning the payments experience both times. We launched Venmo on Uber and worked closely with teams to use machine learning to help riders choose their preferred payment method. We also did a lot of behind the scenes work to launch Uber Lite, a slimmed-down version of Uber and in launching Uber Cash, a new type of payments wallet.
Reliability at scale, in a challenging environment. Before joining Uber, I never thought of getting into payments. It does not sound like the most exciting thing, after all. After a few years of working in this domain, I have come to appreciate how challenging it is. When payments don't work at Uber, it has a very real-world impact. People are stuck, trying to get to an important appointment. Drivers might not be able to get dinner, as they have not been able to cash out (yes, this happened).
I sometimes joke that if you can design, build and operate payments systems reliably at the scale that we do, you're ready for just about any systems reliability challenges in the industry.
At the same point, the environment is full of constraints found in few other places. End-to-end testing is very difficult to build, due to all the anti-fraud systems in the financial networks. An E2E test might pass once, then twice, until the payment provider will mark this as fraud, rendering it useless. Because E2E testing can't really be automated, this forces building world-class monitoring and alerting. Because payments are inherently local, monitoring needs to work both on a global, as well as a regional level. And when things do go wrong, then we make further system improvements to our already sophisticated tools and services.
(Work) culture
Cultural norms. Uber keeps evolving, as do our values. Mid-2017, many people - including myself - got together to discuss what culture we want to cultivate. The result is the 8 cultural norms that reflect what we value and expect from people working here. The things that I identify most with is acting like owners, being customer obsessed and doing the right thing. Another one that by now, feels natural to me is ideas over hierarchy. Even if you're the least experienced in the room, that takes nothing away from the merit of your ideas.
Transparency. We have a culture of proactively sharing within engineering. Before starting a project, teams do some lightweight planning and documentation. This plan is sent out to practically all of engineering to comment. I wrote more about this in this post: Scaling Engineering Teams via Writing Things Down and Sharing - aka RFCs. We also share a lot of what we do on our engineering blog. Examples of the depth we share are how we go into details on our experimentation platform (did you know we have over 1,000 experiments run each month?) or in-depth explanation on our financial forecasting pipeline.
Open source. We are huge users of open source and prefer technologies built on these. We regularly contribute bugfixes back to the libraries we use and open source a lot of things ourselves as well. Myself and many people on the Amsterdam team were active participants in open sourcing the RIBs framework.
(Somewhat) technology agonistic. People often ask me what language do we hire for. We don't hire for any given language. The technology stack at Uber keeps evolving and we are pragmatic in choosing the best tool for the best job. On the backend, we build most new services using Go or Java. Our older services are built in Python and Node.JS, which we are retiring. On mobile, we currently use mainly Swift, with some Objective-C and on Android, it is Java. We keep having continuous discussions and experiments on different frameworks/languages that might be a better fit for some areas, like Kotlin. Much of this discussion happens internally accessible for everyone, using our RFC process. You can read more about what our tech stack looked like two years ago here and here.
Continous improvement. As we grow quickly, each team and organization has pain areas that they all work on solving. For my team, one of the main areas that we are working hard to getter at are oncall. Teams at Uber are very autonomous and can spin up a new service after going through the RFC process. We have a "you build it, you own it" rule. This also means the team building will be responsible for making sure it has the appropriate uptime, once launched. This continous improvement is present everywhere at Uber. We have a team focusing on us contributing to open source be more productive. Other teams want to get better at listening to customers. Others work towards reducing tech debt. Some work on better developer tooling... we know we can improve in many places and are actively working on it.
Get things done and celebrate. There are times when the work is easier and times leading up to public launches where the team develops a sense of urgency to get things done. Sometimes, we have to make difficult decisions on cutting a feature to meet a launch date we previously set or to launch later. We always get there, in the end. After a job well done, we celebrate, have fun and relax. When I say have fun, it comes in different flavors: below is the animation our designer created for the launch of the new Uber rider app (codename: Helix).
The team
The people I work with is one of the best perks of the job. We have software engineers, data scientists, designers, product managers, UX researchers and product operations people work together, in one team. You can read more about the Amsterdam tech team on this engineering blog article.
Above: Uber Amsterdam tech a year ago, celebrating the third year of the office. A year later, we're about double size.
Several people working in the office are also regular speakers on conferences. You can watch Pawel talk about managing chaos at scale, Victor and Pavel talk about building apps at scale, myself talk about continous testing at scale or some of my other talks.
Come work with us, in Amsterdam!
We keep hiring for talented people across tech to join us. You can see all of our open positions here.
Interested in working directly on my team? My team is hiring full stack engineers and senior backend engineers.