Ideas
One rotating champion per technology
A single expert per technology is a risk that looks like a strength. A shared calendar of rotating champions spreads the knowledge of each technology across the team and shows where the gaps are
Every team has one: the person who knows the pipeline, the one who understands Kafka. They answer every question, review every change in their area, and nobody plans a release without checking they are around. It looks like a strength. It is a single point of failure with a first name.
My answer is a calendar shared by the whole team. For each technology or practice the project depends on, such as the pipeline, the unit tests or the message broker, one member is its champion for a set period: a program increment or a quarter. When the period ends, the calendar names the next one.
A champion is not the person who knows it best. It is the person who answers for it this quarter
Being champion means owning the technology for that period: answering questions, keeping its documentation up to date, making sure the team’s rules for it are applied, spotting what should change. The person who already knew it becomes the new champion’s first support, and stops being the bottleneck.
The rotation does the real work. After a few turns, each technology has had several champions and each member has owned several technologies, so knowledge no longer lives in one head. Responsibility becomes concrete too: it is hard to say “that is not my area” about a technology you will own next quarter.
The calendar also turns a vague risk into a number. The share of technologies without a champion tells management where the team is exposed, before someone leaves rather than after. The number of champions per technology and staff turnover show whether the rotation holds.
A technology nobody answers for already has a failure date: the day its only expert is away