I see some lessons in the OP, but not the ones Ben intended. Ben is saying that at times need to work very hard? Okay. Ben is saying that if a competitor has

I see some lessons in the OP, but not the ones Ben intended. Ben is saying that at times need to work very hard? Okay. Ben is saying that if a competitor has a much better product that is selling well and threatening own business, then likely just must do the work needed for a competitive product. Okay. But after that I lose it with Ben: His "lead bullets" are defeatist, close to luddite, look like he is trying to degrade himself and his company, to fight by getting down, dirty, simplistic, nose to the grindstone, shoulder to the wheel, and ear to the ground and trying to be successful in that position, to suffer first and count on that being the path to success. Not good. Indeed, one of the things we're supposed to be doing is innovating, which likely also means being creative, original, maybe even mathematical or scientific. Ben reminds me of Edison sending yet another team to the Amazon jungle to look for more plants that he could bake into carbon and try for a light bulb filament that wouldn't burn out so soon. The real solution was to borrow the idea of a tungsten filament from the chemist Swan in England and to use a really good vacuum pump from a guy in Germany. Edison could have had his teams slogging through jungles for 1000 years without finding anything. But, eventually Edison did go with tungsten and the German vacuum pump. For Windows' first version of IIS being as much as five times faster, tough to believe that just a 'lead bullet' approach would yield what was missing from what Ben had. Instead, look at the architecture and think a little about what the heck the poor computer is being asked to do. Then look at where the computer resources are going. Likely then, tweak the architecture: So, if are spending time walking down arrays or linked lists in O(n), then consider using an AVL tree in O( ln(n) ). If executing the code for a page when know that the output will be the same as the last 10 times, then cache the output and don't run the code again. If caching the output in main memory, i.e., virtual memory with page faults, then consider just using disk file for each page to be cached and save on page faults. If are connecting to a database, then have a pool of connections. Etc. I.e., think a little. Looks like Ben doesn't like thinking, more likely has, really, a low regard for his people and doesn't trust them to be productive if asked to think. Ben wants to measure hard work by sweat, long hours, and suffering and not good work with good results. Here's a lesson I draw: I agree with Ben that a business that has been going along well might suddenly encounter some problems, e.g., a five times faster competitive product given away for free. First, such problems should have been expected. If Ben had inefficient software, then he should have known that and not had to learn it from a Microsoft product. Or, how and why did the Microsoft people do a much better job? Sure: They wanted something fast, at least not wildly inefficient, thought some about the architecture, and did a decently efficient implementation. Why? Because they cared enough. Then before Microsoft's work, Ben hadn't cared enough. Second, Ben should have done much better trying for, expecting, counting on, working toward silver bullets. I sense that Ben doesn't much believe in silver bullets, suspects that any efforts toward silver bullets will be just time and effort wasted. Bluntly, I seriously doubt if Ben knows how to direct a productive, creative, effective little applied research project. Ben reminds me of the remark in the movie about the auto guy Tucker "A well run company doesn't waste time on research". Yes, some research is close to intellectual self-abuse, but it's the job of a good CEO and a good Board to know that this is not always true (e.g., SR-71, 22 nm line widths) and how to make applied research productive, not just throw out the baby and drink the bathwater. Third, any entrepreneur with a good chance of doing well has to ask himself at least 10^10th times if he wants anyone like Ben on his Board of Directors. Why? Sure: The CEO and his team have seen an area where they might do better. With the CTO, the CEO outlines an applied research project to get the coveted better results. So, for the next Board meeting the CEO includes some foils on the applied research project. Then in the Board meeting Ben wakes up and starts asking questions: How long will the project take? How much will it cost? How good will the results be? What will be the milestones during the project? What is the project schedule, step by step? Or if an experienced auto mechanic can do a brake job on a Ford F150 truck in the time in the book, why not this 'research' project? So, the CEO has to tell Ben and the Board that for all of the questions, at present he is comfortable with the situation, will continue to review the situation during the work, but otherwise really has no answers at all for the more specific questions. Presto: Ben gets torqued, brings out his fiduciary powers, fires the CEO, before his stock is vested, and 'gets the company back on a business like, bottom line basis' and just blows it. Even worse, maybe the applied research has already been successful, and at the Board meeting the CEO introduces the CTO who explains the work and, then, the next step, converting the applied research to production software. Again, just over the software work, Ben does an upchuck. I just don't see Ben being able to work effectively with things that are new, powerful, valuable, innovative, etc. NSF, NIH, and DARPA problem sponsors can. Ph.D. supervisors can. Successful Ph.D. students can. Research professors can. But I don't see Ben as able.