I promise this isn’t one of those “what deep sea diving taught me about B2B sales” type LinkedIn posts.
I help run a team of marshals at the Isle of Man TT races. I also lead a remote engineering team. These sound like very different jobs, but they have a similar concern: how do you coordinate people you can’t see, doing work you have to trust is happening?
If you’re not familiar with the TT: it’s a motorbike race held on public roads on the Isle of Man, a small island between Britain and Ireland. The course is 37.73 miles of normal roads, closed for racing. Over 200 corners. Speeds above 180mph in places. It’s been running since 1907 and is considered the ultimate challenge for motorbike racers. I wrote about my first visit to watch it here.
Over 600 volunteer marshals are needed for every practice and race session. Without them, the roads don’t close and the bikes don’t turn a wheel. They’re positioned around the entire 37 miles, responsible for safety, flags, barriers, ensuring the track is clear and ready for racing and incident response. The marshal community is over 8,000 volunteers, many returning year after year.
There’s a mixture of people in the teams around the course – some come back year after year and know the track better than most of the riders, some are on the island for their first time that day, some register for marshalling months in advance and others decide to try it out the night before.
On a race day, volunteers arrive at our location before the roads close. We show them around the kit and where to find it: medical bags, fire extinguishers, flags, barriers etc. We walk through maps of the course, where spectators can and can’t stand and where the rescue helicopter will land if needed. We open the medical bags so everyone knows what’s inside and where, and we hope it’s never needed.
Then they go to their posts, spread out along the course. And I can’t see them anymore. Neither can race control.
Each individual post has line of sight to the next, so flags can relay information along the course. Each post has a radio. But once they’re in position, they’re trusted to do the job. No news is good news.
Remote engineering teams work the same way. People are distributed. You can’t watch them work, and you shouldn’t want to. You can have standups, Teams, Slack, maybe some check-ins and meetings during the day. But mostly, you’re trusting that the work is happening. No news is good news.
The instinct, often, is to increase visibility. More check-ins. More status updates. More “just making sure.” But that’s checking up, not checking in. It signals distrust. And it often doesn’t actually tell you what you need to know.
What works is the same in both contexts: clarity up front, then trust.
At the TT, we get one chance to communicate before people scatter to their posts. If it’s not said in the briefing, it’s not getting said. So the briefing has to cover what matters: where the barriers go, how the kit works, who does what if there’s an incident.
But just as important is the why. It’s not necessarily obvious to newbies that you must get flags displayed before going near the track to help a downed rider. People assume they could just step back if another bike was coming. But these machines move at 180mph. By the time you see it, it’s too late. When people understand why something matters, they remember it.
Same with engineering teams. A ticket that says “implement X” is less effective than one that explains why X matters, what problem it solves, what good looks like. When people understand the purpose, they make better, more independent decisions and are able to fill in gaps.
And there are always gaps, because plans don’t survive contact with reality. At the TT, there are delays. Weather, incidents, logistics. Sometimes someone doesn’t show up. Sometimes we need to move people between posts. The question isn’t whether the plan holds. It’s whether people can adapt when it doesn’t.
This works because of two things: autonomy within boundaries, and a clear escalation path.
Marshals can make some decisions on their own. They can show yellow flags to warn riders of debris on the road or an ongoing incident. They can speak to spectators who are in the wrong place or getting out a drone to illegally fly over the race. They can coordinate with adjacent posts to relay warnings along the course.
But some decisions need authorisation. Red flags to stop the race come from race control, not from individual posts. If something’s beyond their scope, they can escalate to me. If it’s beyond mine, I can escalate to the Chief Sector Marshal, who in turn can coordinate with race control.
Remote teams need the same structure. People need to know what they can decide themselves and what needs sign-off. They need to know who to escalate to and when. Get this wrong and you get either paralysis (everything waits for approval) or chaos (everyone doing their own thing).
The hardest part can be trusting people you don’t know yet.
Volunteers sign up to marshal online or in person. Some I’ve worked with for years. Some I’ve never met. When I see an unfamiliar name, I get in touch before race day. Do they know where we are? Do they have supplies for a long day? Have they marshalled before? Where?
New marshals get paired with experienced ones. The experienced marshal shows them the ropes. The whole team doesn’t need to be there for every lesson. We trust the pairing.
Onboarding in engineering works the same way. A new hire paired with someone who knows the codebase, the norms, the unwritten rules. The lead doesn’t need to teach everything directly. But they do need to set up the pairing, make sure it’s working, and stay available for questions.
What does “good” look like? For marshals: reliable, observant, a good communicator, willing to move where they’re needed. The best ones notice things. A small part hanging off a bike. A spectator edging into a dangerous spot. These observations, communicated well, can prevent real problems later.
For engineers: the same, really. Reliable. Observant. Communicates well. Willing to help where it’s needed, not just where it’s comfortable. Notices things that aren’t quite right before they become incidents.
In both cases, the job isn’t just mindlessly executing tasks. It’s paying attention, making judgements, and speaking up.
None of this is about surveillance. It’s not about tracking hours or watching screens or demanding proof of work. It’s about setting people up to succeed, then trusting them to do it.
The briefing matters. The why matters. Clear boundaries matter. Escalation paths matter. Pairing new people with experienced ones matters.
And then you let go. You trust the posts you can’t see. You trust the work you can’t watch.
When you trust your team, no news is good news.