The article suggests that the correlation between corporate success and founders being replaced is due to the influence of investors; I think there's another far more innocent explanation: Many of the replaced founders WANTED to be replaced.
I recently found a bug on the Yahoo website (a graph was being drawn incorrectly) which could be fixed in a startup in about 15 minutes; but because Yahoo is such a large company and has so many users, individual developers can't go in and make even a trivial, obviously-correct fix to the live website -- instead, it takes three weeks for the fix to go through QA (along with all the other changes which have been prepared since the last QA cycle).
A founder who has spent three years building a startup -- and being able to fix bugs and see the results 30 seconds later -- isn't likely to be happy working with a 3 week QA cycle. There's nothing wrong with either approach; they're just suitable for different people.
Do what you're good at doing, and let someone else do what you're not good at doing. If you're a startup hacker, then go do a startup; but once your company is successful and not a startup any more, bow out and let someone else take over. Staying around to do a job which you're neither interested in or good at doesn't do any good for either you or your company.
Another thing to consider is that sometimes 'QA' isn't even an appropriate term for what goes on in a 3 week change cycle. Sometimes it's only because there has to be a clear blame tree if anything goes wrong.
I recently found a bug on the Yahoo website (a graph was being drawn incorrectly) which could be fixed in a startup in about 15 minutes; but because Yahoo is such a large company and has so many users, individual developers can't go in and make even a trivial, obviously-correct fix to the live website -- instead, it takes three weeks for the fix to go through QA (along with all the other changes which have been prepared since the last QA cycle).
A founder who has spent three years building a startup -- and being able to fix bugs and see the results 30 seconds later -- isn't likely to be happy working with a 3 week QA cycle. There's nothing wrong with either approach; they're just suitable for different people.
Do what you're good at doing, and let someone else do what you're not good at doing. If you're a startup hacker, then go do a startup; but once your company is successful and not a startup any more, bow out and let someone else take over. Staying around to do a job which you're neither interested in or good at doesn't do any good for either you or your company.