What Organizing Berkeley Omnium Taught Me About Leading Teams

A shared purpose makes the hard parts worth doing

Berkeley Omnium exists because a lot of people decide to give it their time. The weekend brings together the Berkeley Hills Road Race and the Berkeley Streets Criterium, put on by the Berkeley Bicycle Club. Every part of it depends on an organizing committee, volunteers, clubs, officials, sponsors and community partners working toward the same two days.

I help organize it with that team, alongside my engineering work. I wrote about what riding and racing have taught me in What Cycling Taught Me About Engineering Leadership. This is the other side: what organizing has taught me.

Organizing Berkeley Omnium has reinforced the same lessons as leading engineering teams: people need a clear purpose, realistic commitments, named ownership and support. The results belong to the whole team.

Our purpose is concrete. We create opportunities for racers, including junior, collegiate and women’s fields, and the proceeds support local NICA teams. Our events raised $21,000 for NICA teams in 2025 and $28,610 for six NICA teams in 2026. Those totals belong to everyone who organized, volunteered, sponsored, partnered and raced.

That purpose does real work when a task is tedious. It helps to know exactly who benefits. Engineers need the same thing, which is why I want every engineer to be able to say why their current task matters, and who is waiting on it.

Volunteer time is a real constraint

Everyone on the team fits this work around jobs, families and everything else in their lives. Enthusiasm is easy to find. Capacity isn’t, and treating one as the other is how good people burn out.

So the shape of a request matters. A clear ask with a defined end is much easier to say yes to than an open-ended “can you help with sponsors?” Responsibilities need to fit the time people actually have, and deadlines need room for the weeks when life gets in the way.

The tension is with standards. A race has to be safe and well run, and respecting people’s time can’t mean lowering that bar. It can mean a smaller scope, a longer runway, or two people sharing a role so it doesn’t depend on one person’s free evenings.

Engineering teams have the same limit with less visibility. Salaried time looks unlimited on a roadmap. It isn’t, and I’d rather plan around the capacity a team actually has than discover the real number halfway through.

“We should do this” isn’t the same as owning it

Some of the riskiest words in any planning meeting are “we should.” Everyone agrees, nobody leaves owning it, and a task the whole group supported can sit untouched for weeks.

What helps is plain: a named owner, a clear outcome, and visible dependencies. Who is following up with whom, by when, and what do they need from someone else first?

The harder question is what to do when an owned task starts slipping. Stepping in can protect the date. It can also teach the owner that their ownership was never real. I’d rather ask what’s in the way, offer help, and agree together on whether the plan should change. Taking the work back is the last option. It’s the same principle behind how I mentor engineers: support when things go wrong, without taking ownership away.

The race date forces honest prioritization

A software date can usually slip. A race date mostly can’t, and that changes the conversation about scope.

Some things must be in place for a safe, well-run race: the course, officials, marshals, registration and clear information for racers. Other things are improvements, and they can wait if they have to. Separating the two early protects the team. It stops nice-to-haves from eating the time that the essential work needs, and it lets people say “not this time” without feeling they’ve let the event down.

A fixed date also means discussion has to end in a decision. On a volunteer team, input matters, because people commit to plans they helped shape. But input with no decision point stalls everything. I try to make sure people are heard, then that someone decides, and that the decision is written down where everyone can find it.

Engineering releases with fixed dates need the same discipline: protect the must-have scope, make the cuts explicit, and ask what we’re willing to stop instead of asking the team to absorb everything.

Finished tasks don’t add up to a ready race

A race weekend depends on many separate pieces coming together at once. Each one can be done and the race still not be ready. Registration can be complete while the information hasn’t reached the people who need it. Volunteers can be confirmed without knowing where to report.

Software releases fail the same way. Every ticket is closed and every service passes its own tests, yet the system doesn’t work end to end because nobody owned the connection between two pieces. That’s why I push to test the whole path early, so nothing new is learned on launch day.

The people closest to the work usually see these gaps first. A team needs room to say “I don’t think this will work” early, and a leader needs to respond with curiosity instead of defensiveness. A concern raised weeks ahead is cheap to address. The same concern discovered on the morning of the event isn’t.

The work continues after the finish

Race day is the visible part. Much of what makes it work happens earlier: preparation, coordination and follow-through that nobody sees from the finish line. That work deserves the same credit as race-day execution.

After the finish, there’s still more to do. We thank volunteers, sponsors and partners, review what to change next time, and close the commitments we made. It’s easy to skip when everyone is tired. It’s also a big part of why people come back.

Engineering teams have their own version: the post-launch review, the cleanup work, the thank-you to the team that unblocked you. A release is one delivery. The relationships behind it carry into the next one.

Short answers