Coming into undergrad, Sarah Spaugh, ’18, MS ’22, felt like she was “a little late in figuring out what all of the different engineering disciplines were.” At first, she tried out the introductory product design course, but she finished the quarter wanting more . . . something. She found it in a Mechanics of Materials course taught by associate professor Marc Levenston, MS ’90, PhD ’95, analyzing the nitty-gritty of internal structures and their connections to the real world. Spaugh then chose mechanical engineering as her major, found her way to the Stanford Solar Car Project, and took on a lab assistant role in Stanford’s Automotive Innovation Facility. She says a “lingering curiosity” led her to pursue her master’s in electrical engineering, when she realized she wanted to commit herself to interdisciplinary work.
During an internship at Tesla in 2020, Spaugh helped design the physical switches that manage energy within a car battery. Now, as a vehicle systems engineer at Tesla, she gets to focus more broadly on the flow of energy through cars, from storage to performance, in service of ever-better designs.
Photo: Aniea Essien
STANFORD: What do vehicle systems engineers do?
Spaugh: My team uses simulations and data to analyze the performance of existing cars and to anticipate requirements for future cars. This often involves studying the power train, organizing the engineering effort that goes into the battery, the motors, and everything that takes energy out of the battery and puts it down to the wheels—how quickly we can deploy power, how efficiently we can deploy power. Under our umbrella, we’re concerned with how the vehicle performs from an efficiency standpoint and from a speed acceleration standpoint. We also consider user experience and how the car functions in adverse weather conditions.
We maintain a series of simulations that we use to model the power train in different contexts. Then, we use that to inform other design teams—say, the batteries teams or the motors teams—that this is how this design might perform in a future use case, or this is how this design might perform according to a series of standard tests, such as the ones given to us by the EPA to benchmark our cars and put a sticker range on them that we can advertise to customers. We’re also able to help pinpoint the source of lack of performance, like if a car is not performing as well as we were anticipating. Sometimes, we can use our simulations and our analysis efforts to figure out where in the system that is coming from and where we need to look to improve ourselves.
What are your daily tasks?
Spaugh: I do a good amount of programming in my day-to-day because the main internal product that I’m working with is those simulated models. When I’m not programming, a lot of what I’m doing is pretty communication-focused, like building up presentations and sharing the information that I’m learning. Recently, I’ve been doing a bit of work on data analytics. So, looking at data from real cars and combining that with simulated information to do more of the same analysis.
What project have you enjoyed the most so far?
Spaugh: I’ve really enjoyed working on some portions of what we call our energy tool. This is an app on the vehicle user interface and part of the code that runs in the cars. It basically breaks down the energy used by the car into different buckets so that the driver can see why their range depleted a little faster than normal. It’ll offer suggestions such as: Oh, you were driving over 70 miles an hour for a couple of hours on the highway, and it’s less efficient to drive at that speed, so you lost X many miles due to that excess speed. Or, oh, you have really strong headwinds right now.
I liked working on that because a lot of my team’s work is internal. This one was directly outward-facing and impacted something that people use in their day-to-day lives.
What role does collaboration play throughout your projects?
Spaugh: We’re working with the motors teams. We’re working with the batteries teams. Sometimes we get to interface with the new programs engineering team and the design studio. Working with them is always interesting because you get some insight into the thought process that goes into trying to think about what the car should be in the five-year timeline, which is very different from analyzing what a car should be like while you’re in the process of trying to launch it as quickly as possible, which is normally where my team is working.
On my team, we have 11 full-time employees and one to two interns. We often work in a feedback loop with other teams to translate engineering on specific vehicle subsystems into the full vehicle perspective. For example, we might take a set of desired vehicle attributes—things that the customer might see, like the advertised range—and then correlate these to more detailed, specific design requirements for various components of the car.
How did your coursework prepare you for your work at Tesla?
Spaugh: Getting some exposure to both [mechanical and electrical engineering] departments, I saw a broad range of topics. Also, the workplace here moves at a decent pace because of the variety of work that’s available to me on my team. So, the pace at which Stanford moves—and the pace at which you’re asked to pick up new information—was super helpful for learning how to learn things.
How has being an engineer been different than you expected?
Spaugh: Interning helped me not be so surprised by the day-to-day work. I did a couple of internships through undergrad, so I feel like my onboarding into real engineering was pretty smooth. I do think the focus on communication has been a little surprising to me—the extent to which that didn’t just come automatically and naturally, and always getting real feedback on presentations I’ve made and charts and ways that I’ve presented. In school, obviously, you do a final presentation, and you do learn to communicate work and whatnot. But people [in school] are just asking for your presented information so that they can give you a grade. It’s not necessarily as critical for them to really understand the subtleties in what you’re communicating as it is in the workplace, where someone else has to then do something with that information. So I think it was a little bit surprising to me that I couldn’t just whip up good communication content right away. It really takes some time, some work, and some thought to do a good job at that portion of my job.
What is the most challenging part of being a vehicle systems engineer?
Spaugh: I think just covering so much breadth as a team. There will be projects where I’m really focused on the battery, and I’m really in the brain space of thinking about batteries. Then my next project will ask me to flip over and look at something that’s interfacing with the inverters team a lot. I would say that covering so many different areas is what I love about working on this team and what makes it so interesting, but it is also challenging.
What advice do you have for young engineers?
Spaugh: Be open to trying new experiences, and then trying to learn from as many professors, professionals, and older engineers as possible. Ending up in this role was a lot of me just looking for opportunities and then saying yes to them when they came along. I tried to remind myself to be really open to learning new stuff continuously along the process.
Kalissa Greene, ’25, is an editorial intern at Stanford. Email her at stanford.magazine@stanford.edu.
