Cold Evaluations

I exchanged notes with a couple of people that I used to work with while at Big Blue, and I must say, I'm feeling a little guilty.

While I'm happily semi-retired, doing baking, house-cleaning, and reading, both of them -- and, from what I gather, another as well -- are trying to garner new employment after being summarily (more or less) ejected from the warm corporate embrace of IBM. They're finding it difficult, and, from the tenor of the notes, dispiriting. One, an experienced security administrator, is taking a class on coding Medicare claims; a second is working as a real-estate agent, and the third is taking a class on the ASP programming language. All three have easily a dozen years working in the support and implementation of the IBM security product; all were kicked out because IBM felt they didn't want them around. Objectively, I find that hard to understand.

I understand why they might not want me around. I wasn't particularly talented at the job. I did what they asked me to do, and asked good questions as needed, poking and probing for the intellectual pleasure of doing so, but I never relished the job as they did. I said, multiple times, that I was a techie, not a security person, and so when the time came to lop off security people, I was an obvious candidate.

But these people were not. I can't even fairly say that they were middle-of-the-pack folks; based on what I know of their abilities, they were probably about two thirds to three fourths of the way up the food chain (I was probably about fifty percent). Two of them didn't have much desire to understand the internals of the product (which is what you need to get the rest of the way up), but that didn't matter, because IBM didn't make it possible for them to learn those internals. They kept that restricted to the small club of people who were doing it, and had been doing it for years. Eventually, of course, that club would need new members, as the existing ones died, transferred, or just grew stale, and since you can't just show up and be productive in a job like that, it seems obvious to me that they'd want to bring new talent in every so often, either just as a trial --- let's see if these guys have the right stuff --- or as a way of preparing them for an eventual transition. It's possible that such things did happen -- but if they did, I never heard of it. That surprised me on an ongoing basis -- where's the mobility, the growth in this field?-- and it surprised me when we were told Thanks for being here, now scram. Me, I could see, but not these guys.

The only thing I can think of is that IBM was hard up for money, to the point where they really believed they could do the same work with fewer people (certainly not literally the same work, but the essential core of that work, sure), or they thought that they needed the same number of people, but those people could be found more cheaply elsewhere. That song's been sung elsewhere, either lyric. Its possible that such a decision would be supplemented by their managers' literally not knowing what these folks did -- what value did their function bring to the organization. And that brings me to the thought about evaluation. Its usually difficult, and for someone in a software job, its frequently impossible.

For example: how much is one hour of a software programmer’s time worth? The standard answer is that it depends on the market. There’s no objective evaluation. It gets trickier when you think about two software programmers. If it takes one SP an hour to do something, it doesn’t follow that it would take another one an hour to do the same work – and it absolutely doesn’t follow that two could do the same work in a conjoined half hour. People who aren’t programmers don’t understand that. As in so many other things, Dilbert said it best, when the manager observed that he didn’t understand what it was that the engineers did, so it must be easy. To be fair, programmers think the same of managers.

I don’t know what drove IBM to this point. I’m glad that I was already edging toward the railing, preparing to jump; I’m sorry for those who were still in their cabins, eating dinner, when the ship hit the iceberg. I hope that these actions don’t affect the company’s ability to succeed; at least, not too much. (There would be glum pleasure in seeing them fail, at least a little.) A better answer would have been for the company management to be insightful and proactive; to learn how programmers think, and to show programmers how they were evaluated, and how they would selected, when the cutting starts, so that they, jointly, could keep from that point -- and provide advance warning, as needed. Hire smarter, not more frequently. Evaluate with insight. And on the other side of the equation -- learn the business. Remember that it exists to make money; higher revenue and lower expenses are inherently desirable.

But that, I expect, might be too much to ask, of either side.

==============
Passing note: Apparently, I'm able to turn out a halfway-decent English muffin. Who knew?