13 July 2022. It's the eleventh stage of the Tour de France, a brutal day in the Alps finishing high up the Col du Granon (that's a really high one). Two of the best one-day racers in the world, Mathieu van der Poel and Wout van Aert, the two men who have spent the last several springs trading wins across the Flemish cobbles, both went up the road in the early break.
Neither of them was racing for himself.
Van Aert was working as super-domestique for Jonas Vingegaard, fetching bottles for the Danish climber on his way to yellow. Van der Poel was up the road for Alpecin, the loyal lead-out man for a sprinter teammate who could ride their bike even faster than him. Two riders who win their own races for a living, spending that July in service of someone else, because the races their teams cared about most were going to be won by someone else.
Van der Poel cracked and abandoned the Tour that same afternoon. Four days later his teammate Philipsen won his first ever Tour stage. The star went home, but the team kept winning.
In professional cycling, role is a function of the race, not the rider. In most SaaS teams we audit, the senior engineer is at the front of every decision regardless of what kind of decision it is, because seniority and role have been collapsed into the same thing.
Let's call this the peloton problem.
What this looks like in software teams
Roughly 80% of the SaaS companies we have audited show the opposite pattern to our beloved cyclists. One person, usually the CTO or principal engineer, is at the front of every decision: architecture, code review, production support, hiring, the awkward Slack conversation. In 63% of those audits, that same person is also playing product manager, scrum master and production incident commander. One leader, four jobs, all of them at the front.
The intent is speed. The effect is an inverted peloton. The leader burns energy on routine work and arrives at the decisions that actually need their judgement already exhausted. The team behind them, never given a chance to ride at the front of anything, gets dropped the first time a real crosswind hits. When the senior eventually leaves, what looked like depth turns out to have been the appearance of depth.
This pattern is rarely a failure of character. The leader genuinely cares about the work, the team is shipping under pressure, and the founder remembers when there were three of them and everything was easier. Recognising the pattern is a different exercise from judging the person inside it.
The best teams we audit keep a clear hierarchy and rotate the front-line work anyway. Code review, production support, architecture decisions, on-call rotations. The most senior developer should not be catching all the wind. Juniors and mid-level engineers handle the routine work, build capability through repetition, and learn what wind feels like at speed. The senior architect arrives fresh at the few hard decisions per quarter that actually shape the system. When that senior eventually takes a holiday or moves on, somebody has already been holding the front for them.
The role attaches to the work, not the worker. Everyone on the team should know what the wind feels like. Only one person should face it in the moment that decides the outcome.
Ready for an experiment?
Pick the most important thing your most senior person is currently doing alone. Hand it, deliberately and with a straight face, to the second-best person on the team for thirty days. Tell them they have full ownership for the month, that you will not step in, and that you will be on holiday for half of it. Then leave.
What happens in those thirty days is your real team. Van der Poel went home from the Tour halfway through. His team won at the Champs-Élysées later that week. Build for that.
