Only we didn’t have a more junior person on the team because it was not that organization’s policy to hire junior people. Leadership felt more senior people would get more done and therefore why waste headcount on junior people?
If one engineer monopolizes a whole work stream then no one else understands it, no one else can maintain it, and if the system is critical enough the engineer may be denied opportunities to do other things. The organization ends up with a knowledge transfer issue that stunts growth.As a person learns they take on new responsibilities, if they cannot transfer some of their knowledge to colleagues they also cannot transfer any of those responsibilities. As they take on additional responsibilities they are not being released from their old responsibilities. The team becomes more and more dependent on them, they have less and less time to devote to new learning. Eventually you either burn the person out or you force them to leave for a new organization in order to clear their responsibilities and focus on growth opportunities.Look, no matter how brilliant they are or how thoroughly you screen for “culture fit” you can’t have a team full of tech leads. If you do nothing but hire senior engineers the only way to maximize the output of those engineers is to allow them to continue building new things. In any given software project there are different levels of tasks to be completed. Obviously in the beginning there’s a lot of architectural decisions to be made, a lot of unknowns, and a lot of requirements to be discovered, but as the project continues the team will start to pull off well-scoped items of work that need to be done in order for things to continue.