←back to thread

581 points antr | 1 comments | | HN request time: 0.305s | source
Show context
donw ◴[] No.6223679[source]
Few people remember it, but the same thing happened at HP. It used to be that HP engineers were expressly given Friday afternoons and full access to company resources to just play with new ideas. Among other things, this led to HP owning the printer market.

Then "professional" management came in and killed the proverbial goose. They had to focus more on the "bottom line". To do what was easy to measure and track, rather than what was necessary for the next step of the company, and now HP is a mere shadow of its former glory -- directionless and bleeding.

3M and Corning have largely avoided this fate, but it seems that Google won't. This should make a lot of entrepreneurs happy, as there will continue to be a lot of top-down management-driven products that, if history shows, will continue to be market failures. Yet somehow, I'm incredibly sad, as it seems that too many companies go down this road.

replies(12): >>6223710 #>>6223758 #>>6223782 #>>6223788 #>>6223813 #>>6224099 #>>6224119 #>>6224329 #>>6224628 #>>6224913 #>>6226352 #>>6227439 #
api ◴[] No.6223710[source]
It boggles my mind, given the big money involved, why so many people continue to bet huge sums of cash on the proven short-term penny-wise/pound-foolish idiocy of MBA-think.

I mean sure-- if your company is under cash flow pressure you have to pinch pennies. You have no choice. Spreadsheet says so, and spreadsheet's the boss. But if you're not, you should be investing and thinking long term cause the other guys probably aren't.

I've seen a related phenomenon in the startup world. Watched it, front row seat. I did a stint in startup-tech-focused business consulting. If you have a top-ten MBA and connections you can raise millions of dollars, set fire to it like the Joker in Batman Begins, and then raise millions of dollars again, serially.

They were basically cargo cultists, mindlessly imitating the words, phrases, and superficial behaviors of supposedly-successful people and businesses. But there was no higher-order conceptual thinking beneath the surface-- no "there" there. They had no plan and no plan on how to acquire a plan. They got the money and then did a kind of mindless MBA rain dance until the money was gone. Then they'd raise more.

I watched them do shit like destroy products that big customers had money in hand ready to pay for when they were inches away from release. I mean a done product, ready to go, and better than anything else in its market. A product that they owned and had already paid to develop. The rationale was always some kind of MBA newspeak blather. I can't even remember it since my mind filters out sounds that imitate language but lack conceptual content. Otherwise I risk wasting a synapse.

But what do I know? I went to a po-dunk Midwestern state school, so what looks obviously stupid to me is maybe genius. I'm not saying I definitely could have done better, but I do think my probability of failure would have been <= to theirs. But there is no way in hell I could get what they got. Not a chance. I saw people try with better credentials than me and who were probably much smarter, but they lacked whatever special magic blessing the cargo cult guys had.

I'm convinced its pure cronyism and ass-covering. I guess nobody ever got fired for losing their clients' money to a Harvard or MIT Sloan MBA. Nobody with a degree like that could be at fault. It has to be the employees (I've seen really good people get blamed for following stupid orders several times), bad market timing, etc.

replies(23): >>6223875 #>>6223893 #>>6223901 #>>6223916 #>>6223925 #>>6223943 #>>6223992 #>>6223998 #>>6224016 #>>6224193 #>>6224215 #>>6224339 #>>6224349 #>>6224399 #>>6224681 #>>6225139 #>>6225367 #>>6225500 #>>6225508 #>>6225519 #>>6226889 #>>6226927 #>>6227446 #
Spooky23 ◴[] No.6223992[source]
From a management perspective, you're forgetting about the obvious: the less than productive people. The benefit of giving employees no- or few-strings attached time to work on whatever is clear. Things like GMail, Apple 1, etc. The "cost" is that people are doing things that don't necessarily contribute to the bottom line -- for every GMail, there are 1,000 low-impact ideas.

When your ability to make money hand over fist starts to get challenged, it is difficult to continue giving people free reign, especially when your competitors focus on cost, cost, cost. HP was a great place that made oodles of money selling tank-like PCs (among many other things) that cost $3k. But then Dell came along, invested $0 in R&D and started cleaning HP's PC clock. Bell Labs was engineer/scientist nirvana, then the AT&T monopoly went away.

The other issue in big companies is that as people with direct connections to the business start losing control, the bureaucrats (well intentioned as they are) start moving in, and they worry about things that the engineers/etc didn't really care about. They are passionate about you using the appropriate powerpoint template, and will speak to your supervisor if you don't comply!

replies(9): >>6224040 #>>6224187 #>>6224340 #>>6224352 #>>6224384 #>>6224469 #>>6224632 #>>6225732 #>>6227906 #
JabavuAdams ◴[] No.6224040[source]
Re: productive people. We have this notion of the 10x producer, but the real problem is high variability within the same person's work.

I know productivity superstars, but if you catch them on the wrong day or at the wrong time, they look like lazy bums. Over a year, they're extremely productive. On any given day, they may look like they're wasting time.

This property of conceptual work is at the core of a lot of culture clash with people who have more predictable work-comes-in, work-product-goes-out flows.

replies(3): >>6224268 #>>6224405 #>>6226104 #
Silhouette ◴[] No.6224405[source]
I know productivity superstars, but if you catch them on the wrong day or at the wrong time, they look like lazy bums.

I've encountered a particularly nasty variation of this since Agile became a Thing, where anyone who isn't writing code or running tests or showing up in the commit logs every few minutes obviously isn't working. The idea that it might be better to step back for an hour, or a day, or even a month, to think things through properly and maybe do some throwaway prototyping before you start pushing code to production, doesn't even seem to be accepted as credible any more in some quarters.

replies(2): >>6224707 #>>6226235 #
api ◴[] No.6224707[source]
Agile / Scrum is the return of the K-LOC:

http://en.wikipedia.org/wiki/Source_lines_of_code

People don't recognize it as such because the LOC -- lines of code -- has an added time dimension now and a different name. In Agile / Scrum it's K-(issue/day) where issues take the place of raw lines and the metric is applied per unit of sprint duration.

But same idea, and same fallacy. It results in gobs of ugly Rube Goldberg machine code that's slow for fundamental O(crap) reasons and bug-ridden.

replies(1): >>6226170 #
1. saidajigumi ◴[] No.6226170[source]
"'Agile.' You keep using that word..."

An org that calls what it does "agile" or "scrum" and then proceeds to accumulate technical debt like the Titanic taking on water is lying to itself about what it's doing. Piling up technical debt is a textbook Agile(flavor) failure, full stop.

What sounds like happened in the case(s) you describe is that someone with dev management preconceptions wore "Agile" like a wolf in sheep's clothing and proceeded to dole out the same old ad-hoc nonsense. Nonsense as in being "efficient" (high KLOCs/metrics, butts in seats, long hours, etc.) and not caring about being "effective" (working on the right problem vs a problem, necessary understanding of the company and customer needs, working smarter vs. simply harder, etc.).

I've seen this attitude a number of times, e.g. in program managers with history in big, established s/w companies. They learned a certain way of working, but then talk "Agile" as the trendy hire-word. Unfortunately, some of these folks never gained understanding of the tools that Agile brings to the table, and when/how to apply (or not apply) them to a situation.