Did you actually read what I wrote? Including the sentence you quoted?
He busted his ass to deliver something un-asked for that didn't meet more than maybe 5% of our requirements and didn't improve the product in any way, rather than doing the job he was paid to do, because he decided he knew a better solution without knowing or understanding what the full requirements were.
Had he come to me and asked if he could do an experiment to see if he could rebuild part of the system simpler, we would have discussed the idea with him. If he gave me reason to believe he could meet the full requirements rather than what he thought the requirements were, we would certainly have entertained the idea of giving him time to prototype something.
But he didn't. He made a ton of assumptions that were mostly wrong about what the system needed to do, because he was not privy to e.g. the strategy discussions the board and executive team had, and the discussions we'd had with investors.
That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots. While doubtless sometimes they are, a lot of the time they simply have more information than you.
Do you honestly not see how someone that takes an initiative like that could be an incredible boon to a company? When you punish people like that, what you're left with is an office full of drones that does exactly what they are told, nothing more nothing less.
The situation you're describing is a management failure of epic proportions. Failed to communicate future planned features to dev team. Failed to exploit someones willingness to take responsibility. Failed to get input from the programmers (obviously at least one of them thought the code base was a mess).
Oh, and hiring someone who believed making a good product was more important than following chain of command. Big mistake there.
> That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots.
Even construction workers always knows what they are working on and why their work is important. If management is unable to communicate to the developers what purpose their work serves to the company then that is incompetent beyond belief.
He busted his ass to deliver something un-asked for that didn't meet more than maybe 5% of our requirements and didn't improve the product in any way, rather than doing the job he was paid to do, because he decided he knew a better solution without knowing or understanding what the full requirements were.
Had he come to me and asked if he could do an experiment to see if he could rebuild part of the system simpler, we would have discussed the idea with him. If he gave me reason to believe he could meet the full requirements rather than what he thought the requirements were, we would certainly have entertained the idea of giving him time to prototype something.
But he didn't. He made a ton of assumptions that were mostly wrong about what the system needed to do, because he was not privy to e.g. the strategy discussions the board and executive team had, and the discussions we'd had with investors.
That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots. While doubtless sometimes they are, a lot of the time they simply have more information than you.