I agree that a worker can often reasonably evaluate their boss.
But unless you've been a director level person - with 'managers of people' working for you, it's easy to see how a 'well liked boss, who lets's their workers do their jobs' is often not the best manager.
Team staffers may think their job is to do ABC, but really it's XYZ. A dev may think it's his job to write 'quality software'. But the business objective may call for 'a quick iteration for demonstrative purposes'.
The staffer thinks he's 'doing his job', his boss lets him, but the business objectives are totally off.
>"But the business objective may call for 'a quick iteration for demonstrative purposes'."
Most developers I've worked with are smart enough to know quick hacks are fine in small doses, but if they become the norm you end up with a great deal of technical debt, which can ultimately cripple the productivity of a company.
From the perspective of managers who aren't familiar with technical debt, the 'quick win' is always going to seem like the best option. It's up to the development team to strike a balance between 'the quick way' and 'the right way', and whilst some managers may get frustrated on the occasions when 'the right way' wins out, in the mid to long term they benefit too, though they may not understand why.
But unless you've been a director level person - with 'managers of people' working for you, it's easy to see how a 'well liked boss, who lets's their workers do their jobs' is often not the best manager.
Team staffers may think their job is to do ABC, but really it's XYZ. A dev may think it's his job to write 'quality software'. But the business objective may call for 'a quick iteration for demonstrative purposes'.
The staffer thinks he's 'doing his job', his boss lets him, but the business objectives are totally off.