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.
But I found it to be bookmarkable. I really like the RACI-like chart.
Pretty well done overall, good writing style and good advice, opinionated (which is the point) but not overly so.
I only disliked the "warning" about "light math". I felt it was talking down to her audience in an attempt to come off as more human and less robotic / analytical and make sure the reader plows through that part if they start to perceive it getting too dense.
Maybe I'm wrong about the intended audience. It could be for director+ level folks, who make these org decisions. Maybe she doesn't expect them to have any math skills. But it is in the _Better Programming_ blog, subtitled _Advice for programmers_.
It also feels filled with "assume a perfectly spherical cow of uniform density" oversimplification. While the roles are certainly different, so are people, teams and companies. Very often, optimizing for those strengths/weaknesses is more important than some universal rule about the appropriate breakdown of responsibilities between roles.
