Postmortem: My First Design Team Experience

Edit: I originally stated that “WARG’s repository contained predominantly CRLF files”, which was incorrect. Only a few files contained CRLF whereas most files were in LF.

In the University of Waterloo’s Faculty of Engineering, design teams offer students the opportunity to collaborate on exciting projects—from drones to rockets to ASIC design. After attending the design team fair in early September, I joined the Waterloo Aerial Robotics Group (WARG) with enthusiasm and high expectations. The team members were welcoming, the leaders supportive, and I successfully completed bootcamp to become a full member. Yet after nearly two months, I made the difficult decision to leave.

This isn’t a story about interpersonal conflict or team dysfunction. Rather, it’s a reflection on technical philosophy misalignment and what happens when different engineering cultures collide.

The Technical Challenge

WARG’s embedded flight software (EFS) team uses STM32 microcontrollers for their drone projects, with STM32CubeIDE as their development environment. My initial task seemed straightforward: implement a new error handling standard that would improve code reliability by returning error codes and using pointers for computed values—a common pattern in systems programming.

However, I immediately hit a roadblock. The project wouldn’t build on my macOS system due to CRLF line ending issues—a classic cross-platform compatibility problem. Unable to compile and verify my work locally, I found myself in an inefficient workflow that hindered meaningful contribution.

I proposed migrating the project to CMake with the STM32Cube VSCode extension, submitting several pull requests to address these issues. While one EFS team leader expressed interest and said they would review my solution, the proposal didn’t move forward as the team leadership preferred to maintain STM32CubeIDE. The team leadership prioritized maintaining STM32CubeIDE for its beginner-friendliness, despite the technical advantages of a pure CMake approach.

The Deeper Divide

The build system disagreement revealed a fundamental philosophical difference. WARG employed a hybrid approach—building their flight software as a static library with CMake, then linking it to STM32CubeIDE output. This setup, while functional for Windows users who comprised the majority of the team, created significant friction for Unix-like systems.

The CRLF issue exemplified this Windows-centric workflow. While most cross-platform teams standardize on LF line endings with proper git configuration, WARG’s repository contained predominantly CRLF files. Converting them would have disrupted ongoing work and required team-wide coordination—a battle I recognized wasn’t worth fighting.1

What troubled me more was the response to technical issues. When I reported missing execution permissions on build scripts, one team leader insisted the problem didn’t exist on their system, even after I provided git commit evidence. This interaction highlighted a cultural mismatch that went beyond technical preferences.

A Tale of Two Cultures

My background in open source development, particularly with the FreeBSD project, had shaped my expectations. In that environment, code review is rigorous, contributors obsess over code quality, and technical decisions emerge through consensus and merit. Open-mindedness isn’t just encouraged—it’s essential when confronting unfamiliar concepts.

WARG operated more like a traditional organization, with leadership making top-down decisions and members focusing on assigned tasks. This structure makes perfect sense for a student design team that needs to onboard beginners efficiently and achieve concrete goals with limited resources. It simply wasn’t the collaborative, discussion-driven environment I had grown accustomed to.

Moving Forward

Leaving WARG wasn’t a failure—it was a learning experience about the importance of cultural fit in technical teams. The team members and leaders were genuinely helpful throughout my time there, and I’m grateful for their patience and support. We simply had incompatible visions for how engineering work should be conducted.

My immediate focus returns to academic work and my contributions to the CHERI Alliance, where I’m preparing research for the CHERI Blossom Conference 2026. Looking ahead, I’m planning to join UWASIC to study processor design—knowledge that will prove invaluable for my work on RISC-V systems with CHERI capabilities and potential contributions to projects like lowRISC ibex or OpenTitan.

This experience taught me that technical skills alone don’t determine team success. Understanding and aligning with a team’s culture, workflow, and decision-making processes is equally crucial. While WARG and I weren’t the right match, I’m grateful for the perspective this experience provided on how different engineering teams operate beyond the open source world.

Sometimes the most professional decision is recognizing when to step away—not because something is wrong, but because the fit isn’t right. That’s the most important lesson from my first design team experience.