Cambridge University Drone Society

I work on both the engineering and operational side of the society — leading a UAV team while also managing the resource decisions behind delivering projects. Both feed the same outcome:

Lead a six-person engineering team developing a custom UAV, working across airframe design, propulsion, sensing, embedded hardware and flight control. It is not just CAD or software — several subsystems have to work together.

I design and refine the UAV airframe in CAD, balancing several practical considerations:

I integrate motors, ESCs, power distribution, microcontrollers and sensors into the complete aircraft — these parts have to work as one aircraft, not as isolated components.

Onboard electronics handle sensor acquisition, state information, feedback control and autonomous-flight capability, with practical integration between hardware, embedded software and aircraft dynamics.

Inertial and other onboard sensor information has to be combined into useful state information about the aircraft.

The engineering work connects aircraft dynamics with onboard control — developed and tuned from real flight behaviour, not just theory.

The aircraft is developed iteratively from test results. Real problems investigated include flight instability, mechanical vibration, sensor noise and controller behaviour.

I apply systems-engineering principles to connect mechanical, electrical, software and control subsystems into one working aircraft. The hard part is usually not each subsystem on its own — it is the interfaces between them:

I lead a six-person UAV team, with engineering responsibility for:

Not receipts and spreadsheets — the interesting part is managing limited resources across competing technical projects: budgeting, procurement and capital allocation across drone projects, competitions, workshops and wider society operations.

Financial planning across competing engineering activities weighs several factors:

I manage procurement and supplier evaluation — comparing options not to find the cheapest part, but the one that best supports the technical project within budget and schedule.

I work with project leads to translate technical requirements into realistic costed delivery plans — understanding what a project actually requires before approving funding, rather than treating engineering spend as generic budget lines.

I track expenditure against approved budgets and use variance analysis to spot where funding should be redirected toward higher-priority work.

The treasury role is constrained decision-making, not administration:

Holding both responsibilities means I understand the technical requirements of engineering projects and the financial constraints behind delivering them.