[ivan_gammel]

It feels like the author experienced some pain for which the solution was the formalization of the roles in such an explicit way. The positive part of it makes a lot of sense, the trust in the teams is essential, so splitting the responsibilities between the most experienced IC and the manager is a good thing.

However the part about “should not” is not that obvious. An important part of building trust is allowing others to do your job, be it representation of the team in your absence or some part of engineering work. People may not do the job as good as you, but they will do it good enough - understanding this is the key to building trust. When you have this level of trust you can improve the communication by using more different channels.

If a manager performs a code review, this may save time of engineers explaining the complexity of the solution and their time estimates. If a tech lead or developer steps into the conversation with stakeholders, they may understand better the user needs and business constraints. A strong leader will see a good opportunity for personal growth of the team members in letting them to try doing his job. A humble leader will see an opportunity to learn from the team by reading the code. Restrictive role separation will remove such opportunities.