[fighterpilot]

> If requirements were fulfilled, but you aren't happy with the result, then your requirements were wrong.

Isn't it possible for a dev to fulfill requirements but still deliver a bad result as measured by subjective (but important) things such as code smells, bloat, crappy algorithmic logic, and so on? Or do you think managers need to spec things out in such strenuous detail that surprises (but also, to an extent, autonomy and ad hoc decision making) aren't possible?

There's also the case of R&D roles where it's hard to spec things out exactly in advance, and you're partly relying on the employee's ingenuity.

[takeda]

You're talking about completely different thing than what OP was talking about. It's about developer having a different vision than you.

You either need to accept that someone sees the problem differently than you and accept their solution, or if it is something important to you, you need to get better at explaining your vision.

Anyway, back to your requirements, as you pointed those requirements are subjective. If those are important things you should still outline what's expected. You don't have to do it for every project, and can be when person is being on-boarded.

[fighterpilot]

Right, in that case I'm in agreement, if the employee didn't deliver what was expected because they didn't understand (or weren't convinced with) the manager's vision, then that's most likely the fault of the manager's communication.