I've been there too many times to count. But maybe its just me.
I'm purely an engineer who 100% prefers being hands on; now that I accidentally have to manage teams, I fully appreciate the article's perspective. I've been on both sides of that argument as well.
It's not about a manager expecting an underling to get his paperwork done. I think that is an unfair assessment of the argument being made. It's that there's more involved to the job of engineering than simply pushing code one thinks is clever.
Sometimes that means knowing which problem to focus (not just the fun ones), sometimes that means dealing with other responsibilities like mentoring or interviewing or filling up timesheets or getting to work on time or attending meetings or what have you. None of those are unreasonable requests (as much as we hate them). If it's part of the job description, it's part of the job, and, for example, making a piece of code conform to one's own subjective preferences so they can feel clever doesn't make up for missing a deadline on a separate, boring, high priority task.
I've frequently seen engineers who think otherwise. Who think their work is so brilliant, they don't need to care about the boring stuff. Some of them have indeed been brilliant. But guess what; they still need to get their shit together, because their brilliance is still objectively not making up for being unreliable.
People are all different. Its up to a manager to get the best from each. Harping on TPS reports is not the way to get there.
Who said anything about a manager's work? There's lots of things that can be called "boring" but are still expectations that fall on an engineer, not on a manager.
If a problem gets to the point where the person being reviewed is unaware of it until a review, the system and management above it has failed. This should all be part of the process. Nothing should be surprising, the feedback should be continuous and so should the attempts to rectify things.
I'm not saying disputes don't come up, or that there aren't issues that develop. But the idea of "implied" tasks or project needs that go neglected to me in turn implies that this should have been addressed immediately, not at the time of an annual review or something, after the fact, and after it's been allowed to grow.
To me it's a sign of lack of communication and management being out of touch.