TL;DR: The most useful leadership training I ever had was not a job. It was a year as the elected President of the IEEE student chapter at FAST NUCES in Lahore, the same year my team was fighting its way to the ICPC World Finals. Nobody in a student chapter is paid, nobody signed a contract, and anyone can stop showing up on any given week without consequence. That makes it the purest test of leadership there is: people only stay when the work is clear, the piece they own is really theirs, and they can see it mattering. Years later, as a CTO at startups where I have very few hours and no interest in commanding anyone, I still run on the same rules. Here they are.
Most of what I write here is technical: AI voice agents, AR systems, build pipelines. This one is about people, because the part of engineering that decides whether a team ships is usually not the code. I learned most of it before I was paid to lead anyone.
Why volunteers are the hardest team to lead
In a company, a lot of weak leadership is hidden by the salary. People show up because it is their job, and a vague plan or a confusing priority costs some efficiency but rarely makes the team vanish.
A student society has none of that cover. Everyone has exams, assignments, part-time work and their own ambitions. If the plan is vague, they drift. If the work feels like busywork, they drift. If someone else takes the credit, they drift and do not come back. You find out very quickly, and very honestly, whether people are following you or just tolerating you.
That year I was also deep in competitive programming, which I wrote about in what competitive programming taught me about production engineering. My time was scarce on both fronts, so I could not lead by doing everything myself. I had to lead by making other people able to do it without me. That constraint turned out to be the whole lesson.
Give people an outcome to own, not a task to finish
The first thing that stops volunteers from drifting is ownership. "Can you help with the event?" gets polite yeses and very little else. "You own registration: the form, the reminders, and the list at the door on the day" gets someone who thinks about it in the shower.
The difference is that an outcome has an edge. The person knows where their responsibility starts and ends, knows what done looks like, and knows that if it goes well, it is visibly theirs.
I use the exact same principle with engineering teams now. As a fractional CTO I split work by ownership, not by ticket, and I wrote about the founder version of it in being a technical co-founder with a remote US partner: write down who has the final say on what, before anyone writes code. An engineer who owns the release pipeline behaves differently from one who was assigned "fix the build" this sprint.
Clarity is a form of respect
Volunteers disappear most often not from laziness but from confusion. When someone does not know what is expected, the easiest thing to do is nothing, and doing nothing feels safer than doing the wrong thing in public.
So the job of the person leading is to remove ambiguity before it costs anyone their motivation:
- One written brief per piece of work. What it is, why it matters, when it is due, who to ask.
- A default for every open question. "If you do not hear back by Thursday, go with the smaller venue" keeps work moving when the leader is busy.
- One place where decisions live. Not scattered across personal chats where half the team never sees them.
None of this felt like leadership at the time. It felt like admin. It turned out to be the most transferable skill I have. When I hand an AI voice agent over to a client, or when I leave a written end-of-day handoff for a US team that wakes up nine hours after me, it is the same habit: make the next person able to act without waiting for you.
Make the first contribution small and winnable
A new volunteer who is handed something huge on day one either freezes or burns out. A new volunteer who is handed something small, finishes it and gets thanked in front of the group usually asks for the next thing.
This is onboarding, and engineering teams get it wrong constantly. A new engineer's first week should end with something real merged and shipped, however small, not with a reading list and an intimidating ticket. The first win builds the confidence that makes the second, bigger contribution possible. I think about this every time I join a product mid-flight, which is how I came into RAQTS as CTO and wrote up in stepping in as CTO mid-build. The same logic applies to me as the newcomer: understand the ground, make a small correct change, then earn the right to make big ones.
Events have a fixed date, so scope moves instead
A student event does not slip. The hall is booked, the speakers have travelled, the announcement is out. Whatever is not ready on the day simply does not happen.
That teaches a discipline most software teams resist: when time is fixed, scope is the variable. You decide early what the event cannot do without, protect that, and cut everything else without drama. It is much better to run a smaller thing well than a larger thing badly in front of everyone.
I apply this directly to software releases and app store submissions, where a date is often fixed by a launch, a client meeting or a marketing push. Decide what must work, ship that, and cut the rest before the deadline forces the cut for you in a worse way.
Asking someone bigger than you for something
The most ambitious thing that year was not an event. It was pitching a celebrity on a collaboration, which ended up spinning up a community of around 100 active volunteers. I was a student with no budget and no leverage, asking someone with a large audience to give us attention.
What I learned from that pitch is the same thing I now use when I talk to a founder about a project:
- Lead with what it does for them, not with what you want.
- Make the ask small and specific. A clear, easy first yes beats a vague big one.
- Show you have already done the work. A plan and a team ready to execute is far more convincing than enthusiasm.
It is the same shape as a good discovery call, which I described in scoping an AI voice agent: start from their problem, be precise about what you will deliver, and make it easy to say yes to the first step.
A community of 100 does not run on one person
Once a group grows past a handful of people, the leader cannot be the hub any more. Every question routed through one person is a queue, and that person becomes the reason things are slow.
The fix is structure. Small groups with their own lead, clear ownership inside each, and the leader's job shifting from answering questions to making sure the leads have what they need. I did not get this right immediately. The instinct to stay involved in everything is strong, especially when you care about the result.
This is the exact trap of the fractional CTO role. With several companies at once, as I wrote in holding the CTO title at three startups, I simply cannot be the hub for any of them. I am there for a few decisions that are expensive to reverse, and the team owns everything else. The student version of that lesson made the professional version much less painful.
Credit in public, fix in private
Volunteers are paid in recognition. If they do good work and nobody notices, you will not see them again. If they make a mistake and it is discussed in front of everyone, you will not see them again either.
So the rule was simple: name people publicly when things go well, and deal with problems one to one. It sounds soft. It is actually practical. People who feel safe admitting a mistake tell you about it early, while it is still cheap to fix. People who fear being embarrassed hide it until it is expensive. That is true in a student society and it is true in a production incident.
What did not transfer, honestly
Not everything carries over. In a paid team you can set expectations more firmly, and sometimes the right call is a direct conversation about performance rather than hoping someone re-engages. Volunteer leadership also rewards charisma and energy a little more than engineering leadership does. On a technical team, being right about the architecture and calm under pressure matters more than being inspiring at a kickoff.
But the core held up better than anything I learned from a book: clear ownership, written clarity, small first wins, fixed dates with flexible scope, and credit given freely.
A checklist for anyone leading their first team
- Hand out outcomes, not tasks. Each person should know what they own and what done looks like.
- Write the brief and include a default for every question that might go unanswered.
- Make the first contribution small and visible.
- Treat the date as fixed and the scope as the variable.
- Stop being the hub once the group is bigger than a handful.
- Credit in public, correct in private.
- Protect your own deep work. I could only do both roles that year because I stopped trying to do everyone else's job.
If you are a student leading a society right now, this is not a distraction from your career. It is some of the most honest practice for leading engineers you will ever get, because nobody has to stay.
I lead engineering as a fractional CTO for startups and build AI agents and products for teams across the US, UK and Europe. If you need someone who can own the technical side of a product and get a team moving without becoming the bottleneck, more about me is here, or book a call.