As engineers, we’re always encouraged to work collaboratively. In most cases, projects are designed to be dependent on multiple individuals. However, as student researchers in grad school, it’s easy to become solely involved in our own projects. We get used to setting our own schedule and approach, often only needing to update our PIs. This is great and all until the time comes to have an internship or job in a more collaborative environment. In this blog, I want to contrast the different expectations when working on a research project that you lead vs. working on a larger, collaborative project where you only work on a single component and have to report to a team, and how that affects one’s communication approach.
Throughout my academic career, I’ve interned at JPL four times. In the past, I mostly just worked with my mentor, and together we tackled our research project. Every once in a while, we would update the respective science and engineering teams on our progress that was most relevant to them. For the most part, however, my mentor and I were the ones deciding research direction and approach. This mentor-student relationship can vary depending on the project, lab size, and number of collaborators. Sometimes there are multiple students on a project trying to meet the pre-established requirements. Other times, a student is working with several collaborators on a project. It wasn’t until this past summer, when I did my fourth internship in a systems engineering group, that I realized how many meetings go into agreeing on a project’s trajectory.
To give some context, this past summer, I was working on autonomous system health management for the proposed Endurance Lunar Rover. Because this mission is in the early development stages, I had a lot of say over my approach for my algorithm and how it would fit into the design as a whole. In other words, the project defined what each component in the architecture needs as inputs and outputs, and I had free rein inside my box. However, this also meant that there were a lot of unknowns for what I should be taking into consideration when designing my algorithm in order to meet the high-level requirements for my part of the architecture. The majority of my summer ended up being consumed by meetings with several individuals, subgroups, and teams. This proposed mission has an autonomy team, a hardware team, a scheduling and planning team, an integration team, and the list can go on. At each of these meetings, everyone had different ideas for what I should be doing with my project. There’d be times when I made a good amount of progress and then had to scrap it and start over in a different direction. Yes, it was frustrating at times trying to manage everyone’s expectations and project goals, but this is all part of engineering at NASA. Because these missions are so large, responsibilities get distributed among several teams. Things move quickly and everyone must be up to date on what’s going on.
As progress is made and roadblocks are reached, it’s helpful to get insight into different factors of the project. In this case, it’s helpful to get feedback from individuals in different teams. But again, take the meat and leave the bone. Once I did a general survey of what everyone had in mind for my project outcome, I had to sit down and decide where I actually wanted this project to go while also contributing to the greater goal of the mission. Everyone is going to have their own strong opinions and approaches, and while it’s crucial that everyone is aware of updates and on the same page, you have to start somewhere, or else you’ll be brainstorming and planning forever.
In this case, I advise clearly setting your expectations for each meeting so that you address the more pertinent questions and topics. A short slide deck that just lists this is great, so that you simplify the problem and don’t lose people by over-explaining unnecessary details. Another important thing to remember when going into these collaborative meetings is to prepare your high-level questions in advance. Logistically, you need to be aware if system interactions have changed or if desired outputs are going to vary. However, when it comes to the low-level details of how to change your task approach, make sure that you have some progress or simple examples mapped out before taking feedback. This makes it easier for collaborators to analyze and criticize something concrete instead of getting lost in the hypothetical.
Early on in my internship, the number of opinions was overwhelming and I felt pressure to incorporate every suggestion I received. Over time, I realized collaboration in this setting does not mean giving up ownership over your work. It means learning how to absorb feedback, identify recurring concerns, and make informed decisions without losing direction. Working with so many teams forced me to manage expectations and be more intentional with the meetings I would schedule with people. I think in graduate school, we’re often trained to define the problem clearly before solving it. However, in a large systems engineering project where things are rapidly evolving, sometimes part of your job involves navigating uncertainty and continuing to make progress while direction, priorities, and even the problem itself are still being worked out. For me specifically, I found it more efficient to first outline a bare-bones architecture of my algorithm and get a single model working. This made it easier to then clearly point out potential areas for expansion at meetings within a predefined list. This way, I could poll what people thought and at least have a starting point from which to build upon.
Looking back, this experience completely changed how I think about engineering research. Technical ability is still important, but large-scale engineering projects also require adaptability, communication, and the ability to make progress even when not every variable is fully defined. While the transition from independent research to systems-level collaboration was overwhelming at times, it ultimately taught me how much engineering depends not just on solving problems, but on learning how to solve them alongside many different teams, constraints, and perspectives.