I used to manage a team of mixed very-experimented / very-juniors and I'd make sure every senior worked on stuff I knew were not in their comfort zone, and assi

I used to manage a team of mixed very-experimented / very-juniors and I'd make sure every senior worked on stuff I knew were not in their comfort zone, and assign tasks in their expertise domain to juniors. They'd act as consultants, while checking other parts of the codebase/docs (as noobs) for incoherencies, sand-in-gears, and improving them. Over time, the experts kept things getting better, up to their common standards, and the juniors would level up far more quickly than other parts of the org. To keep things interesting/challenging for the experts I'd have them also reach across domains (to system eng, safety, quality assurance, bids, R&D) and sometimes even overreach (blur the boundaries) while protecting them from corporate-strife. Software is far more interesting in the context of the product, the customers, actors on every critical team. I'd also have them try new techs, or find some innovation/maturity budget for 'pet peeve hunts' and we'd often end up with new tools, large-scale improvements in code, perf, readability, robustness, observability, or testing. I'm going off topic here but I'm sad that 'Slack', the book, isn't more widely read.