Designing the team, not just the boat.

Something a little unreasonable.

We wanted to build high-performance foiling yachts, take New Zealand engineering to Italy, and create a university team that would actually push boundaries.

I helped establish the University of Auckland Advanced Foiling Team because of my love for sailing, hands-on engineering and ambitious design. I also wanted a different kind of student engineering experience: one where people could take ownership of meaningful work and learn by making real things.

Our goal was to design and build two International Moths for the 2027 SuMoth Challenge in Italy. We thought a boat could be built in less than a year. I don't think we fully believed it until we watched Kōtare lift out of the water.

I thought doing it myself was faster.

I wanted every detail to be right. So I designed too many of the parts myself.

It seemed efficient: I knew what I wanted, I didn't have to explain the brief and I could trust the outcome. For one component, that logic sometimes worked. For a 25-person project, it created a bottleneck.

Other members had fewer opportunities to design, experiment and learn. Meanwhile, I was buried in individual tasks when I needed to be supporting people, reviewing interfaces and helping the whole project move forward.

Then I overcorrected. I delegated work but became too hands-off. A wing control box exposed the problem: the person I asked was a capable designer but didn't fully understand the manufacturing constraints. The printed walls were too thin for the load, the clearances were wrong, and the part broke.

Leadership isn't doing all the design. It's helping other people do their best design.

Five executives. Too many crossed wires.

At first, everyone was managing everyone. Which meant nobody really knew who was responsible for what.

Members didn't always understand the big goals or their weekly priorities. Executives stepped into each other's areas, updates were hard to track, and even incoming emails could go unanswered because responsibility wasn't clear.

We didn't want to fix this by dividing the club into five isolated departments. That would have reduced the opportunities for people to learn across disciplines. Instead, we created five smaller groups with team leads for progress and support, while the executives became specialist leads working across the programme.

This structure isn't perfect, and it continues to evolve. But it taught me that effective organisation is not about adding hierarchy. It's about making responsibilities clear without closing off learning.

Ten minutes became fourteen hours.

The final control-system assembly was supposed to be a quick job before launch. Almost everything that could go wrong did.

Parts broke. Interfaces didn't line up. Fixing one issue exposed another. By Saturday evening, suppliers were closed and our options were limited. The team improvised with a turnbuckle from another boat, a kitchen spoon and hose clamps to get through the immediate problem.

I am proud of the ingenuity and teamwork that night. But I don't want to romanticise it. The bigger lesson is that we had left systems integration too late.

We should have tested individual subsystems earlier, checked how components interacted through their full movement, and assembled the mechanism before launch week. A completed part is not necessarily a validated system.

From Weet-Bix boxes to carbon fibre.

The most valuable prototype isn't the most expensive one. It's the one that answers the right question.

Our control-system mounting points occupied a difficult, crowded space. CAD was essential, but measurements and digital geometry alone could not settle every question about clearances, moving parts, attachment points and real-world assembly.

I worked through an iterative sequence: CAD, cardboard mock-ups, 3D prints, stainless steel and finally carbon fibre. Each stage gave us different evidence. Cardboard helped us understand the space. Printed parts helped us test geometry and tolerances. Physical metal components advanced the fit and functional development.

Carbon fibre gave us the lightweight, strong final material we wanted, but it was costly and difficult to manufacture. Using faster, cheaper prototypes let us remove uncertainty before committing to it.

The important limitation: a cardboard or 3D-printed prototype can confirm geometry, not prove the structural performance of the final composite. The evidence has to match the question.

Don't prototype to make it look finished. Prototype to find out what you still don't know.

Evidence is only as good as its assumptions.

I want to make products that are lighter, stronger and more capable — but a convincing simulation isn't the same as a validated design.

In separate MECHENG 701 coursework, I investigated hybrid carbon, basalt and flax composites. I manufactured 100 specimens across 20 laminate configurations and used three-point bending tests to study how fibre selection, orientation and ply placement affected flexural behaviour.

I then explored a preliminary hybrid-composite wing-bar concept using CAD and Abaqus FEA. The work strengthened my understanding of how manufacturing variability, loading assumptions, boundary conditions and material models influence conclusions.

It also reinforced what remained unproven. Flexural coupon tests alone cannot validate shear, torsion, buckling or impact performance in a real wing structure. Those are questions for further work, not claims I can make from one set of results.

Academic integrity note: MECHENG 701 research is identified as separate work, not represented as a new DES221 deliverable.

What improved. What still needs proof.

We built a foiling boat. We also built a far more capable team. But success doesn't mean every decision was good.

These are recommendations, not processes I claim we have already fully implemented. Our judgement that the structure improved is based largely on what the team experienced; we have not run a formal productivity study.

Over the DES221 professional-practice period, I refined my Moth model, developed my portfolio and CV, and created this case study to examine my decisions more critically. I chose to show mistakes as well as achievements because I want my work to communicate how I think, not just what I made.

We set out to build a boat. We ended up building a team capable of building one.

Five things I'd tell anyone starting a team.