Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've seen memory drains during down-turns in the economy. The company will offer the oldest, most-experienced, highest paid employees a buy-out or they'll offer them five years extra pension/retirement if they leave now. Mgt figures that consultants can be hired if they ever need X, Y or Z done again at a fraction of the cost of the employees.

Many senior employees accept the offers, and then later mgt realizes that 95% of their Fortran or Cobol (or name your old programming language/product) experience has vanished. Thank god the software is mostly in maintenance mode, but client problems do still arise and what once took 15 mins to fix, now requires a week and phone calls to retirees begging them to help fix a client problem. They'll pay them loads of money too just for a few minutes of work.

Consultants turn out to lack the domain specific knowledge required to fix the problem.

Bottom line is that sometimes, mgt is so focused on hitting short-term financial goals, that they lose site of the big, long-term picture. Business needs less 20 something MBAs who only see this quarterly report and more managers who understand that business is a decades long proposition and that senior employees are key to maintaining an edge and passing along knowledge.



It's easy to blame the popular meme of "short sighted management", but they aren't necessarily as short sighted as you think.

Often management gets rid of the old guard because the old guard actively prevents the business from improving it's processes. I know someone (maybe multiple people) who works at a large financial institution. A particular department there is running on ancient systems using ancient processes, most of which can and should be properly outsourced to $BIGVENDOR. The fed agrees, and is constantly hitting them with MRIA's (Matters Requiring Immediate Attention).

But right now there are many managers of 50-100 employees who will become redundant when 49 of their employees are replaced by a few servers in NJ. These people tend to passive aggressively slow down the replacement, hoping to delay it until they retire. There are other people who have stable jobs, based not so much on competence as the fact that they hold lots of institutional memory. They don't want to help build a system that will make their knowledge obsolete.

When management fires these people, it doesn't do so because it doesn't understand their value. It does so because they are actively hindering the company from moving forward.

Sometimes this process fails as you describe. But when properly managed, this process results in a streamlined department half the size it was before, processes properly documented, everything automated, where people are fighting to improve efficiency from 99.7% to 99.9%.


I downvoted you for framing someone's observation as a generalization, and then trying to argue about it.


I upvoted you because you explained your downvote. Anonymous voting is what I like least about Hacker News. I prefer that people vote publicly. On my own site, I'm about to start offering actual cash (very small amounts, mere pennies) to people who explain their votes.


I would be interested in learning how that experiment goes. Social hacking fascinates me and at one time I spent quite a lot of time performing "private" experiments/tests with regards to influencing forums/email lists. I would be especially interested in seeing a write up done beforehand as to your logic/reasons for doing it and what you hope to achieve and then a write up afterwards to see what the actual results were. The information is a lot less valuable/interesting to me if there is no beforehand piece of it, put in writing before actual implementation. However, it probably should not be published until you get results, just written down. Publishing it could contaminate the data as it could influence the outcome and make it impossible to tell if the money or the article was driving change.

Best of luck.


That is a great idea. And I understand the need to keep the prediction secret till later. I just wrote this up and sent it to you as an email. We will see how things work out over the long term.


+1 to documenting the hypothesis+ prediction and the results.. I would love to see that too.. yep.. am ok with not publishing the hypothesis first too..


This depends a lot on what time frame a business is planning for. It used to be industrial businesses were planning for 30-75 year timelines; now it seems rare to find an MBA who cares about 10 years hence.

If what you care about is the health of the business in a year or two, the chances that that institutional knowledge will be important is almost nill. It is only if we had a way to prioritize lasting value that this becomes a management concern.


It's not always that. Sometimes (especially in smaller companies) the technical staff just leaves. Sometimes they get better offers. Sometimes they go off to start their own company.

I know some of what the OP is describing. I'm dealing with a system that's got three layers, each written in a different programming language. It was written by a pair of very brilliant programmers, who were unfortunately rather bad at documenting. They left the company when an after-hours project they were working on turned into a viable business opportunity.

When I deal with this system, I can piece together the what, but the why often escapes me, only to bite me later when I try something and it fails horribly. Luckily, I'm only dealing with software. I suspect that it'd be much more costly to deal with failures in OP's case.




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

Search: