Career paths for engineers are often constrained to two possibilities: becoming a people manager or a high-level individual contributor. At Uber, however, engineers have taken on a variety of roles, from moving into a product track to working on promotions and compensation.
Uber Engineering’s Rick Boone found another path, working his way from a site reliability engineering (SRE) role to a software engineering role to joining the Infrastructure Leadership Team as a strategic advisor. Rick built on years of engineering experience to his current role, where he looks at the big picture of Uber’s infrastructure with an eye towards the future.
Uber’s infrastructure, running in data centers and cloud services, hosts our platforms that connect riders and drivers, delivery people with restaurants and eaters, and shippers with freight carriers, among other services. People around the world rely on this infrastructure to get places, earn money, and run their businesses, so ensuring its long-term health and ability to scale for growth are very important.
We sat down with Rick to talk about his journey into his current role at Uber:
How did you first become interested in technology and engineering?
My mom and dad met while working as computer operators for New York City. My mom was the Manager of Computer Operations for the Department of City Planning. I sometimes went to her job with her, so I became fascinated with computers from an early age. Of course, this was the early ’80s when big mainframes occupied a whole room and used punch cards for input. As I grew older, I got into hacker culture, reading 2600 Magazine and logging into BBSes. I also went to a math and science-focused high school, which helped cultivate my left-brain thinking. When it came time to consider college and choose a major, I was going to pursue a degree in either Computer Science or Pre-law. If you’re going to study Computer Science at the University of Southern California, where I went, you had to commit to it as a major when you come in, so that was a factor. But, really, at the end of the day, computers were my passion, so that’s what I ended up doing.
What encouraged you to apply for a role at Uber?
I had been working at Facebook in Production Engineering, which is basically the same as SRE, for three years, but in 2014 decided to leave and travel for a while. I went to Thailand for a month, spent three weeks in Europe, and attended a wedding in Mexico. At the time, I was just figuring things out, like who I was and what I wanted to do next. The day before I left for Europe, I got an email from a recruiter at Uber. I had heard a little bit about the company at that time, mostly from reading blog posts. One article, about how data scientists at Uber could use anonymized, aggregated data to identify a city’s nightlife districts, was particularly fascinating. I got a sense at the time that Uber was a company that could change the world. It was actually the only company around that I found compelling enough, product-wise, to want to work at, and that’s actually still the case today, five years later.
I responded to the recruitment email and they set up a call between me and the person who would eventually become my manager. He really sold me on the company, though I was already fascinated by what I knew of them before then. Within a few days of me coming back from Europe, I came in for interviews, and shortly after had an offer.
What type of engineering were you doing at that time?
I was a site reliability engineer, though at the time we were called Infra Embeds, doing things similar to what I had been doing at Facebook, making sure Uber’s business infrastructure was available, reliable, and scalable. In general, SREs are responsible for ensuring that the platform can continue to serve requests no matter what happens in the world, whether it’s heavy site load or hardware failures. At the time, I was embedded with the API team. Before we transitioned to a microservice-based architecture, Uber’s entire business logic platform was composed of a single, massive, monolithic 600K-line codebase and service, simply known as “The API”. This position allowed me to gain a deep and focused understanding of the domain so I could make sure we had the right resources to handle what was being built and the demands placed on the API by users all over the company.
What team are you on now and what projects do you work on?
I’m on the Infrastructure Leadership Team, working as a strategic adviser to the head of Infrastructure here at Uber. My title is still engineer and I still do engineering work, but not on a day-to-day basis. In this role, I’m looking at our infrastructure from a higher level, like trying to understand a specific problem space and figuring out how we work on it, get things implemented, and what resources we need over the next two to three years. I’m looking at technical and cultural problems from a very high level and with a very long time horizon.
Part of my job involves considering how we orchestrate the various component areas of Infrastructure–things like developer platform, hardware domains, reliability–together to make our infrastructure the best possible place for internal engineers to develop the software that runs Uber and for external customers to use the products that Uber makes available. Then there’s things like organizational design, group psychology and behavior, understanding how different teams work together. We’re a global organization with dozens of teams working across 6 sub-organizations, in 11 of Uber’s 13 engineering offices, so I need to understand how these different teams work together. I need to figure out if there’s any pain points or friction we can remove or any ways we can organize those teams, offices, and the work they do more deliberately and strategically.
I also focus a lot on the engineering culture within the organization. Culture is one of the most effective levers available to organize people to build and do amazing things, so I’m always working to better understand and improve ours.
What is most challenging about your work at Uber? What is most rewarding?
I have the same answer for both questions. Adapting to new things, understanding and handling the associated fear of failure, is a challenge but ultimately rewarding. I’ve changed my career path at Uber twice now, taking hard lefts from what I had been doing. Each time it’s been a big and terrifying risk, which then paid off. I love what I’m doing now but it took a lot to steel myself for the possibility of failure, and to actually embrace it not only as part of the job, but really, the only thing that would actually allow me to truly succeed. One Friday I was an engineer, then the following Monday, I was reading and writing about strategy. I had to rapidly adapt and learn on-the-job about something entirely new to me.
Every time I’ve done this, it’s terrifying in the moment, but when I look back six months later, it’s unbelievably rewarding. I’ve experienced huge growth and found some parts of myself that I didn’t know were there. I’ve started to realize how I used to put myself in a box, but have learned that potential is limitless.
Interested in joining Rick and the many other software engineers working to solve real-world problems at Uber? Take a look at our careers page!