Reflecting on UBC Solar

Background

UBC Solar has been the most important aspect of my life over the past four years. Having recently stepped down from the team after our success at competition this July, I’ve been collecting my thoughts on my experience as a team member (Jan 2021-April 2022), subteam lead (May 2022-Dec 2022), and executive (Jan 2023-Aug 2024). It’s important to me that such a monumentally impactful experience such as this one continues to compound it’s influence, and part of that process is a reflection on my experience on the team.

Aside from a brief introduction to UBC Solar, I’ll mostly be talking about my experience building a world-class solar racing design team as Electrical Lead.

My Introduction to UBC Solar

The first week after moving into residence at Orchard Commons, someone named Serhii put a message in a WhatsApp group chat asking if anyone wanted to grab dinner in the dining hall that night. My roommate and I read the message, shrugged, and typed “let’s meet up.” At the time, I had no idea that Serhii would go on to be the Captain of UBC Solar while I was Electrical Lead, nor that he would become one of my best friends in the process.

Serhii (R) and I in Kentucky in July 2024, almost four years after we first joined the team

Entering my first year of Engineering at UBC in 2020, I knew I wanted to join a design team. At the time, I was a curious individual passionate about technology (as I still am), and wanted to get an early start on improving my hands-on technical skills while giving a boost to my resume, which I knew would come in handy when applying for internships.

Serhii is the smartest, most motivated, and driven individual I know, and being a car guy, it was no surprise that he gravitated towards Formula E, Formula Gas, and UBC Solar when looking for design teams to apply to. At the time, I wasn’t sure whether I could handle a first year engineering course load while being on a design team, so I ended up only applying to UAS, and while I was interviewed, they’d already filled up all the new recruit spots on their team. Serhii was accepted onto UBC Solar in September 2020, while I later applied and was accepted onto the team in January 2021.

L-R: The Formula Gas, Baja, and Formula E engineering design teams at UBC

Entering the discord call for the 10AM general meeting on the second Saturday of January, I felt that I’d entered a world of the most driven engineering students on campus. I knew I needed to hit the ground running in terms of my dedication, motivation, and contributions to the team. Initially unmatched to a subteam, I nervously entered different voice channels, introducing myself to that subteam, and trying to get more insight into their responsibilities. Joining the BMS channel, I quickly knew that I’d found my subteam. Everyone had their cameras on, and Blake (who’d become the future Captain), and Andrew (the subteam lead) were extremely warm in welcoming a nervous new first year.

At that moment, I’d become a part of UBC Solar, little realizing that I’d embarked on a journey which will continue to impact me for the rest of my life.

A Primer on Solar Racing

UBC Solar is an engineering design team at the University of British Columbia that designs, builds, and races solar powered vehicles. The team is made up of ~30-60 active members (depending on the time of year) ranging from first year engineers to masters students. We accept folks from all backgrounds (including arts and business) regardless of technical experience - all we ask for is a drive to learn and motivation to work hard.

The team competes in two races, the Formula Sun Grand Prix (FSGP), an annual three-day track race, and the American Solar Challenge (ASC) - a biannual cross-country road race taking place on public highways over five days. Every second year’s FSGP is a qualifier for that year’s ASC - a team needs to get a certain number of laps over one or two days on the track in order to qualify to race in ASC. Usually, there’s about 20-30 teams competing in FSGP, with around 10 making it through to ASC.

Solar racing isn’t an activity confined to North America - in fact, it’s a global community. Some of the top teams in the world come from everywhere from the Netherlands to Japan, and race in the toughest competitions around - namely, the World Solar Challenge - the equivalent of ASC but through the outback of Australia - and the South African Solar Challenge.

*The Youtuber Veritasium hosted a documentary series on the 2019 World Solar Challenge*

Building a Technical Team

Prior to stepping into my role as Electrical Lead, Serhii (Captain), Liam (Mechanical Lead) and I had met several times to discuss the team’s biggest challenges. While many organizational and motivational issues were raised, we first had to formalize a clear technical vision for the different subsystems the car required to both comply with competition regulations and be competitive in a race. After all, you can’t build a crack team if their purpose isn’t structured around concretely-defined problems.

The two biggest technical challenges our team faced at the time were a lack of requirements, and an abundance of grandfathered assumptions from the team’s previous car, Daybreak.

Question Your Assumptions

The Issue

Brightside, the 2024 car, began design prior to Daybreak racing in 2022. When the team moved online during COVID, they weren’t able to go in-person to work on Daybreak, and so began designing Brightside before aspects of Daybreak’s design were complete (let alone having learnt from the lessons of racing the car at competition). This lead to assumptions about what to re-design and what to keep, which started Brightside’s systems off on the back foot.

The thought process of “the only thing we can do online is design something new” lead the team to take on many non-critical-path projects that lacked any technical requirements, apart from the goal of keeping members busy until in-person work resumed. Additionally, may critical-path projects for Brightside, such as the chassis roll cage, also started with a lack of requirements, causing designers to move forward with unchecked assumptions related to space constraints and material properties.

Case Study: Reactive Suspension Design

Not questioning assumptions caused significant issues for Brightside’s suspension design - the Vehicle Dynamics (VDX) subteam kept designing based off assumptions about other subsystems, such as the chassis structure, while those designs themselves were in the process of being redesigned. This caused the suspension design to take three times as long as it should’ve, with multiple iterations of design being scrapped when the designer reacted to changes from the chassis team.

Another less obvious assumption which caused significant stress prior to competition was the vehicle’s custom wheel rims not taking into account the height of the BLDC motor’s coil windings. This required the team to machine off a bit of the wheel rim and re-do days of FEA - the results of which would make-or-break the team’s chances of competing. The height of these windings wasn’t included in the manufacturer’s CAD, however, the assumption that the CAD was correct could’ve been overcome by taking dimensions from the physical motor, which had been purchased and sitting the bay for over a year prior to the wheel rims completing design.

These issues lead to suspension being the critical path during integration of the car’s subsystems, with the VDX team pulling all-nighters to finish design and machine components right up until the night before competition.

Brightside’s final suspension design, assembled less than a month before competition

The Solution

The executive team decided to formalize our process of “questioning assumptions” with a section in our newly-created DR Documents. This forced the project owner and lead to brainstorm, discuss, and explicitly write down all of their assumptions for the project at each stage of the design cycle - from inception to the last design review prior to project completion.

Reflecting on the assumptions you’re making about a project’s scope and requirements is a skill, and a crucial step in the design process. Even if an assumption seems obvious, note it down - assumptions give visibility on project risks that would otherwise go overlooked. An easy example of an assumption would be anything that you’ve taken from someone else’s design, for example, transferring a system from Daybreak to Brightside (you’re assuming they’ve done that portion of the work correctly).

• *From a wiki page I wrote on the team’s design review process.

The assumptions written down in a DR document could be based on the project’s purpose (ex. strategy assumes they’ll need IMU data to characterize the forces acting on the car in turns), requirements (ex. assuming the IMU needs to be sampled at 10Hz - this could be revisited once strategy determines whether this data rate is necessary), or past (ex. assuming we need an LCD screen on the dashboard since that’s how it was done on Daybreak). This last point was especially important; whenever someone said “that’s how it was done on Daybreak”, this signaled a major red flag that would halt all project progress while a deep-dive was conducted on that assumption.

After the DR Documents were formalized as team procedure by the executive team, I made it a priority for the electrical subteam leads to complete a DR0 document for every existing project, regardless of its level of completion. In doing so, we raised and questioned assumptions about project timelines and priorities, leading to increased focus on projects that we needed for competition, vs. “research projects” that were holdovers from COVID.

I also focused the team on questioning assumptions about project scope, leading to members making a common remark that brought a grin to my face every time I heard it - “I didn’t realize we were responsible for that”. Questioning our assumptions lead us to fill the communication gaps between cross-subteam projects, resulting in less “surprises” as we built up increasingly granular timelines.

Case Study: “Proactive” Drive System PCBs

I realized after becoming Electrical Lead that there were several low voltage drive system PCBs that had been designed based off numerous non-verbalized assumptions (along with a lack of requirements). One of these boards was the steering wheel, for which I oversaw the PCB layout and routing. After the board was ostensibly completed, a gut feeling held me back from ordering it. Writing down assumptions we’d made about the project, I realized that we’d assumed the PCB shape based on Daybreak’s design, without any consideration to Brightside’s steering wheel’s mechanical form factor.

Brightside’s v1 STR PCB

When the member who’d previously been working on v1 of the project left the team, we assigned a new member to the project and started v2 from scratch (DR0). We began by connecting the new project owner on the electrical side to the mechanical designer, and made sure they were continually collaborating on the design. The mechanical designer would pass DXFs to his electrical counterpart, who would align components and export a 3D model for mech to validate in CAD. This redesign yielded a transformed v2 steering wheel PCB, featuring an entirely new form factor and button configuration compared to its v1 predecessor. The updated layout seamlessly integrated with the steering wheel, providing drivers with a (mostly) successful ergonomic experience.

Brightside’s v2 STR PCB

This experience made it obvious that it’s ridiculous to design a production PCB without mechanical design collaboration, a tenant which I formalized in the team’s procedure for MCAD-ECAD Collaboration.

Another key assumption questioned on the steering wheel PCB was the addition of a “regen paddle”, similar to those in consumer electric vehicles. This was initially a requirement for the project, however, I felt we didn’t have convincing evidence for why it was needed. A personal mantra was “question your requirements, this will lead you to your assumptions - then questioning your assumptions will lead you to refining your requirements” - I applied this during meetings in which the PAS and EMBD teams questioned fundamental assumptions and requirements related to how the entire regen system would be implemented on the car. Eventually the electrical subteams decided that the driver didn’t need to control the motor’s regen percentage - regen would either be fully on (during normal driving conditions), or fully off (for scrutineering). This lead us to scrap the regen paddle, simplifying both the electrical and mechanical design of the steering wheel.

Areas for Improvement

Unfortunately, I didn’t proactively question assumptions on all the drive system PCBs. The DID (dashboard) ended up with spurious LEDs left over from Daybreak’s design - why the driver would need to see whether the motor was in an over-temperature fault state wasn’t an assumption I questioned.

As a result, the DID was larger than needed, and missed an important LED for indicating when the ESTOP was pressed. I identified these assumptions after 2024 competition, and relayed them to the new Electrical Lead.

Connecting to Other Design Processes

Recently reading a book on sustainable building practices written by the founders of the US Green Building Council, I was extremely pleased to see many of their recommendations for integrative design mirrored in my approach to building an effective technical team at UBC Solar. Specifically, on page 34, the authors present an example of collaboration between an architect and mechanical engineer:

The second lesson addresses the question of why the architect had put the mechanical equipment in a penthouse on the roof in the first place. When asked this question, the architect replied, “because that’s what we did on the last project - it’s what we’ve always done,“… In order to produce a project that was much more efficient, in terms of not only operations but also initial construction cost, a willingness to question assumptions was needed. - 7group, Bill Reed - The Integrative Design guide to Green Building

Requirements Drive Engineering Decisions

The Issue

The most valuable lesson I learned in first year engineering was the difference between a project’s requirements and ‘nice-to-haves.’ This clarity only came after watching projects drift aimlessly in their final stages, victims of unclear boundaries between requirements and stretch goals. Clear priorities from the start would have helped us know when we’d actually succeeded in finishing a project.

Another way to envision a collection of requirements is asking “what does done look like?” - a powerful question that I was faced with each time I dug into an electrical subteam’s projects at the beginning of my leadership.

Not having an idea of what “done” looks like demotivates designers and corrodes the team’s timelines and priorities as projects in unknown states of completion drag out over years. Not proactively thinking of requirements at a project’s inception causes costly, stressful, reactionary decisions further along in design, as teams realize they neglected to implement key functionality and were forced to backtrack, or worse, start from scratch.

The Solution

Just like the formalization of “questioning assumptions” in the DR documents, we also used those documents to formalize the process of requirement capture. Before diving into design, I worked with leads and members to spend more time on requirement building and ideation, interfacing with other stakeholders to more concretely define the problem and solution space.

This concept of “front-loading ideation” as opposed to “immediately kicking off design” resulted in huge successes for the electrical team, primarily in the form of scope reduction. Intentionally thinking about the minimum a project needed to accomplish allowed us to make more realistic timelines, reduce design work, and create flexible, debuggable systems.

Sidebar: What Are Requirements?

I explicitly defined “requirements” in the Design Review wiki page, some highlights of which are expressed below.

Solar’s “requirements” are defined in the same way as ASPC 100’s - the minimum features the design must implement or accomplish. The key word here is minimum. A project must be created to accomplish a specific goal - the requirements are the breakdown of that goal into quantifiable metrics. Those metrics represent the minimum viable product (MVP). Anything beyond these requirements are stretch goals, and are not necessary for the project to succeed.

ex. The project is a GUI to monitor the battery’s voltages. The requirement is that the update rate of the GUI’s graphs is 1Hz. Would it be nice to have 5, 10, 100Hz? Yes. Is it necessary for the MVP? No.

Building on our definition of requirements, a requirement is a PASS / FAIL object. If one requirement in the project is not met, the project is incomplete. This means each requirement must have a metric for success (requirements must be quantitative). For example, you’d like a specific refresh rate, a specific safety factor, or a specific maximum temperature. The sum of these requirements answers the question of “what does done look like”.

Vague Requirements	Quantitative Requirements
Safely implement cruise control firmware	Implement cruise control firmware that responds within 1s of the driver’s activation, and turns off whenever the accelerator or brake pedals are pressed
Send messages on the CAN bus	Send CAN messages 0x501, 0x503 at 100Hz to the motor controller on a 500kbit bus
Driver must be able to see through windshield	Driver must be able to see a cone 2m in front and 30 degrees below the nose of the car

Requirements should not include implementation details. For example, it’s not required you use a certain steel alloy for the chassis, whereas it is required you achieve a specific safety factor. Even if you’re certain you’ll use a specific alloy to achieve that safety factor, save those implementation concepts and details for DR1. Separation of requirements and implementation is essential - the more well defined the requirement, easier it’ll be to create a successful implementation.

Case Study: Distribution Board

The first time I considered a project’s requirements was when planning for the Distribution Board project as BMS lead. As a lead, I found it difficult to wrap my head around requirement capture without a framework I could refer back to (this was before the DR Documents had been created). I remember sitting down with the Elec Lead at the time and listening to him suggest - what seemed to me - wilder and wilder ideas of how to implement LV system fusing. After a point, I stopped him, and said “but what does this board need to do?”

For the first time, I realized it was up to me as an engineer to craft a concrete vision for what this board needed to accomplish and justify why I thought that to be the case. I could add as many bells and whistles as I wanted, or I could strip it down to the bone, but it was all under my control. The only way my mind could manage this responsibility was to come up with quantitative requirements, such as current-carrying capacity for power rails, fusing requirements for LVS boards, and visibility of LED indicators.

Left: Final Distribution Board design. Right: Design I inherited as the new BMS Lead

That said, I still failed at capturing several project requirements. As a BMS member worked on the board, I was constantly thinking of items that needed to be added, from the board’s orientation relative to the ECU it connected to, to the types of connectors necessary for the LV systems - exhibiting reactive, not proactive design habits.

Overall, we probably had ten DRs for this project when we should’ve only have three to four. I actually ended up finishing the project at the last-minute because I was unable to clearly communicate my requirements, something which demotivated the designer and robbed them of an opportunity to learn and own the project to completion.

The assembled Distribution Board at the top of the pack

Case Study: Telemetry MVP vs. MMR

The biggest challenge facing the electrical team coming out of UBC Solar’s first race with Daybreak in 2022 was the lack of a wireless telemetry system, for both viewing real-time CAN bus data for debugging purposes, and for collecting data to inform race strategy. The team was also beginning to realize that the ability to store data was essential in pushing the team towards a more data-driven design approach for future cars.

A telemetry system had been in development before Daybreak’s race, but failed deployment during the race. I knew that for Brightside to succeed, we needed a 100% reliable, robust, and requirement-driven telemetry system.

With a tech stack of RF hardware, off-the-shelf components, embedded firmware and a RESTful API, significant development and testing time needed to be allocated to this project, an understanding which lead me to focus embedded stakeholders on the system’s minimum requirements. To begin building this mindset, I introduced the foundational vocabulary of “minimum viable product” (MVP) vs. “minimal marketable product” (MMR).

Vocabulary Alignment

I picked up this language in the summer of 2023 when working at Sanctuary AI. In the thick of a Series B fundraising round, the company had no room for product features that didn’t align with their MVP of demonstrating a stable, reliable system during investor demos.

Pausing design and backtracking to build a shared vision for the project’s MVP and MMR was an essential step in crystalizing the requirements we’d drive to complete for competition. This step also informed our timelines and member allocations, while preserving ideas for future optimizations and cleanup as MMR milestones.

This focus on building a 100% reliable MVP immediately lead the Embedded lead and I to some enlightening conclusions, such as agreeing that the primary purpose of the telemetry system was to collect data for race strategy, with the secondary purpose being real-time data viewing. This meant the development of the SD logging system was the top priority, and not, as we’d previously assumed, the RF or RESTful system components. In the interest of further reducing scope by ranking priorities, we realized that since we’d mostly have line-of-sight with the car at FSGP (and would certainly at ASC), we decided to focus solely on transmitting data over a 900MHz link and pause development of all cellular-system-related components.

Focusing on RF Comms

After becoming electrical lead, many of the embedded team’s discussions were focused on the interleaving of cellular data with radio data to create a redundant system. However, considering that no development had gone into the cellular system combined with the need for a system that worked at all prior (before focusing on a redundant system), reducing scope to solely the radio link allowed us to achieve our goal of a robust, zero-downtime system that in practice, worked about 95% of the time.

A final important discovery was that, with minor changes to Sunlink - the existing receiver data collection software stack - we could add the ability to collect data from a computer plugged directly into a CAN bus, unlocking real-time Grafana-based debugging while in the shop or out around campus. Crucially, this enabled BMS to monitor and log data from the battery pack without needing to develop their own GUI, striking off a major project from BMS’s list of responsibilities.

After explicitly defining the project’s MVP, the embedded team came up with the following project requirements for the telemetry system:

• Millisecond timestamps for all data that will be on the CAN bus at 2024 comp
• 1s max latency from data arriving at the TEL PCB to remote visualization
• It should take no longer than 10 minutes to freshly spin up the collection and visualization system on any member’s computer
• Collect and visualize data from either an RF or direct-CAN connection path
• Capability to upload logs to the remote database from an SD card
• Ability to receive data from the car over a radio module at a max distance of 0.5km

At this point, the embedded lead, the other subteam leads, and the embedded members were all aligned on exactly what problem the telemetry system project was there to solve along with the project’s associated requirements.

The Importance of Front-Loading Design

The benefits of clearly defining the telemetry system’s purpose and requirements at inception compounded throughout the project. Immediately after defining transmission requirements, a high-priority, joint PAS-EMBD project was initiated to characterize our existing radio hardware. This was the result of questioning whether the assumption (raised in the DR0 document) that the radio module chosen for Daybreak would meet our newly-defined bandwidth requirements was true.

Success

This project ended up validating that our RF systems could, in fact, meet our range and bandwidth requirements, while also increasing collaboration between PAS and EMBD. This project grew the team’s awareness around the necessity of early prototyping and system modelling, while building good member habits of thoroughly developing, executing, and documenting a test plan of this scale.

As development and testing of the telemetry system progressed into April 2024, the embedded team came to two key realizations, namely that the SD logger’s firmware was behaving inconsistently, causing data to be wiped from storage, and that the GPS module didn’t provide millisecond timestamps, meaning we’d need to write algorithms interfacing with the MCUs clocks to meet this requirement. The team struggled with both of these issues through the month of April, and I kept an eye on our timelines, specifically the fact that full systems integration and on-car testing were set to start mid-May.

Considering solutions to these issues, I went back to the project’s requirements. Nowhere was it written that we needed to develop a custom SD logging firmware, nor that we needed to use a GPS module to provide millisecond timestamps. All we needed to do was somehow get millisecond timestamps, and somehow log data to an SD card, for the purpose of providing Race Strategy with vital data pre- and post-comp.

After this realization, I quickly opened up the website of Phytools, a UBC Solar sponsor who’d previously donated some CAN-USB dongles to the team, and searched for “CAN bus data logging systems”. A week later, I’d secured a sponsorship for the Kvaser Memorator Pro, a fully-featured CAN logging device that also had a real-time clock (RTC) which, in combination with the device’s CAN API, could be used to send millisecond timestamps which the TEL board could consume. The embedded team made quick work of programming the device to do just this, and refactored our existing scripts for uploading SD card logs to our database to fit the formatting of the Memorator’s logs.

In the past, the team assumed that everything needed to be done ourselves. However, my push to focus the team on requirements over design, combined with questioning assumptions, lead to our ability to pivot quickly to a more robust solution that allowed us to achieve our timelines and be 100% certain that all data would be logged for future analysis.

Monitoring Brightside’s live telemetry in the chase car on the highway outside of Nashville

Purdue’s Telemetry System

At competition, you could separate competitors from novices by seeing whether a team had the mindset of “building a 100% reliable MVP”.

On the last day of FSGP while our car was racing on the track, I was chatting with the Electrical Lead of Purdue’s Solar team and asked him about their telemetry system. He proudly began talking about how he’d spent months optimizing the machine code of their firmware, and how their system included a Raspberry Pi they could wirelessly SSH into to flash code onto their car’s CAN bootloader. I was very impressed, and asked if I could see how the live data looked on their graphs. “Well, I can’t show you” he said, “our telemetry isn’t working right now”.

This isn’t to say that Purdue isn’t a competitive team - they had the lightest monocoque out of all the teams, and did extremely well for a first time team in both FSGP and ASC. However, when designing their next car, they’ll be making decisions without the benefit of historical race performance data.

TLDR

As Dylan Gunn, one of the directors of the Engineering Physics project lab likes to say, “Love the problem, not the solution”.

Building Team Frameworks

For improvements in the engineering design cycle to be effective - especially in “questioning assumptions” and “defining requirements” - it’s essential to have cohesive, intentional frameworks supporting these practices. Technical procedures, no matter how detailed and well-documented, are ineffective if they’re not ingrained in the team’s consciousness, or if ten team members are scrambling to manage the workload of forty.

The Issue

All design teams struggled during COVID. However, even after UBC Solar returned to in-person work, there were fundamental problems that caused us to nearly miss racing at FSGP 2022; problems that the new executive team needed to address if we wanted to design and build a solar car that would race in less than two years.

Prior to January 2023, Solar had a high rate of member turnover - demotivated by unclear timelines, inconsistent project follow-through by leads, and a perceived lack of technical experience, members would leave the team for internships and rarely return. Additionally, there wasn’t a team culture of members taking initiative or being proactive with projects, unless we were lucky enough to have a member join the team who was already extremely motivated and willing to bootstrap their progress. Generally, members would join the team, become demotivated with their progress and learning as they were neither pushed nor taught, and then float around making little progress on random projects until they left the team all together.

As new executives riding on the energy of a first-time successful race in 2022, we needed to level up UBC Solar from an organization of a few cracked individuals reacting to problems, to a cracked team that would proactively chart the course of solar vehicle engineering for generations to come.

Scaffolding a Team’s Success

While brainstorming effective frameworks that would set the team up for technical and organizational success, I reflected on where I excelled as a member and where I would’ve liked additional support. As well, I considered what it would look like as a lead to build a team I wanted to work with.

During the summer of 2023, I remember walking home with Serhii and talking about what our mission as leads should be. We were both concerned with how the team would fare once we’d left after competition in 2024. As we neared the end of our walk, Serhii said, “As a lead, my goal isn’t to build a single solar powered race car - it’s to build a team that can continue to build solar powered race cars years into the future”. This thought catalyzed a shift in my leadership mindset from building a car to building a team that can build a car.

• I later reflected that this focus on the potential for team empowerment over problem solving is the key to differentiating Managers vs. Leaders.

My strategy to strengthen the team focused on building out a scaffolding of project management frameworks that would serve as the structure around which team members could grow their ideas.

UBC Solar roaring our team chant each morning of FSGP 2024

A Callback to Teaching

The reason I decided to focus so heavily on creating structures for the team was that, as BMS lead, I felt I’d done a poor job of setting my members up for success, the importance of which I’d internalized from two of my own previous life experiences.

Working as a Tutor

I’ve worked as a tutor for various organizations from the time I was 16. In my experience, there’s one thing that differentiates a good tutor from a bad one, and that’s the way they give students the necessary tools to solve their problems.

A basic example is teaching a grade 10 student about linear equations. Instead of flipping open their workbook and starting to solve problem 1, I’ll start by building up general mental frameworks around graphing and visualizing lines. I’ll bring students over to the building’s stairwell for a lesson about “rise over run”, and we’ll open up Desmos and play around with sliders to see what happens when we change one value in the equation. After this, I’ll begin with a basic problem, and dig deeper into its solution using vocabulary from the textbook.

This is an example of setting a student up for success by creating mental frameworks around which they can structure their knowledge about a topic - the next time they encounter a question asking them to find the slope of a line, they’ll think back to the stairs analogy.

Working with Jonathan Thomas

Jonathan Thomas was my manager at Ciena, where I worked from January 2022 to April 2022 as an electrical hardware co-op.

Jonathan’s philosophy as a manager was powerful in its simplicity - “I set them up, and you knock them down”. Jonathan was excellent at reacting to problems (chip shortages) and breaking them down into appropriately-scoped tasks for a second-year engineering student while providing ample opportunities for feedback and learning that grew not only my technical skills, but also my communication abilities and confidence as an engineer.

Leading Up

Calling back to the idea of “building a team that can build generations of solar powered cars”, I knew it wouldn’t be good enough to only create frameworks I could use to leverage the team’s energy - I’d have to instill members and leads with a feeling of ownership over these frameworks. Essentially, these frameworks needed to be useful and intuitive enough that members would actively want to use them - and not just because their manager told them to. This would foster a more proactive team where responsibility for success is owned equally by members and leads, distributing ownership and initiative throughout the organization rather than concentrating it at the executive level.

To create this sense of collective ownership over the team’s success, I focused on encouraging members to “lead up”. I was exposed to this term by Brad, the embedded lead at Sanctuary AI, during a 1-1 at the end of my co-op. Brad said I was good at proactively driving decisions by leading up - presenting managers with a recommended path forward, along with an overview of the methods and data that informed my opinion.

I’d encountered a similar idea at Ciena, where Jonathan emphasized that a team member’s responsibility was to give concise, clear summaries of your results to your manager, directing their attention to key points they’d need to make informed technical decisions. It wasn’t good enough to just collect data and hand it to your manager with no supporting details.

*A presentation I gave to my team’s manager at Ciena which included my recommendations for the project’s next steps

Mental Frameworks for Leading Up

In the summer of 2023, I was the only person propping up the electrical team’s progress, which was an unsustainable situation. Having been Electrical Lead for four months, I’d inventoried all current and future projects and had organized our Monday boards and timelines accordingly, however, there were no technically proficient or motivated members left in-person to begin this work.

Faced with a deficit of first and second year members across the team, in August 2023, the Captain, Mechanical Lead, and I decided to be more intentional than ever before about our recruitment process. Inspired by Formula E’s approach to recruitment, we were more vocale about presenting UBC Solar’s expectations and commitment level to prospective candidates during info sessions and interviews. This statement went along the lines of:

“This is the most challenging experience you’ll ever encounter, but it’s going to be the most impactful experience of your life, and it’s a once in a lifetime opportunity. What you put in to the team is what you get out.”

Intentionally presenting our team as an exciting challenge (as opposed to just another club or design team) brought in one of the strongest batches of new recruits the team had seen, and in October 2023, I put 100% of my focus into applying frameworks that would empower members to output fast-paced, high quality work that required minimal oversight from leads, while at the same time training members to become leads themselves - following the team motto of “recruit your replacement”.

A few of my own mental frameworks that served as guiding principals for the design of the physical project management frameworks I put into effect throughout my time as electrical lead are listed below:

1. “A good lead is like grease” - they get everywhere to support the heavy lifting, but don’t do it directly. This was a quote from Joe at Formula E, and runs parallel to the VP of Engineering at Sanctuary AI stating he was an “empathetic” lead who was in touch with his team’s needs on a daily basis. A team that can lead up should function as a distributed system, without any central node or master, allowing rapid communication between members that can bypass the bottleneck of a lead.

   Getting members to coach other members is key to reducing dependency on leads. As a BMS member in January 2022, I remember sending wiki pages to new recruits to help them get started with learning team standards. Andrew, the BMS lead at the time, appreciated this, and recognized he could let me take on more responsibility on the subteam, eventually leading to me becoming BMS lead in April 2022. This peer tutoring also helps to identify gaps in the coaching member’s knowledge - you only truly understand a subject when you can teach it to someone else.

   One way to encourage this is to have certain members become masters of a subject and have everyone go to them when related questions arise. This encourages the member to deeply learn a subject, and also increases their confidence in answering technical questions and being comfortable as a “point of contact” for team members.

2. Set the challenge for team members to rise to - if you’re not out of your comfort zone, you’re not learning. The easiest and most powerful way to push members while increasing their potential for leading up is to ask “what do you think”? This gets members comfortable driving decision making by increasing their confidence in their own critical thinking abilities. It also encourages them to speak up in the future, which is important for checking others assumptions and sourcing better engineering decisions. Before answering someone’s question, I’d ask whether they’d searched it up, whether they’d asked another member, and whether they’d asked their lead.

   When Krish and Sam (currently the BMS co-leads) joined the team as new members, I knew it was important to make the team’s expectations around “leading up” clear; when they’d ask me a question about the battery’s code or components, I’d say “what do you think?”, “where can you find that information”, or “try asking Tigran (the BMS lead at the time) first”.

3. Vocalize the “why” - it’s essential for members to understand why a decision about something they’re working on is being made. This is how ownership over project and team success is fostered. As a lead, practice a vocal stream of consciousness at all times. For example, when you make a discovery, take a step back and explain the thought process leading up to it to your members. The same goes with if think a proposed solution won’t work - explain why. This goes double for timeline planning, subitem creation, and general milestone/goal setting - any time a decision or change is made about an item owned by someone else, that owner must understand and internalize exactly what happened and why.

   When transitioning out as Electrical Lead, I shared my personal Elec Lead January 2024 Reflection with the rest of the team, vocalizing the why behind my leadership methodology (similar to what I’m doing in this post).

Applying these mental frameworks to project management strategies lead to success with members like Aarjav and Saman, who “lead up” on complicated projects like the telemetry system and array integration. Through their Monday updates, presentations, and questions, I was able to effectively inform their technical decisions at car-wide integration scales while they reduced the need for me to micro-manage day-to-day decisions.

R-L: Kyle (present EMBD co-lead), Evan (present 2nd year EMBD member), and Saman (present Electrical Lead) debugging issues with the telemetry system

Successful Frameworks

Monday

In September 2022, the executive team brought in UBC Solar’s first centralized project management system, Monday.com. At the time, the purpose of integrating Monday into the team’s PM workflow was to enable the creation of a car-wide Gantt chart to improve our ability to maintain timelines.

Initially I was against Monday, wanting to stick with Trello, our simpler project management software. My mindset changed once I realized it was the job of the project manager to make the software work for them, as opposed to being controlled by the software’s constraints or pre-existing templates. I realized how powerful Monday could be as a team framework to help solve common subteam challenges such as:

• Documentation
• Team knowledge transfer
• Formalization and visibility of progress
• Building member’s skills in leading up
• Timelining projects, including subteam integrations

As BMS lead, I dove head-first into organizing the subteam’s Monday board, rapidly iterating on the board’s organizational structure to uncover successful ways of working that I’d later implement across the electrical team. After a month, I’d discovered my love for project management organization, and had become an outspoken champion for using Monday.

A presentation I made to vocalize the Monday standards I wanted the team to own

Documentation and Knowledge Transfer

Documentation is tough task for any technical team, and Solar was no exception. Previously, members wouldn’t document completed projects, and when leaving the team, would take their goldmine of technical notes with them on personal devices. This made knowledge transfer a reactive, last-minute task that was doomed to cause gaps in understanding as one member left and another took over.

I solved this problem with a clear vision - “if you get hit by a bus”, I’d say to members, “any member of your subteam should be able to look at your project in Monday and seamlessly continue working on it after your funeral”.

To accomplish this vision, I encouraged members to continually write summaries of their progress, specifically after meetings where key technical or timeline decisions were made, after they’d done a block of research, and after they’d troubleshooted a problem in the project.

These kinds of updates have always been second nature to me. When working on personal projects, I felt that I needed to track my progress by making weekly updates, writing down solutions to problems, and noting my next steps - including snippets of code or links to useful resources. Confident in the usefulness of this framework, I formalized it and worked to get the rest of the team leads and members to own it.

If members wanted my opinion on a decision, I’d say “send me your Monday update about it,”, refusing to converse further unless I’d seen an update detailing their progress and recommended action items. This successfully built member’s habits of continually reflecting on their project’s progress, and organically tied ongoing documentation to everyday member-lead communications. This preserved key technical decisions for future generations of the team and moved technical notes off member’s PCs and into communal team spaces. Finally, writing Monday updates with recommended action items encouraged members to practice “leading up” by clearly, concisely, and concretely communicating their technical observations and decisions.

Success

Presently, as an advisor on the team, if members ask me about why a decision was made or how a subcircuit works, instead of having to think years back or vocally explain something for the fourth time, I can point them to relevant Monday updates from that project.

Case Study: Summarizing Slack Threads

UBC Solar used the free version of Slack to communicate, meaning all messages past 90 days were blocked from view and search. This caused knowledge to literally be lost - there were many times when I became frustrated after trying to find a message where key decisions were made, only to realize it was too old to be visible.

I consciously began encouraging the electrical team to move their slack conversations from DMs to public channels (thereby increasing visibility to members and leads and allowing everyone to chip in), and then, once a discussion was complete, ensuring members summarized the relevant technical issues and decisions in Monday updates.

This resulted in threads with sometimes 50+ messages being condensed into a single concise Monday update by the project owner which encapsulated key decisions, assumptions, and action items - and wouldn’t disappear after 3 months. The act of summarization also forced the member to practice technical writing, and to understand the relevant/important points of a discussion. There were many times when a member would begin their Monday update but need to come back to ask questions about a point from the Slack thread they realized they hadn’t actually understood.

Case Study: BMS Testing Dashboard

In December 2023, after a lot of hard work by the Battery Mechanical subteam, and some long nights crimping wires after work on my part, the pack’s mechanical and electrical hardware had been assembled - now, it was time to test everything.

Months prior, I knew we’d need a way to document the entire bring-up procedure of the battery for two main reasons: one, to ensure that we’d completely tested the functionality and edge-cases of every subsystem within the pack, and two, to maintain a record of this bring-up for future generations of UBC Solar battery pack designers.

Always thinking of ways to empower members to learn and lead up, I decided to create the “Battery Testing Dashboard”, a space on Monday where members could crowdsource the creation of test cases tickets that could later be completed by any other member.

An archived version of the BMS Testing Dashboard showing completed test cases

The BMS subteam lead would assign members to create certain test cases, for example, to check that the ECU could close all the contactors on the controlboard, or that the slaveboard discharge circuits were all working as intended. The initiating member, following a strict template, would then independently create the test case and gain feedback from their lead - learning how to write detailed, complete test cases for distributed embedded systems. The dashboard included sections for each subsystem of the pack, a countdown to integration deadlines, a leaderboard showing the total number of test cases written by each member, and a tracker showing the percentage of test cases passed. We also included a section for “issue” tickets that could be logged and documented over the pack’s operating lifespan.

Once the pack’s assembly was complete, BMS immediately began checking off test cases, starting with masterboard-slaveboard functionality then moving to ECU-controlboard and integration tests in the months after. This explicit itemization of tests, along with a binary pass/fail status, created momentum for BMS’s progress over several months - this framework made it easy to assign a member to a test case, document design quirks, and understand where the team was in the overall bringup process.

Gamification of Testing

Completing test cases became such an addictively rewarding experience that Tigran (the BMS lead at the time), and I worked all the way through the 2023 winter break, including Christmas and New Years. One day, I remember working on BMS testing from 9AM to 5PM, then quickly showering at the EDC and heading straight to Contact to rave until 1AM.

L-R: Jack, Krish, Sam, and Tigran monitoring the pack’s vitals during a 10A discharge

Overall, over 60 test cases were created and completed by the team, allowing us to flag and fix numerous issues with the pack’s hardware and firmware. This dashboard was instrumental in leading the BMS team to successfully build a pack recognized at FSGP 2024 scrutineering as one of the safest batteries the event officials examined, while providing invaluable hands-on experience for first-year members and preserving the bring-up process for future generations of the team.

Timelines

Solar had always struggled to upkeep and meet timelines - mainly because we’d never had any in the first place - few projects had meaningful timelines related to key milestones or integration deadlines on the car. For the three projects I worked on as a BMS member, the project deadlines kept getting pushed further back as I encountered technical stumbling blocks, leaving me with less and less of a sense of urgency to finish.

Moving With Purpose

When training to be a lifeguard, my NL instructor would tell us to “move with purpose” when responding to an emergency. Upkeeping timelines is the sign of a team moving with purpose.

As mentioned previously, Monday was brought in to help fix our timelines by allowing us to proactively create visible, realistic, priority-driven Gantt charts. Codifying timelines in Monday would also allow future generations of the team to see how long a certain project took and which of its subitems took the longest.

Taking advantage of Monday’s Gantt charts helped the exec team plan the car’s integration timelines years in advance, an activity which back-propagated to better inform major subteam timelines. We called back to these integration deadlines when making critical decisions towards the last six months of the car, such as whether to wrap or paint the car, or to fix the date when full-car driving testing would begin.

To help members hit their project deadlines, the exec team wanted to ensure members owned and felt responsible for their project timeline. We realized that just assigning a member a project with a deadline would inevitably cause them to miss that deadline, as the member would give more priority to items in their life they felt more ownership over.

To evoke this ownership, during the DR0 phase of a project the lead would ask the member, “when do you think you can get this done by?” for the project as a whole, after which they’d break down the project into smaller subitems, each with their own timelines. At the end of this timelining process, the member not only knew the shape of the entire project - from a main deadline to subitem-specific milestones - but also verbally chose those due dates themselves, removing the feeling of being forced into rushing to some arbitrary deadline.

To drive home the importance of achieving subitem deadlines, I repeatedly called back to these timelines during my 1-1s with the elec leads and when talking with members - asking “when’s subitem x due?” every week until a member was able to say the date off the top of their head. When subteam leads would propose additional projects or subitems in response to changing requirements or mistakes, we’d immediately pull up the subteam’s timelines on Monday and ask “what’s the priority and when do you need it done by”?

The last and most important piece of the timeline puzzle was what to do when deadlines needed to be moved. Timelines aren’t static objects - they respond dynamically to internal dependencies, such as the progress of other projects, and external factors like part shortages or shipping delays. That said, I wanted to impress upon the team that moving timelines was a very serious business. I focused on making lots of subitems with their own timelines, allowing the member and lead to clearly see whether a project was on track or not. As project deadlines approached, I’d internally begin to plan for contingences, but externally, I’d push the member and lead harder - reminding them of the deadline along with the other subitems and projects dependent on them achieving this deadline.

Serhii and the entire aeroshell team was an exceptional example of creating week to week (and sometimes day to day) timelines in Monday, and then executing on every single item to create the most expensive and technically complex part of the car right on time for our pre-comp integration deadlines.

Case Study: VDS

When working with leads to create timelines, I made sure they understood the difference between when a project needed to get done vs. when it would be nice to be done. I encouraged them to think about when their project’s progress would block that of another, and to build out their timelines with a member’s learning and growth in mind. Ideally, the project’s timeline would be long enough that a member could acquire as much growth as possible, and at the same time short enough to push them to finish a subsystem required by other parts of the car.

The Vehicle Dynamics Sensors (VDS) project is an instance where I failed to create realistic timelines which caused reactive decision-making and robbed a member of opportunities for growth.

The VDS was a set of PCBs that would acquire shock travel and brake pressure sensor data at speeds of up to 1kHz, and would store that on an SD card for the VDX team to analyze later. This project was very technically challenging - the firmware required fast sensor polling while writing data to an SD card, and the hardware needed to deal with sensitive analog signals running the length of the car.

After getting requirements from the mech team in January 2024, Ben (the PAS lead), Yonji (the member working on the project), and I created subitems and timelines for the project. My understanding of mech’s priority for this system was that it was low, and as such, I decided to bake in lots of learning and documentation time to the timelines. Through this project, Yonji would learn about SPICE simulation, analog transmission theory, and PCB design for the first time, and I wanted her to become an expert in all of them.

This focus on learning lead me to be more relaxed with the timelines being pushed into the future - something I knew from experience would de-energize the project’s progress, but nonetheless neglected to consider. I also failed to consider that pushing the project’s deadlines into the months before competition would prevent leads from consistently checking in on the project and providing advice, as Ben and I would be too busy with competition-related tasks.

That said, into May 2024, Yonji had done an amazing job prototyping a challenging single-ended to differential analog transmission system, and was just beginning work on its schematic design. This was also the first Altium project where we decided to implement a hierarchical schematic design - a standard we wanted to trial and implement on all new electrical PCBs moving forward. However, time for this new standard to be documented and discussed hadn’t been allocated in the project’s already lagging timelines.

The death-blow to the project was when, during a Saturday morning meeting with the Mechanical Lead, he noticed the slow project progress, and wanted to make sure it was going to get done prior to competition, a statement that took me by surprise. After some back and forth, I agreed to complete the system within the month. I took over the schematic design of the main board from Yonji, and finished up design of the AFEs in a couple days. I looped in the embedded folks to begin the project’s firmware development, and held meetings with the VDX and chassis teams to begin enclosure design. However, I still felt certain that this project wasn’t a priority - the suspension system the sensors were supposed to read hadn’t even been installed on the car. A proper test plan and sensor characterization plan wasn’t created, nor had important electrical prototyping been documented and analyzed, and as I continued to work, I knew that the project wasn’t going to be completed. All of the potential for additional learning by setting Yonji up for success was stripped away as I fell back on the “I’ll do it myself” mentality.

Kovin, the manager of the embedded hardware team at Sanctuary AI, introduced me to the term “servant leadership” during one of our 1-1s. When I queried him about his leadership style, his opinion was that the team leader is there to provide any resources the team needs to work at 100% efficiency. If you’re picking up slack for your team by taking on their technical responsibilities or not taking time to give feedback, you’re preventing your team members from getting better - actively robbing them of opportunities to grow.

There were two key places where I should’ve paused to ask questions that would’ve set the project, and Yonji, up for success.

1. At the project’s inception, I should’ve met with the mechanical team to understand their timelines and priorities. We did a great job of collecting technical requirements from the VDX lead, but I didn’t ask any questions related to when they wanted the system done. This lead to them assuming it’d be completed before competition, while I assumed it’d get done after.
2. When the Mechanical Lead said he expected the project to get done before competition, I shouldn’t have reacted with “ok, let’s do it”. I should’ve slowed the conversation down and brought it back to the priorities and timelines of the VDX team and pre-comp integration. Internally, I knew they wouldn’t be able to support the VDS system, as they hadn’t finished the fundamentals for the car to be drive-ready. If I’d proactively voice these concerns - pointing to their timelines as evidence, the project’s deadline could’ve been pushed past competition, allowing Yonji to continue learning and documenting. Furthermore, this would’ve given supporting embedded and mechanical members space to fit the project into their timelines, instead of reacting to me suddenly saying things items to get done “ASAP”.

ASAP is a Destructive Word

The word “ASAP” represents everything that I did poorly at the end of the VDS project. ASAP is a reactive word, and is disrespectful to the priorities and timelines of the person you’re saying it to. If it’s 2AM and you ask me to do something ASAP, do I need to get on a call with you right now? Do I need to rush over to the bay right now?

Using ASAP gives no information about when the task actually needs to be completed, and usually causes it to not be completed in a timely matter, as was the original intention.

Instead, communication should start with “what’s the date you need this done by”, “what’s its priority”, and if needed, “what assumptions did you make when you answered those two questions?“.

DR Documents

Design reviews are a critical part of every engineering team’s decision-making and feedback process. “DRs” had always been present at UBC Solar, but their quality varied from member to member. As a BMS member, I would work hard to prepare for design reviews, which I took as a serious opportunity to gain technical feedback and push the state of completion of my project from one level to the next - however, this approach was taken by few other members.

Codifying the team’s design review standards in wiki pages and the DR Document templates had three primary purposes.

1. To get members to practice thinking like engineers by enforcing requirement-driven designs that had their assumptions thoroughly questioned. The DR documents would serve as a grounding point for future decision making and would track changes in the project’s purpose, assumptions, requirements, regulations, and stakeholders as it moved towards completion.
2. To generate ongoing project documentation. Combined with Monday updates, the project owner and lead would generate the majority of critical project documentation by filling out DR documents over the course of the project’s lifespan.
3. To evoke a sense of ownership in the member leading the project, and create alignment between key project stakeholders on the purpose and progress of the project.

UBC Solar’s Design Review process follows the image below.

DR1, DR2, and DR3 are formatted as more traditional design reviews - concepts are generated, designs are created and iterated, and, once stakeholders agree that a design is finalized, it is released for manufacturing.

We quickly realized that the most important DR was DR0 - so much so that when the DR Document templates were created, I worked with leads to go back and make DR0 documents for most of our ongoing projects at the time.

There are five sections in the DR0 template (also present in the DRx documents):

• Purpose
• Requirements - Requirements Drive Engineering Decisions
• Assumptions - Question Your Assumptions
• Stakeholders - team-wide view of who’s involved in the project
• Regulations - for relevant competition regulations
• Open Questions - documented to ensure they didn’t turn into unwritten assumptions

Each section in the DR0 document was important, however, the section most important to creating alignment between members, leads, and exec, as well as starting the project off with a clear, concrete vision, was the Purpose section.

This section is the first step in encouraging members to own the success of their projects. Without a clear understanding of the problem their project is meant to solve and how it relates to the final car (“Vocalize the Why”), members can’t make effective decisions or conceptualize designs, and won’t feel motivated to dedicate their time and energy to pushing the project to completion.

As a tutor, introducing a concept through new vocabulary is always the first step to building a student’s understanding. When teaching grade 8s about volume and area, the first thing I do is take a piece of paper, have them cut it and fold it into an open-topped box, and then begin to define terms like width, height, area, and volume (as opposed to going straight into formulas and calculations). This builds up an intuitive understanding of the problem and project vision, and gives them vocabulary tied to visualizations of the concepts they’re working with.

Establishing Shared Vocabulary

I was reminded of this concept of quickly gaining alignment by starting a project off with shared vocabulary and vision from Vince, the VP of Engineering at Sanctuary AI.

I asked Vince to sit in on one of the meetings with the leads of the engineering teams to talk about the company’s 10 year goals. Arriving early, I watched as Vince brought out a whiteboard and began writing down phrases and key points. Throughout the meeting, he’d use these phrases as grounding points, referring back to them whenever discussions got heated or derailed.

Vince translated his vision into clear vocabulary that he encouraged the rest of the company’s leads to use from the meeting’s inception, focusing discussions and creating alignment on a conceptually large topic.

Design reviews were intended to be structured in a way that encouraged members to lead up by putting most of the project management onus on them. Members were responsible for charting the path of their project by documenting the design process, scheduling future design reviews with leads and appropriate stakeholders, and for initiating discussions with other subteams when necessary.

Case Study: Alex Ezzat

Encouraging members to lead the design process was an area where I could’ve been more of a hard-ass. As a first-year member, I took design reviews extremely seriously, a mindset that was a function of Alex Ezzat’s (the previous Captain and general legend) extremely high standards.

Alex’s central tenant was that guessing and engineering are mutually exclusive. An designer must present a reasoned, data-driven argument as to why they think a course of action should be taken. Alex was the first person who showed me what it was like to think like an engineer. He emphasized doing quick back-of-napkin calculations guided by first-principals thinking to quantify decision making - no design aspect was too small to be arbitrarily decided.

One example of Alex’s data-driven decision making was when the embedded team and I were deciding whether or not to replace the existing driver screen with a more easily-programmable, but higher current option. We were confused on how to quantify making the decision of how much current was too much.

Alex entered the discussion with a simple metric - how many laps on the track would we sacrifice by adding this new screen? With this number, we’d be able to answer the question of whether this was a worthwhile tradeoff to make for ease of programmability. Another way Alex put it was “How many battery cells would you need to add to account for the added power consumption of the new screen. Is this worth it to you?“. This was one of the reasons I began to realize how important the Race Strategy subteam was to informing technical design decisions.

Attending the 2023 Solar Car Conference, this decision-making philosophy was articulated as “Weight, Watts, and Time” by Paul Park, the previous Captain of Toronto’s BlueSky Solar.

Preparing for design reviews as a BMS member, I always anticipated the questions Alex would ask, and would feel proud and motivated when I was able to justify my design decisions with data and engineering logic. As Electrical Lead, if someone hadn’t filled out their DR document, didn’t have a presentation prepared, or had missed noting a regulation, I should’ve more frequently channeled my inner Alex Ezzat, rejecting their request for a DR and sending them back with questions for themselves and their lead.

Improving the DR Framework

I don’t feel that I successfully standardized the DR1, 2, and 3 frameworks across all electrical subteams. Most of the time, there would be multiple DR1s as concepts were generated and discussed over multiple meetings, while DR2 and DR3 would get left behind as progress on implementation sped forward.

My recommendation to the new exec team was to keep DR0, and be more strict about having members completely fill out the DR1 document. Once the DR1 was passed, the full design solution space should’ve been explored and a final design chosen - only then should implementation begin (usually, design would bleed into implementation without a clear checkpoint). This would encourage the team to practice rapid prototyping of design concepts prior to deciding on the best design option.

Wiki

UBC Solar’s wiki was created by Andrew, the previous BMS lead, to replace the individual Project Management Sites that had previously been the team’s way of documenting standards and tutorials.

As someone who loves to write organizational procedures down, I took to the wiki like a fish to water. My goal for the wiki was to streamline the onboarding procedure, update existing tutorials with new team standards (such as Altium), and to document workflows such as Monday Usage, Design Reviews, and Recruitment Standards. Adding onboarding information to the BMS’s wiki page reduced the time taken to bootstrap new member’s team knowledge and gave them an easily-accessible location to search for team links, BOMs, and build books.

A wiki page documenting UBC Solar’s design cycle standards

The wiki also served as a tool for encouraging members to lead up, as anyone could create or modify any wiki page. This framework created space for members to practice their technical documentation skills while contributing to the team’s generational knowledge transfer resources.

Here are some of the wiki pages I was proud to contribute to on the team:

• Recruitment Standards
• Ceedling Unit Testing
• Wiki Best Practices
• Radio Operations
• UBC Solar Car FAQs
• Electrical PLM
• Firmware Versioning
• Github Organization
• Git Usage
• Scheduling Concepts
• FreeRTOS Implementation
• isoSPI Introduction
• Reading ADCs with STM32 MCUs
• DMA on STM32
• Altium Tutorial
• Solar Car Team Websites
• Electrical Shocks
• BMS Firmware Overview
• ECU and Controlboard Overview
• Module Sheet Thermal Testing
• Design Reviews
• MCAD-ECAD Collaboration

MCAD-ECAD Collaboration

At the beginning of April 2024 - late into Brightside’s manufacturing - I created a framework detailing how the mechanical and electrical teams should work together to integrate PCBs into the car’s mechanical assembly. Up to that point, aside from the steering wheel, there’d been little proactive thought about how electrical boards would be integrated with the chassis - elec designed independently, mech didn’t realize there needed to be boards in certain places, and the teams would reactively scramble to make a solution which worked, but wasn’t nice to work with.

The amount of times I struggled with plugging in connectors to the dashboard PCBs, or dropped fasteners while removing the telemetry PCB was a huge waste of time. This was a situation I felt responsible for, and I created the MCAD/ECAD Collaboration Workflow framework to fix this for future generations of the team.

Brightside’s dashboard worked for the driver, but working with it (ex. connectors) sucked

Case Study: Controlboard v2

Over the course of bringing up and testing the battery, we found several issues on the ECU v1 such as trace width, connector spacing, and lack of debugging LEDs. As we continued to test and the issues continued to grow, I began to consider the possibility of adding the design, build, and testing of an entirely new Controlboard v2 into the BMS’s timeline. This would include an ECU v2, as well as design changes to the controlboard that we’d identified since manufacturing, such as replacing large-gauge wires with busbars, and adding a fuseblock for the DCDC and array fuses. I knew these changes would result in a more reliable pack that was easier and safer to work with.

After the final battery tests were completed in February 2024, I proposed the v2 idea to the BMS and BTM teams, and after we agreed it’d be worth making those changes, set our deadline for fabrication three weeks later.

The Controlboard v1, with the DCDC mounted underneath the ECU (right blue rectangle)

The electrical changes (including a PCB stackup change) required some re-thinking of the PCBs layout, which would take about three days. The mechanical changes required moving around some components on the controlboard, but nothing that a couple iterations couldn’t accomplish in one or two days.

The biggest change was moving the high-voltage Vicor DCDC converter from being soldered directly to the back of the ECU’s PCB to a separate daughterboard that would instead plug in to supply 12V_DCDC to the ECU. This change was made so we could de-risk a situation where, if the ECU broke, we’d need to either de-solder the Vicor (a time-consuming process which would damage the converter) or make an entirely new ECU with a new Vicor soldered into it (even more time-consuming and expensive). Due to the space constraints of the pack, it was difficult to come up with a spot that would work for the new DCDC daughterboard while leaving space for the Masterboard and the wires going up to the Distribution Board.

The Controlboard v2, complete with re-designed ECU, DCDC, and Masterboard mounting

So began 19 days of Julie (prev. BTM lead, now Captain), Serhii, and I iterating on the new controlboard and ECU design, with the majority of this time spent figuring out where to put the new DCDC daughterboard. After two slack threads with almost 200 messages each and several hours of in-person meetings, we’d designed a new version that met all our requirements. However, I knew that a lot of time could’ve been saved if we’d been more intentional with the mechanical-electrical communication standards from the get-go.

As soon as the design files went out to fab, I organized a meeting with Julie and Serhii and enumerated how many days and hours each part of our design took. I laid out the good aspects of our communication, as well as major false assumption we’d made and the number of days each had cost us. At the end of the meeting, we realized we could’ve saved a full 7 of the 19 design days - a shocking number, considering the pressure we felt during that three-week sprint. After this reflection, I drafted up a wiki page for new team standards that would explicitly prevent the possibility of making every single assumption we’d made.

I was proud by my proactive accounting of the controlboard v2’s design process. I felt that I’d channeled my inner Alex Ezzat in quantifying the exact time we could’ve saved (Weight, Watts, and Time), and knew that the impact of creating a MCAD/ECAD collaboration framework would compound time savings across future generations of the team.

Electrical Inventory

This framework details a costly problem with a simple solution - since the team didn’t have any centralized inventory of electrical components, we would order a full new set of components, including extras, for each new PCB assembly we manufactured. After a couple PCB orders as Electrical Lead, I realized we could unlock significant cost savings by ordering components in bulk from sellers like Digikey and LCSC. Instead of spending $1 to buy 10x10kR 0805 resistors, we could spend the same amount to purchase 100, or sometimes even 1000 of these resistors.

I initially attempted an implementation with a single inventory Google Sheet in the Brightside BOM, however, as components were added to the inventory, the sheet became difficult to navigate, and folks stopped updating it over time. Brainstorming ways to re-implement this over the summer of 2023, I knew I could scale the inventory into a full-blown PLM, integrating it with Altium, the team’s BOMs, and seller’s online APIs (a thought inspired by Joe when he talked me through a Python framework he was building to query prices in real-time and integrate this with the team’s BOMs). However, I knew that I should follow the principal of building an MVP and seeing where it struggled and and succeeded before trying to build out an MMR.

To quickly build an inventory system that would reduce friction and encourage use, I decided to re-implement the spreadsheet, creating an independent sheet with separate pages for each component type. Each page had standardized columns where members could input a component’s MPN, inventory, and other relevant characteristics.

UBC Solar’s MVP Electrical Inventory

After setup, I spent two days with the BMS members inventorying and sorting all the components from project-specific bins into general boxes for resistors, caps, etc, and finally introduced the new spreadsheet to the electrical team during a general meeting - making sure to Vocalize the Why behind the new framework. I encouraged member’s habitual use of the system by asking them “did you update the electrical inventory?” each time a PCB was built or reworked.

In the month leading up to competition, the upkeep of the Electrical Inventory paid off big-time. Not only did we not have to dig through boxes and boxes of components (or worse, realize we didn’t have any and need to order new ones entirely) when reworking PCBs or building spare boards, we were able to take the entire electrical inventory with us to competition, ensuring that we had enough spare components to fix any electrical issue on any single board on the car.

Waterlogged DACs at Competition

An organized Electrical Inventory paid huge dividends when, on the second day of FSGP 2024, we drove for three laps in a downpour, causing water to collect on top of the MDI’s DACs and short out the 5V and GND lines (resulting in the motor being set to 100% acceleration).

After we pulled off the track and were back in our bay, two members worked on cleaning off the water-damaged PCB, while I searched through the electrical inventory and found our two spare DACs. We managed to clean off the corrosion so that the board worked just fine when powered an hour later, but if the DACs had been damaged, the Electrical Inventory would have saved our butts for day 3 of the race.

Firmware Versioning

As the team approached on-car testing, it became imperative for the requirements of the firmware_v3 repo to proactively be formalized with team leads, just as they would be for any other electrical system on the car. I brainstormed firmware_v3’s structure and automations while keeping in mind the goals of any successful software-development organization: maximized development speed, high product availability (minimal downtime), and ease of use (quick onboarding with minimal dependencies). The wiki page resulting from these discussions laid the foundation for scaffolding firmware_v3’s organization to achieve the aforementioned development objectives.

A snapshot of the firmware_v3 versioning wiki page

This idea of versioning a firmware repository isn’t new by any means, however, I brought concrete reasons for how versioning would help the tea, and workflows that supported the objectives of the framework. Previously, each component of the firmware (bms, mcb, did, etc.) were versioned separately on Monday - something that was fine for benchtop testing. However, in order to ensure all components worked together, and to track dependencies between component firmware versions, it was important to version all the components as a single unit.

“Stakeholders will decide on a list of features to be added to the car in the next release, a discussion which will include the negotiation of the release’s scope. This list of features could range from a single feature - BMS needing to add a CAN message to the ecu - or multiple features (ecu adds a CAN message, MCB adds a second pedal).”

• Wiki page

As we began on-car integration testing, the EMBD and BMS transitioned new items in their Monday boards away from large-scale projects and moved towards specific features or bugfixes to release in upcoming builds. This helped us track the many smaller items needing to be completed before competition that weren’t worthy of an entire DR process. This further helped differentiate the MVP and MRR of different firmware components.

A flowchart of firmware_v3’s release process I created to accompany the wiki page

As testing progressed, having stable releases of the firmware_v3 repository to refer back to was essential when implementing new features on the car. For example, we’d flash new code onto the MCB that didn’t work, and, needing to drive to collect regenerative braking data that afternoon, we’d flash a previous stable release while the new code was reviewed.

Tags (release titles) currently present in the firmware_v3 repo

Monorepo Callback

The decision to maintain the existing monorepo structure of firmware_v3 back in October 2023, as discussed with Nic and Andrew, was instrumental in the ability to version all components of the car together.

Feedback

As any teacher knows, giving feedback is one of the most important parts of improving a student’s skills. If you aren’t aware of your mistakes, there’s no way you can fix them. Furthermore, as you fix those mistakes, your self-confidence grows, empowering you to fix future mistakes independently. I understood early on that giving members consistent, clear feedback was key in setting them up for success. I think I did an excellent job giving members feedback when they did well, however, I struggled to give members feedback when they did poorly, a weakness which stunted the growth of some team members.

Callouts and Kudos

To encourage members to lead up, be recognized by their peers as strong leaders, and remind the team of what good habits looked like, I made it a priority to publicly praise individuals and subteams when they did good work.

Early on, Aarjav showcased a detail-oriented work ethic that I wanted other members on the embedded subteam to strive for. In addition to telling Aarjav “good job” individually, I set up a time for him to present on his project’s progress to the rest of the embedded team. At the end of the presentation, I pointed out the areas where he’d excelled. This allowed me to position Aarjav as a member whose work ethic should serve as an example for the rest of the electrical team, while also sneakily raising the bar for Aarjav’s own standards - he’d publicly set a high standard for this work, and I leveraged the fact that he was the type to try to out-do himself.

Following this trend of public feedback in the interest of fostering a member’s “leading up” mindset, I’d highlight good Monday updates in team meetings and Slack channels. Again, the purpose of these highlights was layered. This public praise would increase the member’s confidence in their own abilities, which would encourage them to speak out and lead up in the future, while also creating a culture of rewarding good work. I believe this pushes people to hold themselves to a higher standard and output a higher quality of work. Finally, public callouts increase a member’s leadership potential by framing their work as a standard towards which others should look up to.

Feedback on Monday Updates

The exception to my statement that I wasn’t good at providing feedback on poor-quality work was when telling members what I’d like to see improved in their Monday updates or DR documents. I took both of these frameworks very seriously, and so made sure to highlight everything from unclear wording to a lack of photos - often getting members to go back and edit their updates.

Case Study: Personal Experience

I realized the importance of feedback to personal growth while working at Sanctuary AI. As a new co-op student, I quickly noticed the lack of company feedback culture - I didn’t have any dedicated 1-1s with the firmware lead until I explicitly request them. This contrasted with my experience at Ciena, where my manager, Jonathan, had weekly 1-1 sessions scheduled with me from day one, during which we’d dive into a list of learning topics he’d prepared that were adjacent to my current projects.

Advocate for Feedback

It’s equally as important to advocate for your own growth as it is to have someone who advocates for it alongside you.

At Solar, I should’ve had earlier, more concrete conversations with members when they failed to meet team standards. Something I recently realized when talking with members is that most of the time, member’s didn’t meet a standard because they didn’t realize their work wasn’t up to spec or didn’t understand the standard in the first place. Instead of silently judging members for being lazy, I should have gone back to my core tenant of setting members up for success.

When transitioning out as Electrical Lead, Saman and I both agreed that the new executive team should hold detailed feedback sessions with each individual member and lead at least every 2-3 months.

Elec Lead 1-1 Document

As BMS lead, I prided myself on taking detailed notes during online meetings with members. However, when onboarding new members at the beginning of October 2023, I realized it wasn’t good enough to just take notes - as a lead, I had to push members forward to achieve each incremental milestone in the project to keep us on-time and on-requirement. I’d noticed that the last 20% of the project took 50% of the time, and that no amount of subitem granularity would push members faster if there weren’t clear metrics to quantize week-to-week project progress. Additionally, I realized that this weekly, formal itemization of project milestones was useful to teach the electrical subteam leads the skill of setting their members up for success. Finally, it was generally useful to have weekly 1-1s with leads to maintain alignment on project progress, keep communication channels open (a good lead is like grease), and encourage leads to be more grounded in the design progress.

To develop detail-oriented subteam leads that would keep members moving forward with steady progress and constant re-evaluations of a project’s state, I created the Elec Leads 1-1 Document. This framework was a running list of weekly meeting minutes from hour-long 1-1 sessions with subteam leads. These meetings had a simple, well-defined structure, as stated in the document’s purpose/introduction section (Vocalize the Why).

When it comes time to integrate, we must ensure all system requirements associated with that MVP have been met. We’ll use our weekly 1-1 time to dive into where each project is currently at, and what should be accomplished by next week - identifying any blockers and open questions along the way.

Review subteam-level goals by going through all items in each project group on Monday and reviewing timelines for each project’s MVP and the MMR. Recap last week’s project milestones by reviewing the last meeting’s goals, and evaluating whether they were accomplished. If they weren’t, why? Finally, create the next week’s milestones to be achieved. Set concrete steps as to how these will be accomplished, and schedule any necessary stakeholder meetings.

• Elec Leads 1-1 Document

As soon as we started these 1-1s, I saw project progress increase dramatically. While breaking down a project’s Monday subitems into four or five bite-sized weekly tasks was a mindset shift for me and the subteam lead, it forced us to think deeply about a project’s immediate next steps. For a “source components” subitem, did we need to write emails to three separate suppliers? Did we need a spreadsheet of different component options? This also helped subteam leads to question their assumptions about what a member could get done in a single week, allowing them to better understand their team’s limits, and push ever so slightly past them each week.

Additionally, the framework’s built-in reflection component of checking whether last week’s goals were met was critical in setting the pace for the team’s progress. I made sure that leads understood it was extremely serious if a member didn’t meet the goals they’d agreed upon. This mindset shift from “update me on your progress” to “here’s what we agreed you would get done by next week - what prevented you from doing so?” instilled a sense of gravity and responsibility for project progress in members, and identified real blockers when items weren’t completed for reasons other than a member having a midterm that week.

Success

The Elec Leads 1-1 Document was the single most important framework for setting members up for success by guiding them through the steps necessary to accomplish a large project on-time and on-requirement. As well, this document was essential for helping me set the subteam leads up for success when it came to building out their skills in organizing and leading technical teams!

Why Was UBC Solar So Awesome?

During the first general meeting of each new term, one of the first things the Captain would tell new recruits is that on a design team, you get out what you put in. I’d actually like to go a step further than this - when you put 100% of your effort and focus in, you will get 110% back out. As an engineer and teacher, I always marvel at complex systems where the net behavior consists of more than the individual sum of its parts. UBC Solar was that complex, positive-feedback system, where the more energy you put in, the more energy would be created. As I developed a sense of ownership over the team’s generational success, I found that the more focus and energy I put in to elevating the team, the more focus and energy I received in return.

When reflecting on Why Do I Want to Do, I noted that strong communities allow their members to take energy from them, and later rely on those same members to return that energy to make the community stronger.

This return of energy from the team’s spirit manifested itself in two major ways that propelled me to be more focused, work longer nights, and literally dream about my design team.

The Only Controllable Variable Is Your Effort

Energy is Infectious

Working with Serhii as co-ops at Sanctuary AI, a startup in the thick of a hundred-million-dollar series B round of fundraising, I understood that our mindsets around leading UBC Solar were very similar to those of running a startup. The key characteristic of running a startup that I resonated with was that the only controllable variable to achieving success was my effort (props to Cansbridge for this phrase). If I wanted to spend hours thinking of ways to make the team work harder, smarter, and faster (Weight, Watts, Time), then we would, and if I didn’t take that time, we wouldn’t.

Fight Entropy with Energy

During my January 2024 reflection a year after becoming Electrical Lead, I noted that I was a “boss at project management” and that I should continue to “fight the entropy and sweat to make your procedures better (because they always can be)!“.

Something that makes me proud is that I try to match and magnify the energy of others in all my interactions. The act of doing this is selfish - attempting to generate energy makes me feel more active, awake, and positive. Fortunately, it’s a selfish act that positively influences others too! Never will I be louder, more silly, more memorable, or motivational than when I’m trying to increase someone else’s energy.

Whether it was early in the morning or late at night, I felt it was important for people to see that their leader was the most excited out of the bunch to be working on Solar, and that this energy was consistently strong to take us to competition. The energy I exuded was infectious - I remember being offline for four days when I was in Ottawa, and coming back to fairly quiet slack channels. The day I returned, I sent out around 10 messages to members and leads, and when I woke up the next day, the number of unread DMs and conversations that my previous messages sparked had spread across the electrical team.

Creating energy is as simple as the act of instantly responding to a member’s message in Slack, putting the ball in their court and encouraging them to move faster.

Critically, I wanted the energy I exuded to be strong and consistent. This was something I admired in Serhii as team Captain, and a quality I strived to match - I wanted to be a lead that all members were proud to have representing their team. This idea of being a strong source of energy that other members could emulate fed into the aspects of my leadership style dedicated to “running UBC Solar like a startup”, and as part of the leadership team of a self-described startup, I felt personally responsible for being a professional presence on the team.

The Importance of Professionalism

Professionalism at UBC Solar was important to me for two reasons. One was that the more gravity I exhibited and vocalized towards my actions on the team, the more seriously I hoped others would take their responsibilities on the team.

The second is because the more seriously I took my experience at Solar, the easier it was for me to get into the flow state of working on team-related items. Feeling like it’s your professional duty to be energetic, composed, and prepared makes it easy to readjust the priorities in your life. As I focused more on UBC Solar, the professionalism and responsibility I felt towards the team became magnified, causing me to produce more and more energy as a leader. Pushing past my previous limits of energy and time spent on the team, I felt stronger and more capable of putting in even more work - a positive feedback loop that would allow me to get five hours of sleep for one or two weeks straight and still wake up focused and ready to work each day.

I didn’t initially make the connection to professionalism as a tool for focusing energy - I’d just always felt that professionalism in activities where you’re dealing with people outside of your close friends is important. In high school, as part of the John Oliver Digital Immersion Mini School, our class regularly went on week-long trips around BC, during which the teachers heading the program impressed upon us the fact that we were representatives of the mini school, and that our actions directly impacted the public perception and success of future trips.

As well, as a lifeguard for the City of Vancouver, I worked at Hillcrest, the city’s largest aquatic center. To be an effective lifeguard, one must be professional above all else - this is what makes people listen to you as you try to prevent accidents before they occur and take control of life threatening situations if they arise. As a lifeguard, when taking your lunch break, you always turn your shirt inside out so that members of the public don’t perceive you as “on duty”. I wore my Solar merch like it was my lifeguarding shirt - when it was on, I was on.

Hillcrest aquatic center, where some of the most professional lifeguards in the city work

Excitement About New Ideas

Another personal quality that synergizes with creating energy in my surroundings is that I am a relentless optimist. On an engineering design team, where technical and interpersonal challenges come up every single day, this quality allowed me to stay positive and resilient in the face of adversity. A shipment was delayed by two weeks - where can we get it locally? That trace on the PCB was too small - let’s add an external wire in parallel. When a problem would come up on the team, my mind would snap to potential solutions and skip the regular “stages of grief” which can paralyze other managers.

While being a relentless optimist was useful when reacting to situations, it was even more useful to proactively identify and seek out solutions to problems before they could occur. On a student design team operating as a startup building a solar powered race car, the only limit to the optimizations you can make to the team is your imagination and curiosity. Fortunately, I was surrounded by a lot of big thinkers who inspired me to think proactively.

Andrew, the previous BMS lead, was great at ideating new ways of working for the team. He singly-handedly created a Google-Forms-to-Github-Issues pipeline that greatly streamline our recruitment process, allowing us to quickly sort through over 130 applicants per cycle. Also, remember the team wiki I keep referring to? Andrew set that entire framework up.

Nic, the previous Electrical Lead, was also excellent at proposing new ideas. After he returned from his co-op at Tesla and before graduating to work there full time, Nic would drop by the bay to check on our progress, and while we chatted, would challenge me to consider high-concept new ideas. In everything from automated Github workflows to Altium library lifecycles, Nic presented ideas around implementing the custom tooling made by fast-moving industry giants at levels which could be leveraged effectively by the team in the near future.

Some of my fondest memories from January-April 2024 were heading over to UBC’s Browns with Nic and Joe (Formula E’s previous Electrical Lead and present Captain), and listening to them talk about running teams, ideas from industry, and new technical design frameworks they found exciting. Joe is an engineer’s engineer - if there’s a way to optimize weight, watts, and time, he’s either heard about it, or has already implemented it. The inspiration he’s sparked from our conversations about how Formula E executes their project management and technical designs is something I am so thankful for, as it has genuinely opened my mind to what’s possible on a student design team.

As I was exposed to more ideas for potential team frameworks, my mind began filling with ideas when I wasn’t working on Solar. I’d be biking to a friend’s house and suddenly pull over to the side of the road to write down an idea for helping members lead up, or make our PCB designs less prone to error, or I might be walking by an computer supply store and think “I wonder if they’ll sponsor our team”.

Case Study: Sponsorship

My first time sponsoring an item for UBC Solar was the Vicor V110A12C300BL DCDC converter. Hearing that the team had previously been sponsored by Vicor, I sent the company an email, and a few weeks later, had a tracking number for the free component in my inbox. This sparked my realization that if I was able to proactively anticipate items the team would need for development and manufacturing, a couple hours of my time could save the team thousands of dollars.

The key word here is proactive. The lead time for most sponsors ranges from three weeks to three months, and as such, the only way I could successfully sponsor an item for the team was if I incorporated it into project timelines. My push for sponsorship across both the mechanical and electrical teams encouraged members to actively anticipate the team’s needs and visualize what a project’s final, successful form would look like.

Each time I’d think of an item the team would need, I’d spend about an hour and a half emailing 5-10 companies who might be willing to donate the item to us. If I was lucky, one or two companies might respond positively or negatively. More often than not, I wouldn’t receive a response in the first place. However, if a company was local, or very specialized, I’d call them or find other departments within their company to email. In the majority of these instances, I’d receive a positive response, which fueled my energy to push for more sponsorships in the future.

Sponsorship Hunting

The longest a sponsorship ever took was 6 months. I initially emailed a company to request sponsorship of our radio modules, and while they responded to my request with interest, subsequent follow-ups from me yielded no further emails. Undeterred, I contacted the representative on LinkedIn, and, hearing no response, asked Serhii to do the same. After a few weeks, the rep responded to Serhii and agreed to send out parts to the team, however, they sent them to the wrong address (in Boston). After a month, we received the parts, only to realize they were the less powerful version of the part we requested. A month later, we finally received the correct parts, just in time for integration onto the car.

UBC Solar’s sponsors displayed on the side of the car at FSGP 2024

The sponsor I was most proud of connecting to the team was ECS. ECS is a local wire supplier located in Richmond, who was very receptive to my requests for sponsorship. Not only did they agree to donate hundreds of meters of wire for our low-voltage systems and our high voltage arrays, they actively wanted to collaborate on media and press to promote the sponsorship. Increasing the team’s public presence was another factor that fed into my mindset of running UBC Solar like a startup - I remember taking a meeting with ECS in one of Sanctuary AI’s meeting rooms, while across the way in the conference room, the C-suite of the company was meeting with potential investors.

Some additional examples of ideas that’ve sparked my curiosity, or I’ve thought of and implemented, are detailed below.

NCAN

Below is a picture of a PCAN CAN bus analyzer which goes for ~$500CAD retail.

Early on, I knew that having multiple CAN-USB devices available to the team would be essential for debugging any piece of firmware or hardware on the car. In case I wasn’t able to get these devices sponsored, Nic and I brainstormed an alternative solution - the NCAN. This was a $15CAD fully-assembled board that was meant to act as a drop-in alternative to the PCAN. In the interest of “getting an MVP that works”, over two months, the team developed a PCB based off open-source designs that could be flashed with open-source firmware.

While the device wasn’t exactly a drop-in replacement (didn’t work with PCAN-View all the time), we’d proved out a scalable in-house CAN-USB analyzer that worked with 90% of open-source Windows and Linux CAN analysis software.

Elec Space Organization

If you couldn’t already tell, I like organizing things. After organizing the electrical team’s project management Monday space, I turned to making the physical electrical space work better for the team. While, at the end of the winter break in January 2023, Serhii, Liam F, and I had renovated the entire bay, the electrical team’s boxes were still disorganized, and sometimes it was easier to just purchase a new component than it was to find it.

Renovating UBC Solar’s bay, an ownership-enforcing rite-of-passage for new exec teams

During the summer of 2023, I put up a new shelf in the electrical space to hold oscilloscopes and function generators, created dedicated boxes for firmware and hardware prototyping, and went on a labelling spree for all of elec’s boxes (with the Electrical Inventory being the last part of this process). I also put up lightning and spare monitors that made the space more usable and enticing to work in.

As a non-obvious example, while working on the battery one day, I noticed that at some point, all the stacked-up cardboard boxes above the workbench could easily get jostled and fall into the pack. I thought for a second, then grabbed a milkcrate sitting outside and stuffed three of the cardboard boxes inside of it. Just like that, I’d removed a hazard from the space. After this, I kept two spare milk crates around the bay at all times. Incidentally, the first person to inspire this milk-crate-craze? Joe.

Elec Computer

In order to persist telemetry data and enable quick benchtop monitoring of the battery, I grabbed an old HP tower I had lying around the house, installed Ubuntu Desktop on it, and set it up in the bay. A simple, hour-long process that unlocked numerous debugging and data-collection options for the team.

Visiting Other Teams

After competition in mid-August, I flew to Montreal for a vacation with some friends. The week before I left, I reached out to Eclipse at ETS and Esteban at Polytechnique Montreal to see if they’d be willing to give me a tour of their workspaces. They generously agreed, and I was fortunate enough to spend around four hours with each team, asking questions about everything from battery pack design to financial structure.

Esteban’s workspace tour, graciously hosted by their Electrical Lead (pictured) and Captain

Eclipse’s workspace tour, graciously hosted by their Mech Lead (pictured) and members

This visit was very special to me, as ETS was the winner of FSGP 2024, and one of the top 10 teams on the world solar racing stage in the SOV category. Esteban holds similar credentials in the MOV category - a repeat winner of FSGP and ASC, and a top competitor in the World Solar Challenge. Going from watching ETS in the Lightspeed documentary on my first day of UBC Solar to meeting them as Electrical Lead of the 6th place team at FSGP 2024 was a profound experience.

In addition, I wanted to make this visit a big deal for the new generation of UBC Solar. When I returned to Vancouver, I presented on my visit to the team to show them that UBC Solar had grown to become a real competitor on the level of some of the top teams in North America. I evoked a sense of pride in UBC Solar’s accomplishments, and showed the team that if we pushed ourselves, we could end up at the same level as these top teams. I also wanted to spark the same curiosity and excitement towards new ideas and design team innovation that I felt by showing the team, “hey, this is how this other students accomplish the same objectives we’re working towards”, opening the team’s collective consciousness to questioning assumptions of our own high level abilities.

Finally, these visits built invaluable inter-team connections that set the foundation for the knowledge sharing that is currently happening between our teams on everything from power electronics to material testing.

Bay Camera

My objective? To get the team to take more professional photos and videos in the interest of generating sponsorship content. I transferred my old Linux GH4 from the shelf in my room where it was gathering dust to a space in the bay where anyone on the team could access it. The chassis was being welded? Get some footage. The aeroshell folks were working on a layup? Take some photos for the composite materials sponsor.

After a year, having this camera present netted the team invaluable, professional-looking media that could be used for everything from recruitment to sponsorship.

Battery Safety

UBC Solar’s battery team has always been safe in designing and working with their battery packs, and coming from a background of lifeguarding, I took this culture of safety very seriously. I created the first team presentation on battery safety and created the first SOP formalizing the team’s rules around working with the battery pack. Once the pack was assembled, I was constantly looking to improve its safety, such as asking BTM to print out 3D printed covers for busbars and contactors. Finally, I learned from Joe about Formula E’s battery precautions and how to avoid the types of accidents they, and other teams, had experienced in the past. Overall, I’m proud to say that there were zero battery incidents during my time as BMS and Electrical Lead.

gen-visual-snapshot

This was a channel that Serhii and I created in Slack inspired by a similar channel at Sanctuary AI. This channel was meant for organization-wide pictures and videos related to cool achievements and progress reports. This low-effort, high-value change gave folks a look into what other subteams were working on while showcasing other member’s dedication. Posting a picture in gen-vis evoked a sense of pride and ownership over one’s work and generally increased the team’s motivation and cohesive spirit.

VDX’s progress shared with the team in the gen-visual-snapshot channel

Hierarchical Schematic Design

With the completion of the NCAN, Nic had provided the team a project implementing industry-standard Altium best practices. I codified the intention (Vocalize the Why) and rules followed in his design into a standard for UBC Solar’s hierarchical design, while trialing this standard on two projects being undertaken by members new to working with Altium. During this process, I encouraged them to contribute their learning and recommendations to the wiki page to build out the team’s documentation and make the standard more designer-friendly.

An excerpt from the section in the Altium tutorial wiki page on hierarchical design

This will be a huge step-up for the team in terms of professionalism, organization, and decreasing schematic loading times in Altium 365.

Passionate Members

While it was initially difficult to take over as Electrical Lead due to the team lacking focus and drive, every member was passionate about the project and motivated to contribute. As the frameworks that the Captain, Mech Lead, and I visioned began to be implemented and ingrained into the team’s spirit, the feeling of being a lead transitioned from pushing the team forward to being pushed forward by the team.

At the beginning of this post, I said that UBC Solar was the most important part of my life over the past four years because of the community I became connected to and subsequently strove to connect others to. Every single action I took as lead was to strengthen a world-class team that designs, builds, and races solar powered cars, and the only reason I could push myself so hard towards this objective was because there was a driven team working just as hard around me. Essentially, I’d helped build a team that would hold me accountable.

The team executing a pit stop on the first day of FSGP

I clearly remember the first time I felt like I’d succeeded in building a distributed, motivated team - in January 2023 helped Tigran, Sam, and Krish set up a test to validate the ADC firmware on the ECU. After checking over their procedure, I let them know they were good to go, and headed out for the night. On the way to the bus stop, I couldn’t help but grin at the fact that I was able to trust my team to work without my oversight, a goal I’d been driving towards for almost a year at that point.

As we approached competition, the momentum and independence of the members that dedicated their summer to finishing the car astounded me, and it was at that point that I truly understood what it meant to be a part of a design team. I no longer needed to message people to check in on their progress, or hold 1-1s with leads to see whether milestones were met. These folks, working hard whether it was 6AM or or 2AM, would come to me with updates, or better yet, tell me that I was blocking their progress.

Throughout my time as Electrical Lead, there were many members who impressed me with their technical skills and motivation, however, I want to highlight three members who grew to make the experience of being on the team at UBC Solar extraordinarily rewarding and exciting with their own drive and curiosity.

Ben

Ben had been on the team for as long as I had, and had become lead of the newly-formed PAS team just after I became Electrical Lead. Over time, Ben quickly became the best PAS lead that an Electrical Lead could ask for due to his intense attention to detail, a deep understanding of the power electronics theory behind our technical challenges, and his ownership over the team’s success.

After Ben became lead, I remember introducing the DR0 document to him for the first time, and I could tell he was skeptical of its usefulness. It was this skepticism and no-bullshit attitude that I came to truly appreciate, and later rely on, leading up to competition. Working with Ben, I was forced to thoroughly explain my engineering reasoning and convince him of the value of technical and project management decisions - if I couldn’t convince him of something, chances are it wasn’t useful in the first place. I will never forget Ben and I going over the car’s high voltage wire gauge sizing before electrical scrutineering, and after we’d written it all out, him saying “ok, now explain it all back to me”. Ben and I are both engineers who won’t accept less than 100% effort and completeness, and we held each other to this during tough times of no sleep and tight timelines (and always with a grin on his face).

Ben working on wiring up Brightside’s array

At the same time, I came to rely on Ben’s deep power electronics expertise combined with his sharp attention to detail, which elevated the entire team’s standards and technical abilities. From complex projects like cruise control to array energy modelling, Ben and I worked well as a team, as he wrapped his engineering first-principals knowledge around the executive team’s scaffolding of project management frameworks. This allowed us to achieve technical milestones I wouldn’t have considered possible (or even imagined in the first place) prior to Ben growing into increasing responsibility as lead.

Finally, I was so proud of Ben’s growth as a mentor and teacher. When he stepped up as PAS lead, I could tell that he’d put himself into a role that he wasn’t instantly comfortable with. However, his persistence to learn and willingness to integrate new ideas while staying true to his own technical frameworks lead to immense growth and success as a project manager and engineer. An example of this was the array wiring diagram that Ben put together with PAS members Saman and Michelle. Ben leveraged his experience with high voltage wiring and power distribution systems to lead Saman and Michelle to make informed choices on wire size, length, and routing configurations. He independently encouraged his members to set up meetings with the aeroshell team to work on the location of array wire cutouts, and helped Saman put together a detailed plan for the array testing, soldering, and wiring process. The team is forever in Ben’s debt for forcing me to give more time to the array wiring and testing integration deadlines. Ben knew that it would take 5-7 days to fully wire up and test the arrays, longer than the 1-2 days I’d considered. Since I wasn’t able to convince Ben otherwise, I trusted his analysis of the situation, and put more focus and energy into integrating the arrays into the car, a decision which paid off considerably to decrease stress and increase the reliability and power generated by our arrays at competition.

Presently, it’s so heartening to see Ben participating in the team as an active alumni, initiating discussions with Race Strategy members on data analysis while providing advice to Saman on the roadmap to building own our custom MPPTs. This, from a Ben who, two years ago, wasn’t sure whether he wanted to be a lead in the first place.

Ben making an observation to Diego about Purdue’s array configuration

Saman

Saman is the definition of a member whose attention to detail lead him to success on the team. The first time I sat down to discuss a project’s progress with Saman, he pulled out his iPad, and showed me the detailed notes he’d made and the questions he’d prepared. I immediately recognized someone who worked in a similar way to how I’d worked as a BMS member, and as lead, I felt determined to set Saman up for success in the ways I was, and wished I was, as a member.

Every challenge I presented to Saman, he tackled with energy and hard work. For example, after revisiting the requirements of our telemetry system, we realized we needed to conduct detailed range tests on our current radio modules to ensure they could meet our new transmission distance requirements. I encouraged Saman to lead this project from the PAS side, and set him up with my expectations of how the test should be planned and documented. Within this framework, Saman was able to flex his project management muscles for the first time, coordinating with EMBD members to execute, document, and present the results of the test to the team. Throughout the process, Saman consistently communicated his results with the leadership team and incorporated my feedback into his work.

Saman making Ben, Aarjav, and I laugh while installing the car’s wiring

The reason Saman excelled at documentation was that he was a very curious individual. Similar to me, he needed to understand the fundamental principals behind the devices he was working with at every level of abstraction. Often, Saman would ask me questions that made me say, “that’s a great question - I don’t know the answer, but let’s find out together”. This hunger for technical understanding was what made Ben and Saman such a successful member-lead pairing. While working on the array energy modelling project, he ran with fairly open-ended requirements, and each time we met, he would excitedly present new findings and project objectives he’d developed from his research.

Over time, Saman lead up more and more on critical projects and in the process, taught me important information about the systems we were working with through his extensive Monday updates. On the same radio systems project mentioned above, Saman was the first member on the team (that I was aware of) who read the module’s datasheet cover-to-cover, and because of this, was able to bring up important features of the device that were previously unknown to the team.

Currently, Saman is doing an exceptional job as the team’s Electrical Lead. He has brought his focus and insatiable curiosity to improving the Race Strategy team’s algorithms, data analysis workflows, and modelling of the car, and has channeled his upbeat energy into increasing the momentum of the electrical team, bringing in new frameworks related to prototyping and increasing the reliability of the team’s design process.

Aarjav

Aarjav, currently the embedded co-lead, is one of the smartest-working people I know. Aarjav is not only able to understand and visualize complex systems and open-ended projects, he’s able to produce results in half the time I’d expect, with double the quality of work, and triple the level of documentation.

As a lead, it’s important to recognize that setting members up for success looks different for each individual. Setting Aarjav up for success looked like giving him a clear vision and purpose for a complex technical project, and then staying on top of his progress to course-correct as he chewed through code and documentation. Aarjav began making strides on the team when he started refactoring Sunlink, the data processing, storage, and visualization software stack of UBC Solar’s telemetry system. As the changes he made to the project quickly surpassed the project’s MVP, I channeled Aarjav’s attention toward documenting his changes on Monday and in Sunlink releases.

Clear Communication

Aarjav, more than any member on the team, focused on his vocabulary and phrasing when discussing technical concepts. Aarjav habitually grounded his conversations in concrete technical language, rephrasing and reiterating to ensure everyone participating in the discussion was on the same page as he introduced new concepts.

I quickly realized that Aarjav embraced documentation even more than I did - he wrote several READMEs on the new software architecture he’d created the previous week, made detailed Monday updates that I highlighted to the team as examples that I personally wanted to mimic, and generally elevated the embedded team’s standards for what detailed, professional documentation and code structure looked like. Aarjav pushed the team’s pace forward, holding Ishan and I accountable to keep just ahead of his progress.

Aarjav leading the Telemetry system’s bringup and debugging

Aarjav’s intentional, detailed documentation lead the telemetry system - the most important and complicated electrical system on the car - to a roaring success as he lead its bringup, integration, and debugging in the month prior to competition. There were many nights when I’d leave the bay at 11PM and Aarjav would be in the atrium continuing to debug the latest issue with the telemetry system, only pausing to wave a friendly, energetic goodbye. Aarjav owned his projects from beginning to end - I never felt the need to nag him about timelines or requirements, because I knew he’d internalized these aspects at the project’s inception.

A detailed release note written by Aarjav for Sunlink

I was pleasantly surprised to find that the team relied on Aarjav more and more as we closed in on competition. The first day we drove after the topshell was installed on the car, the Memorator wasn’t sending its timestamp messages over CAN. Aarjav, back home in Calgary at the time, was instantly available to hop on call and point me to the detailed documentation he’d written as to how to reconfigure and flash the Memorator, a device he’d only been introduced to a couple weeks before. It was a testament to Aarjav’s detailed, hard work that Sunlink and the rest of the telemetry system worked 100% of the time at competition, preserving invaluable data that will allow the team to level-up its future designs and strategy.

Aarjav’s independent and accelerated work ethic, along with his huge curiosity, lead him to learn and contribute to almost every single piece of firmware on the car. If we were having trouble with the MDI firmware, Aarjav would be able to parse and suggest changes to it within the hour, while asking thought-provoking questions about the high-level design intent of the project. At present, I’ll see Aarjav contributing to discussions in Slack threads from every single electrical subteam, pushing his fellow members and leads to work faster and more intentionally.

In Closing

While my time on the team started as a way to boost my resume and technical skills, it grew into a life-changing experience that pushed me far beyond the limits of what I’d ever imagined I could accomplish, and gave me the privilege of learning from and working with a community of some of the most driven, passionate, and energetic engineers to build a freaking solar powered race car.

I do not feel as though I’m finished with UBC Solar. As with any community that’s impacted you positively, I believe it’s important to continue to contribute to the community’s spirit. I will never part with the experiences I had at UBC Solar, and I know I will forever be a member of the most amazing design team in the world.

UBC Solar celebrating our success at FSGP 2024 before competing in ASC for the first time