Experience working at Cruise! 🚀

It was an extremely exciting time to be working at Cruise. We had just launched our product (driverless rides) in SF, and we were receiving direct feedback from our customers daily. In addition, we were working towards exciting milestones like getting our first few paid rides, driving over 250 thousand clean miles and offsetting over 100 metric tons of CO2 emissions.

On the first day at the company, the one thing that stood out to me was how mission-oriented everyone was. Everyone worked tirelessly to develop fully electric driverless cars that were safer and better for the environment.

Alongside this, the team I was working on was reasonably new, allowing me to get my hands dirty with the early formation days of a team, defining the scope of work we did, and working on impactful projects. It operationally felt very scrappy, like a startup. Still, we had a ton of resources (compute, datasets, funding, etc.) at our disposal to work with, which was extremely helpful in making fast progress.

My team at our offsite!

I was excited to dive deeper into ML and hardware and learn from smart engineers with years of experience working in infra, robotics, and AI. But, most importantly, I wanted to learn about building a scalable product in a field without a playbook for success.

Although there are playbooks for success in software companies (i.e. what things are likely to work and not work), there are none for AVs. We don’t know what approach makes the most sense, and we don’t know what path leads to success. This felt like an exciting challenge to me, diving deep into a product with human-machine interaction while tackling the problems that arise from both the human and machine side.

Our work felt very similar to the early days of Uber: an idea at first that wasn’t fully understood by many but quickly became a technology that was widely adopted due to the critical pain points it solved and the ease it brought.

As I reflect on my experience at Cruise so far, I wanted to share some of my learnings. I hope some of these can be helpful to you if you are interested in their work or want to join a hard tech startup/SME:

Importance of interdisciplinary work and skillset

At the company, we have unique challenges that range from hardware, AI, compute infra, and embedded systems to robotics. For example, we are designing and developing custom hardware that powers our software stack, such as the sensors (cameras, radars, acoustics, LiDARs), compute and network systems, telematics, and infotainment. We are leveraging our sensors to collect input data for our ML-first approach for critical systems of our AV stack. Even if you are working on AI, you are touching parts of the hardware system to build and run new perception or prediction algorithms.

Working on such multi-faceted issues further solidified the importance of having depth in one area but breadth to work with other tools. You want to have other skills and knowledge (tools) in your toolkit that, even though you may not be an expert in, you know that you can leverage when solving a problem.

I like this framing by Mark Richards, a software architect, but applied specifically in the context of building an interdisciplinary skillset:

Expanding the top part of the pyramid is beneficial because expertise is valued. However, to work in a large team and be conducive to new ideas, you need to have a technical breadth and multiple tools you can leverage to solve particular problems. Although you might have expertise in one or two areas, it is beneficial to know that five other solutions can exist for a particular problem than to only be a singular expert in only one.

Iterating and moving quickly

Having worked on such multi-faceted complex issues at Cruise, I’ve realized that one of the essential principles in engineering and product development is usually the speed of iteration. I’m sure many engineering managers will agree, but the value of many shorter iterations is missed. To have a lot of iterations, you need to have speed. The faster you work, the more chances you have to iterate. Even though this is harder to do with hardtech, I think there’s lots of ways in which you can do this through working in simulation and doing sim-2-real transfer.

Another way to think of this: imagine that you have three weeks worth of resources to build something. You can spend three weeks building the first version and then releasing it. But at this point, you have used all your resources and still only have the first version of your product, which will likely change a lot.

Instead, let’s say you spend one week on your first version and then release it. Sure your product may not be as ready, but you get the first round of feedback much sooner. Now, you know if you should completely change directions or keep iterating on your approach. This will usually result in a much more robust final product.

The main concern with this approach is whether you can maintain a high bar for quality when moving quickly. What if you go too fast and ship crappy code and a crappy product? In my experience, this is not true. Speed and quality go hand-in-hand. Iterating on your code early can often result in better code than trying to design everything upfront perfectly.

Action items from this that I want to implement in other teams I work with:

• Setting weekly goals. If you’re solving a problem, the best way to think about this is: What will I do this week to chip away at this problem? If you can find a straightforward way to build or deliver something that relates to some value you create, then you have a good forcing function that encourages these shorter, more frequent iterations.
• Less “tech debt”. This may seem contrary, but if you are moving forward faster with more feedback/testing loops, you have more chances to catch any bugs in your product. If you are releasing things at once, it’s harder to know where the bug comes from when errors accumulate over time.
• Splitting the work into very small chunks. Something that I find helpful is breaking down a larger project into smaller pieces and understanding how each piece of work will contribute to solving the larger problem. The engineering part of my brain wants to zoom in, while the operator part of my brain wants to zoom out. As my manager would say, it’s helpful to do both “zoom in, zoom out consistently”.

Growing my technical skills + learning best practices

While iterating quickly on my projects, I spent a lot of time working with engineers and took away a lot from these collaborations on building my technical skills and best practices.

For example, I learned about the importance of documentation and writing optimized and clean code. It’s easy to write 20 lines of code to accomplish a specific task, whereas a different framework could have achieved the same goal in 5 lines of code. The engineering managers at Cruise were enormous advocates for writing optimized code. I learned more about the guidelines engineers at Cruise have to follow when writing and testing code. When pushing code to production, it has to follow a particular form so that anyone coming in can follow along and pick up where you left off.

This showed me the importance of slowing down: thinking through different frameworks for solving a problem before jumping to writing code. Doing this allows you to find the most optimized solution more effectively and then code it vs. jumping to a solution. As a result, I felt myself being more thoughtful about how I broke down problems and became a better programmer overall.

Developing product intuition

Alongside technical comprehension, there are two main things I think are significant when solving any problem:

• Defining the problem clearly: When most people think about a problem, they likely jump right into suggesting possible solutions. This can be negative because instead of understanding root causes, people tend to fixate on familiar approaches. It can be helpful to define the problem by seeing it from different angles, exposing hidden assumptions and revealing new questions for you to answer. An exercise I found useful was writing about the pain point from different perspectives to see the situation in new ways.

As you are in the early stages of defining the problem, there are a few other essential questions to ask yourself:

1. What does success look like if I solve this problem?
2. Who are the key users and what are their main pain points?
3. How many (usually engineering) resources do we have?
4. Where should this project go on our priority list?​

After the problem is defined, you will likely start searching for data to determine the root causes of the problem. Making decisions with half-cooked data is a big part of creating a new product. Unfortunately, you will never have all the pieces of the puzzle before making a decision.

• Searching for data: It’s key to avoid decision-making delays by holding data requests accountable to if-then statements. Think: What would change about your decision if you had data? What data is fundamental for you to have? If there are decisions you can make without data or a minimal amount of data, you should move ahead.

From my experience, the most important data is whatever will help you understand:

1. The magnitude of the problem.
2. The common root causes of the problem.
3. How much of the problem can be resolved if you tackled those root causes. This impact calculation is often harder to estimate since you may also need to be familiar with what already is planned or has been done that could directly/indirectly solve this problem.

Product intuition can also help you make decisions where complete data isn’t available. Even if you haven’t directly faced the problem, think back to past products you’ve built or your experience in this industry. This can help you understand what customers generally care about based on experience, either facing the issue or working on an adjacent type of problem and seeing the result. You develop this product intuition and a more robust judgment through more exposure.

I intentionally put myself in situations where I learned about different problems Cruise was working on and then tried to see how I would approach them vs. how others in the company were approaching solving these problems. The differences revealed biases I had about how I solved problems but ultimately made me more confident in my intuition.

Making tough decisions as a leader

One of the complex parts of running a company is making important decisions, especially when others may have differing opinions. You have to be able to hold healthy debates/discussions, but eventually, we need to move ahead, and some decision needs to be made. To make these tough decisions, you need to have a clear set of metrics for success and a list of where these metrics sit on a priority list. Of course, these can change as you learn more about your market, but it’s important to have something in place based on your current understanding. By aligning on these early with your team, you can always base your decisions on the growth of these metrics and the company’s overall goal.

For example, we must ensure our product works effectively and safely. However, you can always make product improvements, and it’s easy to fall into the trap of perfecting code before putting it into production. On the flip side, there’s also a lot of value in getting an MVP out to users and getting early feedback. At Cruise, the feedback we are getting from real customers has been so valuable and impactful compared to the feedback we were getting when just running internal pilots. Internal pilots help, but feedback from real customers allows your product to be pushed beyond a lab setting and be tested in new ways. For example, as our AVs were being tested, we realized new things about our functionality and edge cases that the AV would encounter in the real-world.

Meeting amazing people :)

Most importantly, I’m extremely grateful for all the amazing friendships and mentors I’ve made. Here’s a fun collage of my friends and I taking Cruise rides on late night adventures:

I also wanted to give shoutouts to the following people for making my experience at Cruise sooo amazing:

• Oliver Cameron: Your mentorship at Cruise and other projects I’ve done over the past few years have been so helpful. I truly can’t put it into words. I’ve learned so much from you and continuously look up to how kind, helpful, and supportive you are.
• Daniella Gutlansky: You’ve helped to push my thinking in ways I didn’t think was possible. I feel that I can now be more creative and more strategic when tackling future problems.
• Ananya Sharan: The guidance you’ve provided me has been pivotal in my ability to execute my projects. Thank you for helping me get unstuck and going out of your way to support and mentor me.
• Allen Tang: Your help alongside Teddy, whether with the query or anything else, was very valuable. I’m excited to see all the impactful work you do.
• Teddy Forscher: You’ve taught me so much, and I appreciate your time helping me directly with my projects when I was stuck!
• James Hammond: I appreciated our lunch conversations about work, college, and life. I value how honest and open-minded you are as a leader and want to embody these qualities more.
• Lucie Zikova: I’m so glad we got to know each other better during our team offsite. Your support on my projects helped me think more creatively and be very thoughtful about my recommendations.
• Sarah Rizk: I enjoyed our meeting on the rooftop at the office and continue to admire all the impactful work you are doing at Cruise.
• Neil Srinivasan: Our 1on1s was one of the favourite parts of my week. I’m excited to see all the great things you’ll do on the AVB team!

Feel free to reach out if you have any questions or want to connect :)

Twitter, Linkedin, Email.

-Alishba