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.

I've watched this scenario play out on multiple occasions, in different variations.

In one memorable case, the developer missed some pretty important requirements that mattered a lot to management but did not matter to him. The developer certainly felt that he was railroaded by politics. But I, as an independent observer at the same level, could easily see that management was right to want what they wanted, and that the developer was too emotionally invested to see what he was missing.

Same company, same team, same developer, a different project, not too long earlier. He went off and developed something that really did meet the needs we had, and got rewarded for it. The difference is that he actually understood the requirements and nailed them.

Drive, ambition, technical chops, and an unwillingness to listen first can get a lot done, very quickly. The same characteristics can create a lot of conflict very quickly as well. It is hit or miss which happens in any particular case. And on the misses, management is easy to blame but they are not really to blame.

> In other words, he pissed management off. He busted his as off trying to improve the product and was rewarded by being treated like shit.

No, he wasted valuable time and company resources attempting to do something that wasn't needed, or asked for, and provided no value (arguably negative value) to his team in doing so. Of course people work hard and aren't rewarded for it, but it sounds like it's the case here that this cowboy was trying to outwit the system and ended up hurting the team a lot with his irresponsibility.