When I arrived at the University of Michigan, I wanted to take advantage of the opportunity to work across disciplines. Conversations with students in naval architecture, electrical engineering, and mechanical engineering introduced me to ideas that felt almost like magic. Their fields were so different from computer science, yet we were all learning alongside one another. I wanted to collaborate with people whose knowledge could help us build something beyond what any of us could create alone.
I found that opportunity at a school fair, where I met members of the Michigan Autonomous Security Team. It was a small group, made up largely of graduate students, exploring how drones could protect public spaces such as airports from drone threats. The project caught my attention because it brought software into a field I knew little about. I attended a meeting and soon became involved.
The team had formed only a semester before I joined, so much of our first year involved building its foundations. We prototyped ideas, set up computers, learned to use simulators, and worked with the graduate students who had started the project. For me, that meant stepping outside the software environments I already understood and beginning to learn how aircraft fly and how software interacts with physical systems.
I built my first PID controller, explored aerospace physics, learned to work with Gazebo, PX4, and ROS 2, and installed my first Linux distribution. I also gained my first experiences using Git in a collaborative engineering setting. Each new tool gave me another way to contribute, but learning to work in an unfamiliar field mattered just as much. I had to ask questions, learn from teammates, and connect my programming experience to problems I had never encountered before.
As I took on more responsibility, I became the software lead. When the founding graduate students completed their degrees and moved on, only a few of us remained. I eventually stepped into the role of chief engineer. The transition changed what the team needed from me. Alongside contributing technical work, I needed to help us establish direction and give other members room to take ownership.
For the following year, I asked a close friend to take on software engineering responsibilities. I knew he was resourceful and capable of learning as he went, and I believed he could really make a positive impact. Trusting him with that work allowed me to focus more broadly on the team. It also helped me understand delegation as a way to support someone else’s development while making better use of our combined abilities.
As my friends and I took responsibility for the club, we wanted a clearer goal to organize our efforts. Our earlier work on drone interception had given us room to experiment, but we wanted a defined challenge with requirements and milestones. In Michigan Honors, we often discuss SMART goals: goals that are specific, measurable, achievable, relevant, and time-bound. I saw an opportunity to apply that framework to our team.
We chose to pursue the SUAS competition. We saw its mission-oriented challenges as a way to connect our interest in security with rescue applications while giving the team a shared objective. A competition provided a concrete target around which we could organize our learning and design decisions.
With only five or six members, we approached the work much like a startup. Each person had a foundational role, and our different experience levels meant that everyone had something to teach and something to learn. We wanted to build an aircraft together, and that shared ambition helped us take on work that would have felt out of reach individually.
Our proposed approach placed software at the center of the design. We wanted to develop an efficient software stack alongside a compact fixed-wing aircraft designed for aerodynamic efficiency. We wanted the aircraft and its software to support the same mission, with decisions in each area informing the other. We are currently in the Preliminary Design Review stage, working through our proposed design.
Leading this effort has challenged me because my background is in software engineering, and I am still developing my aerospace knowledge. I have learned to turn to teammates whose coursework and experience give them a stronger understanding of a particular problem. I can contribute by asking useful questions, connecting their knowledge to the broader project, and helping them take ownership of decisions in their areas of expertise.
This has changed how I think about leadership. When a technical question arises, I consider both who can address it and who can help others understand it. A teammate’s expertise can solve an immediate problem while also strengthening the team’s ability to handle the next one. Coordinating that exchange has become an important part of my role as chief engineer. It requires me to communicate across disciplines, recognize the limits of my own knowledge, and trust the people around me.
The relationships we have built matter just as much to me as the technical work. Working toward an ambitious goal with close friends has shown me how a small team can develop a shared sense of purpose. It has also helped me discover how much I enjoy the uncertainty and responsibility of building something from its earliest stages.
I carry those lessons into my work on Knack Strength, my fitness app, and into professional experiences such as my internship at Common Vector Robotics. I enjoy bringing people with different strengths together, giving an ambitious idea a clearer direction, and helping a team make progress toward it. The Michigan Autonomous Security Team helped me recognize that interest in myself. I joined because I wanted to learn from people in other disciplines; I am growing into a leader who can help those people build something together.
