John X is assigned to project Y with team A but find it very boring for him. So he overengineers in a way so that it only works by solving a very complicated en

John X is assigned to project Y with team A but find it very boring for him. So he overengineers in a way so that it only works by solving a very complicated engineering problem that he wants to solve instead (think "developing your own distributed no-sql db" class overengineering). John X leaves for a more interesting project, team A can't make modifications to the current over-engineered system so they need do a rewrite of a few key components that incurs a huge delay. And yes, it was not John X's fault. It was the manager's who assigned it to the wrong team and project, and the team leader's that they didn't have working code review process to be able to give JX feedback early to "write code easier to maintain by a less experienced team even if it's maybe less efficient and takes him a bit longer". So you're right in insinuating that category-three people don't really drag projects down: it happens when they are assigned to the wrong place and when you have teams with broken processes, so objectively speaking, bad management is actually what's dragging things down in this case. But isn't "bad management" close to a pleonasm anyway?