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.

We've all seen thought leader writeups like this before, written as if the author invented the concept. I was ready to roll my eyes and congratulate myself on knowing the content (the bias) just from the title.

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_.

This article reminds me how FAANGs are great at coming up with all sorts of extra roles/job responsibilities simply so someone can pay themselves on the back in their end-of-year and/or promo write-ups.

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.

Reaction: An EM should review code code for ~15 minutes each week, so he has some slight sense of what's happening at the coal face. If things are going well, the team should barely be aware that it happens - and only through rare positive comments about their work.