Hacker News new | comments | show | ask | jobs | submit login

"At one company I used to work for, I also saw my leadership completely lose their minds and fire off all of the development staff, thinking we could coast with a new sales team and the product we had and pull ourselves into profitability."


I watched this particular face-plant occur once as well. When they actually got customers the results were hilarious. Hilarious because I was not a direct employee, mind you.

It was like having a high-end trendy restaurant with excellent branding, great decor, a great location, and no food. So they run across the street to McDonalds and order fifty Big Macs, run back over, dress them up on plates (who will notice), and...

Running out of money sucks, but this maneuver was destined to fail from the get-go. Anyone who knows anything about tech could have told them that. One smarter alternative would have been to lean the development staff -- they had to -- and hire a small number of salespeople on contract (not full time) and offer them disproportionate bonuses to bring in sales.

What they actually did was fire anyone who knew how to make anything -- and in a way that burned bridges! -- and hire a bunch of sales guys full time and at full salary. Hilarity ensued.

Did the guys at the top ever lose any money?

What usually happens is that they've locked in some preferential options or stock grants + bonuses etc.

If the company hits it big despite them, the stock is awesome.

If the company does poorly they might miss a bonus but they'll still get their inflated salary.

If the company ends up on the rocks, they'll get their salary cut "till company performance improves" as their pay is usually tied to the performance of the company as an incentive.

But what invariably happens is that, even with their pay tied to company performance, the moment it gets cut, they high tail it out of there and land a new job with their top-10 MBA and another couple years of job experience...saying "I'm looking for growth opportunities" over and over again in their interviews.

I don't know if it's still true, but Facebook used to filter out these types by making them do a version of an engineering interview. Except instead of regurgitating algorithms you learned in college, MBAs had to regurgitate stuff from MBA school. Like derive the time-value of money, or discuss the TPM or whatever. The ones who coasted through MBA school got filtered out really quickly and the ones who took the subject seriously might pass the gauntlet.

But what about the people investing in these companies? Money don't grow on trees and you can't make money without products to sell.

Investors bank on most of their investments not succeeding, and the few that do making up for the rest.

The truth is, nobody knows how to bottle "success" and reproduce it -- but in a sense that's what management school is trying to do. With just the right management approach, applied in just the right ways, you can get Instagram instead of Color, or Google instead of Cuil.

The problem is that it's very easy to look at the failures and pick apart the problems. But it's very hard to look at the 1% that succeeds and figure out why -- and when it's attempted it usually overlooks the cases where the company succeeded despite having many of the problems the failed companies had.

Most companies succeed because of 90% dumb luck and 10% business strategy.

(hell, business is so screwed up people still don't understand how to define success. You see it here all the time that a "successful" startup is one that raises a huge round, not one that's profitable and growing...even BusinessWeek does this)

Early stage startup investors expect most investments to fail. Those investing in mature companies expect their investments to do well over many years. I'm sure MBAs have plenty of stories of incredibly inefficient companies that have squandered opportunities. MBAs aren't about growing startups, they're about taking the now $1bn Instagram and doing more with it.

I'd also ask them if they know when to use and when not to use these concepts.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact