Engineering project leadership is often discussed in terms of technical ability, but during my F1 in Schools-style CFD assignment, I found that the human side of teamwork mattered just as much as the engineering itself.
What surprised me the most throughout the semester was that the primary constraint was not aerodynamic simulation, but team optimisation: communication, organisation, and situational leadership.
This project became one of the clearest examples of how technical work and people management are deeply connected. This assignment also reinforced how much I enjoy iterative design work, which is something that has also carried into several of my personal engineering projects outside class.
Project Overview
The assignment involved iteratively designing an F1 in Schools-style CO₂ powered car using SolidWorks and SolidWorks Flow Simulation for CFD analysis before manufacturing and physically testing the final design. Alongside the engineering work, we also had to complete multiple reports documenting our design process, analysis, and testing outcomes.
Each report had a four-week completion window, the class sessions took place once per week, and throughout the semester the project requirements and due dates were often inconsistent, changing, and unclear. Especially during the early stages, it was difficult to clearly determine what exactly was required for submission.
At the start of the semester, we formed groups and assigned roles. I initially selected the design role rather than the leadership role because I wanted to focus primarily on the CAD and simulation side of the project.
However, the reality of the project quickly changed.
Why Leadership Became Necessary
Early in the first report cycle, two group members, including the member who had originally taken on the leadership role, each missed a class session. By that point, the report had not been started, and it was due at the end of that week.
I realised that unless somebody stepped in to organise the project, we were at serious risk of falling behind and potentially missing the first submission deadline entirely.
Rather than formally taking over, I focused on creating structure:
- I created the report template
- Began writing initial sections
- Organised tasks for the rest of the group
- Helped clarify what needed to be completed
Once the absent group members returned, I had them decide amongst themselves which sections they would complete so that the workload could begin moving again quickly.
By the end of the first report, I noticed that contribution levels across the group were extremely uneven. That was the point where I began thinking less about simply “getting work done” and more about building systems that would allow the group to function consistently.
That shift in thinking changed how the rest of the semester went.
Building a More Functional Team
One of the requirements of the assignment was that roles needed to rotate between group members throughout the semester.
In practice, that was not always realistic.
Two of us were already deeply involved in developing the CAD models and iterating designs in SolidWorks. Handing those responsibilities entirely to other group members would have required them to first learn the modelling workflow and then understand the existing design iterations before continuing development. This would have significantly slowed the project and the benefits of that did not outweigh the cons, especially given our tight deadlines.
A large part of why I was comfortable taking on that responsibility came from the CAD experience I had already built through both personal projects and formal study. This comfort stemmed from my prior CAD experience, a progression from self-taught experimentation to formal coursework that I detailed in my previous post aobut learning CAD.
Instead, we adapted the structure while still respecting the intention behind rotating responsibilities.
For example:
- The two strongest CAD contributors continued handling modelling and manufacturing-related tasks
- Research and project timeline tasks were assigned to the group member best suited to organisation and documentation
- Report sections rotated more flexibly between members
- Different members handled presentation components across submissions
By the second report, we had moved toward much clearer section allocation from the start.
For the final report, I created the report structure immediately and assigned draft sections early before discussing the allocations with the group to make sure everyone was comfortable with their responsibilities.
That early clarity made a major difference.
Contribution levels became noticeably more balanced compared to previous submissions, and because everyone already understood their report sections, allocating parts of the oral presentation also became far easier.
Learning People’s Strengths
One of the most useful lessons from the project was how important it is to understand people individually rather than viewing a team as interchangeable parts.
At one point during the second report, I was speaking casually with the group member who had originally taken on the leadership role. During that conversation, he mentioned that he felt most confident when working with data and quantitative analysis. That small detail heavily influenced how I allocated responsibilities later.
For the final report, I assigned him to the evaluation and outcomes section, and because the task directly leveraged his analytical skills, the quality and efficiency of his contribution improved significantly.
I realised that effective leadership often comes down to understanding:
- what people are good at,
- where they struggle,
- and how to structure work around that.
Interestingly, this was something I had already been learning through my retail supervisory role.
Similarities Between Retail and Engineering Leadership
Before studying engineering, I did not expect my retail job to help me lead an engineering project. In reality, many of the core skills transferred directly.
In my grocery store supervisory role, I constantly think about:
- Who works well together?
- Who is strongest at particular tasks?
- How different personalities respond to pressure?
- How human factors can affect efficiency?
Retail work exposed me early to the reality that performance is rarely just about technical ability. Fatigue, stress, and even things like poor morale can completely change how effectively a team operates on a given day.
That experience carried directly into the engineering project.
I became a lot more aware that successful teamwork is not just about assigning tasks. It’s also about understanding how people work best, how they communicate, and what level of guidance they actually need.
One thing I noticed from retail supervision was that different leadership styles can produce different outcomes. One of the more experienced supervisors I work with sometimes describes needing to provide constant, step-by-step oversight for certain tasks to ensure they are completed properly. When I take over those same shifts, I often find that all that is required is an occasional check-in or reminder rather than constant intervention.
That difference made me think more carefully about leadership during the engineering project as well.
Over-managing can sometimes create dependency, while under-managing can create confusion. The challenge is finding the level of involvement that keeps work moving while still allowing people to work independently.
That became one of the biggest leadership lessons I took away from the semester:
Good systems reduce unnecessary dependency on individuals while still supporting the people within them.
Over time, I also improved how I communicated with the group. I began writing clearer messages, announcements, and emails that created a more closed feedback loop:
- I would outline the plan
- Ask whether everyone agreed or wanted adjustments
- Group members would confirm they had read the message
- Additional thoughts or concerns could then be discussed early
That reduced confusion significantly, especially given the changing project requirements throughout the semester.
How Engineering Leadership Differs from Retail Leadership
At the same time, the project also showed me that engineering leadership differs from retail supervision in important ways.
In retail, authority is partially built into the role itself. I was promoted from cashier to supervisor, so the title already carries recognised responsibility and authority within the workplace structure.
In the engineering project, leadership worked very differently. The original leadership title alone did not automatically create direction or momentum within the group. Instead, leadership emerged through:
- Initiative
- Reliability
- Communication
- Technical contribution
- Consistency
It had to be earned rather than assigned.
I also noticed differences in planning style.
Retail supervision often involves rapid short-term thinking like:
- solving problems during a shift,
- reacting to unexpected situations,
- adapting staffing and workloads in real time.
Engineering projects still require adaptability, but there is also a much stronger long-term planning component.
Interestingly, I already had some habits from retail that translated well into this environment. Before my shifts at work, I mentally prepare for what tasks or issues might arise during the day so I can quickly assess priorities once the shift starts.
I found myself doing something very similar with this engineering project. I was constantly thinking ahead about:
- upcoming report deadlines,
- likely bottlenecks,
- workload distribution,
- and potential risks if somebody became unavailable.
What I Learned
This project reinforced something I have increasingly noticed across both engineering and broader problem-solving:
Technical problems are often easier to solve than people problems. The engineering side of the project was challenging, but predictable:
- Improve the CAD.
- Iterate the design.
- Run CFD tests.
- Manufacture & assemble.
- Evaluate the results.
Whereas human factors introduced dynamic variables:
- People learn differently.
- People communicate differently.
- People contribute differently.
- Requirements change.
- Availability changes.
- Motivation changes.
Leadership became less about “being in charge” and more about creating an environment where progress could continue consistently despite those variables.
It also made me reflect on how engineering itself is often framed too narrowly as purely technical work. In reality, engineering projects are deeply human systems.
I have noticed a similar pattern in other topics I have written about as well: discussions often become overly focused on tools or technical details while overlooking the human systems around them.
What Could Be Improved
Looking back, one of the biggest improvements would have been implementing clearer structure even earlier in the semester.
The final report was our strongest largely because:
- responsibilities were defined immediately,
- expectations were clear,
- and everyone understood their role from the beginning.
If we had established that structure during the first report cycle, then the overall workflow likely would have been smoother from the start.
I also think the project highlighted how important consistency in instructions and deadlines is for collaborative engineering work. When requirements frequently change or become unclear, uncertainty compounds across the entire team.
At the same time, learning to adapt to that uncertainty was valuable in itself because real-world projects rarely operate under perfect conditions.
Final Takeaway
This assignment started as a CAD and CFD project, but it ended up teaching me far more about leadership, communication, and systems thinking than I expected.
It also reinforced something I have noticed across many areas of my work and study: Technical ability matters, but projects succeed or fail largely because of how people work together.
