Data Mining Moves To Human Resources 262
theodp writes "Just when you thought annual reviews couldn't get worse, BusinessWeek reports that HR departments at companies like Microsoft and IBM are starting to use mathematical analysis to determine the value of each employee. At an undisclosed Internet company, analysis of (non-verbal) communications was used to produce a circle to represent each employee — those determined to generate or pass along valuable info were portrayed as large and dark-colored circles ('thought leaders' and 'networked curators'), while those with small and pale circles were written off as not adding a hell of a lot. 'You have to bring the same rigor you bring to operations and finance to the analysis of people,' explains Microsoft's Rupert Bader. Hey, who could argue with what Quants did for finance?"
Not necessarily bad thing (Score:3, Interesting)
Often, the problem with companies is that information doesn't get spread around. People work on their own projects in secret, never bothering to spread their knowledge. Perhaps this will urge some of the those to pay some attention to being useful for other employees as well, as opposed to just getting their own little project done.
We'll all be gaming this before too long. (Score:5, Interesting)
I would joke that this could be a good thing, in that, we'll just game the review system to get raises.
The reality is, though, that the more corporations seek to control and monitor their employees, the more they will crush the entrepreneur in them. Corporations work best when they motivate people and you do that by creating a positive, team culture that gives its participants a sense of mission. Take that away, reduce people to cogs, and you are going to get cogs as a result, and you'll get an inevitable decline. What enterprising person would want to work as an anonymous cog, coming out of college with a degree and history that says they are anything but, when they could make a real difference at a startup.
Actions like this doom large corporations, and frankly, this sort of thinking was what alienated the big 3 for a lot of people, and now they want to do this to the computer industry?
Stupid, stupid, stupid.
Useful to convince under performers (Score:3, Interesting)
Re:Human resources? Bah (Score:3, Interesting)
I work at a company that employess about 400 people, perhaps a few more. I have an empoyee number but its just something the accounting department is concerned with, it shows up on pay stubs and once and a while elsewhere like on a benifets form. I certainly would not be able to tell you what the numbe is without going to look for it. I doubt HR could either; they would likely need to ask accounting. I can talk the HR folks any time I want. Our HR director and her assistant know pretty much everyone by name.
I don't think at 400 people we are tiny or useless.
Not every company in the world recudces folks to just numbers.
Yeah... Sure... (Score:3, Interesting)
I currently do chemistry work that I report on paper to get entered by others or tell verbally to someone by phone. I think I've sent three emails at work so far this year.
By this measure I am of no value and a temp who does data entry is a national treasure. (That may be true, but it doesn't follow from this analysis.)
Guess I'll have to start responding to those weekly email tag fests of "who is going to bring what to the Friday pot-luck lunch". It may up my stats, but it'll probably add to my waistline.
Re:Yes it is... (Score:4, Interesting)
There's a huge and erroneous misconception that centralization makes a corporation more efficient. I think centralization is a cancer. (...) The fact of the matter is, that the thing that matters most in any corporation is time to market. It doesn't matter if you are centralized and more "efficient" if it takes you two years longer to ship a late product out the door, because while your smaller competitors were signing stuff and building things, your own design was going through committees and signoffs to make sure that you weren't doing what someone else already did.
Let's try with a little IT analogy (shocking, I know). The "everyone do their own little thing" are the dreaded small VBA applications hacked up in Excel that have no architecture, no signoffs and just pop up all over the place. Or the IT networks where companies are on five different versions of Office and Exchange in a million configurations all running on wildly different hardware and environments depending on what the local IT guru at the time found at Best Buy. I've been in projects where we gathered up the investments being done in all the different business units and realized several of them were working on projects for the same thing because noone had any idea what the others were doing.
On the other hand, I've also been where using an unapproved application or making a configuration required sign-offs to make the Vogons proud. I haven't been that much into beurocratic application development but I'm sure there's places you go crazy over trying to get a change through the archtiectural review subcomittee to get the interface in the common corporate component toolkit changed. Funamentally it's the same challenge the MBAs have, how much should we have a central control and how much should we let everyone do their own thing. It's easy to be an armchair MBA and think you got all the answers because you don't see the actual implications. I'm sure there's many MBAs that think they'd make great IT policy too.
I can smell this from a mile away (Score:3, Interesting)
Does anybody doubt for a minute that the first thing managers will do is exempt themselves from being evaluated this way? The only thing this "tool" will be used for is to intimidate employees at evaluation time, or when they're looking for a raise.
Re:Rejecting mathematical methods? (Score:3, Interesting)
Parent post should be modded up. There is something to be said for using a rigorous methodology when comparing the value of different employees, and that will necessarily reduce to numbers at some point.
That being said, TFA is either seriously oversimplifying what its author learned, or the companies it describes are doing it wrong.
TFA is basically describing ways of developing and presenting sociograms. The shape of any sociogram is as dependent on the choice of qualitative tools used to develop it as it is on the reality that it claims to represent. To be brief, any sociogram, no matter how numeric its appearance, is qualitative and not quantitative and has a huge amount of observer bias built into it. It is a tricksy sideshow mirror that reflects an unstated bias and is inherently untrustworthy.
I've been trying to find a way to say more without ending up as tl;dr and I can't do it adequately. So here are some teasers:
The first steps to effective HR management involve developing good job descriptions of the existing roles. Performance measures can be used to determine how well HR has done this work: do those who actually work in or with each role agree with HR's description? The next steps involve reshaping the company as a whole by changing all of those job descriptions to support the new workflows. Some of this can be quantified: your employees represent a pool of very detailed knowledge about how the jobs could be done.
Only after the above is done can you start looking at employee performance, both current and predicted in the new roles. Very little of this is truly quantifiable: about the best you can do is to say "On a scale of 1 to 5, how legible is Mr. Anderson's handwriting?" And even then, recognize that some of the most critical information may be very hard to come by.
An example of the last: Do you know that you have an entry level programmer that everyone goes to as a technical resource because he has twenty-plus years of extensive experience leading development teams, but now he's satisfied with a low pressure day job to pay the bills while he writes his first novel in the evenings? His LOC stats are miserable, because he spends a lot of time with drop-in visitors who are wondering how he would approach this bug, or refactor that monster object, or shed some light on what the hell the guys who wrote this legacy code 15 years ago were thinking about when they used that schubert approach on what is clearly a brahms problem? You probably don't want to lose this guy: he is improving the efficiency of everyone around him. But he is not going to show up favorably on any of your metrics. And in a dirty professional field like software development, he and his kind are legion.
Re:Yes it is... (Score:2, Interesting)
Let's try with a little IT analogy (shocking, I know). The "everyone do their own little thing" are the dreaded small VBA applications hacked up in Excel that have no architecture, no signoffs and just pop up all over the place
Has the thought ever occurred to you that all of those little applications actually solved problems for the business?
t's easy to be an armchair MBA and think you got all the answers because you don't see the actual implications.
There's only two kinds of people a company needs: people that make things and people that sell them. MBAs do neither. They don't sell, and they don't make. There's no value-add, so there is no point.
A truly clever developer will create code so easy to understand that a less than average developer could debug it.
Only if it does not impact time to market of the product. Average developers need to step up and get better.
Re:Next up: Collateral Employee Obligations (Score:2, Interesting)
Re:Yes it is... (Score:3, Interesting)
I think the larger story is, really, that management education in the United States is a colossal failure. There is no reason that a large and previously successful company needs to decline and fail when other civilizations created empires and institutions that lasted for hundreds and thousands of years. But as it is, in America, as soon as a founder leaves a company, the MBAs get in and these "professional managers" slowly sink the ship. It doesn't have to be this way, but it will be this way until we get some serious curriculum changes at our management schools. That's right: HARVARD, WHARTON, YALE AND OTHER MBAS : YOU F---- SUCK!
I did my PhD in Computer Science, and I teach MBA's (who have to make a thesis and ideally publish it). The first thing I say in class is that "science is too important to be left in the hands of scientists, so in this course there will be no quick formulas or little case studies". We will study science, including the mathematical and computational aspects. Is anyone able to program a computer in, say, java? Is anyone a mathematician or engineer?
Here's what is sad: (i) almost all other professors will be gossiping like a mexican soap opera about you, and how you don't understand things; (ii) most students, INCLUDING those skilled, seem to want an easier ride. Almost all see programming as undesirable, something for lower-level people. Others want to go to, you've guessed it, finance. By the way, my course is on cognitive science and decision-making, and we move from behavioral economics to computational modeling, AI [slashdot.org], and math models of the brain.
Don't know how I haven't been fired yet.
Re:The whole premise is bullshit. (Score:3, Interesting)
What I quoted is from an actual test of civil engineers. NONE of them got it anywhere near right - the best were off by 50%.
Note that most will use a fudge factor to make sure that there's enough safety in their predictions/estimates - but that's not the same thing as saying "you can undecut so much and no more - it will collapse at that point +/- x %.
Case in point - the engineers scoffed when I told them to build a trench box, despite excavating with no more than a 45% slope, when we were doing near-vertical cuts everywhere else on the project. The reasoning was simple - the absence of older trees in the area to be excavated for the main sewer collector cut. Obviously (to me) the area had originally been much lower, and had over the years been a convenient dumping ground for earth from other work while the city was under development. They scoffed, pointed out the delay, but built it anyway - and the plumbers who were in the trench to make the final connections still almost shit themselves when a small portion of the slope that wasn't sloped to my recommendations collapsed. And here we're talking about a cut of no more than 20' into the earth, not the 60' high pile of unconsolidated earth in the example.