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.
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 are joining 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:
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:
As you are in the early stages of defining the problem, there are a few other essential questions to ask yourself:
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.
From my experience,?the most important data is whatever will help you understand:
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:
Feel free to reach out if you have any questions or want to connect :)
-Alishba