This list is a sad thing for me, a former Project Manager, to review. It’s not because I failed to do these things; it’s because, on the rare occasions on which it was really up to me to run a meeting, I did do them and they probably weren’t helpful to my career. In fact, the only thing on the list I didn’t do, which is to bring munchies, if I did that I would likely have gotten into trouble. I can just hear management asking “did you, or are you going to, expense that?” with no correct answer to the question possible.

Other people who were so-called Project Managers were clearly more in keeping with what my organization wanted, and enjoying a boost to their careers…although many of them hit the unemployment line as quickly as I did. They did not do anything on this list. In fact, they did the opposite. And this “helped” them…I guess. They got their positive strokes, their approval.

I suppose when the mediocre performers are employed just as long as the people who are really trying, and the merit increases barely keep pace with inflation, there’s no “right” or “wrong” way to do anything. Process over outcome, folks. World’s becoming more vaginized. Still & all, if I had to do it over again, I wouldn’t do it any differently. If you want to stand up for what’s right, make the best possible use of your time and everybody else’s time, and really give it your all to make sure the project is a success, act-like-you-own-the-company and all that — this is pretty good:

Establish whether the meeting is absolutely necessary. Before you even think about scheduling a meeting, figure out if you really and truly need one. You should only call for a meeting if:

* The information to be discussed could not be disseminated via telephone or email. Meetings should never be called when only a one-way information exchange is needed.
* There are clear benefits to having everyone together in one room.
:
Type up an agenda for the meeting with a specific list of what items will be discussed and in what order. Email everyone a copy a day or two before the meeting to give them a heads up about what to expect and some time to start thinking about the issues and what they’d like to contribute. People can also make additions and objections to the agenda before the meeting instead of at the meeting. Make it clear in your message that if it’s not on the agenda, it can’t be discussed at the meeting. Paste the agenda into the body of the email. People don’t open attachments. [emphasis in original]

And I really, really like this thing down near the bottom. A whole lot.

There are 3 different ways to set up a meeting room: the U-shape, a circle, or lecture style…The circular, uber-democratic, let’s hug it out style has been in vogue for awhile now, and it makes everyone feel important, but it’s also the reason meetings get off-track and become totally unproductive. The truth is that not everyone does have something important to say, and a leader is crucial in keeping things focused on the things that matter.

You know what is a great example of what he’s talking about here. Thunderball, the scene where Number One calls out those two guys who didn’t make as much profit as they were supposed to, and fries the one that was skimming off the top. Not “fires.” “Fries.”

I really detest the round table marathon. I think everyone with a working brain hates it. Anyone who’s been there for any length of time, can make the connection: That’s next year’s raise that’s paying for this circle-jerk. Oh goodie, ol’ Windbag McWindbaggerson to my left, wants to point something out that nobody’s thought of before…oh, you’re so important Windbag, go for it Windbag, don’t leave any detail unexplored.

The problem isn’t that the Project Managers don’t know any better. The problem is one of incentive. There really isn’t any such thing as a good Project Manager or a bad one. So the problem, I think, really exists in the layer above; the PM role is viewed as one of purest bureaucracy. It isn’t acknowledged that this PM over here really excels at making the most of staff time, and this other PM over there really sucks at it. Instead, the PM’s stewardship over a particular project is seen like a gallon of vegetable oil — a can is a can is a can, no difference amongst any of them.

It’s really more like a waiter. This guy can effectively work three tables, that guy can work five, it’s simply not do-able to take on more than seven, so don’t try. If I had my way, they’d earn their wages like waiters; they’d exist on tips. These are crucial people. If they can’t multi-task and manage details and make the best use of an hour, then nobody else can either.

My-Way-Itis (n.)

A mental disease.

It is, quite plain and simply, an inability to comprehend a situation in which some other person might take charge of a familiar task, and by implementing methods the observer would not have used, acquire beneficial results. It is an irrational conviction that the observer’s way is not only the best way, but the only way, to achieve the stated goal.

In the advanced stages it becomes paranoia: Anyone who’s doing things differently from the way I would be doing them, must be acting under sinister ulterior motives.

The technology business tends to see more than its share of this. It moves through stages that seem like fresh-blazed brand new trails at the time, but with the benefit of hindsight one realizes it’s all the same old turf:

Phase One. A youngster is discovered who can demonstrate his ability to do neat things most other people cannot do. Executive or capitalist opportunists cluster around him, he discovers a livelihood, and a fledgling industry is assembled around what amounts to nothing more than a boy’s parlor trick.

Phase Two. The business interests find out, through a series of painful exercises, about the yawning gap that exists between a business process and a parlor trick.

Phase Three. Out of a desire to close this yawning gap, a premiere value is placed upon the commodity that is the Idea-Man…the guy who has strong ideas about how to do stuff. Not quite so much how to do the stuff, but having strong ideas about how to do the stuff. A candidate who shows a strong track record of getting things done on time and under budget, but doesn’t talk too much about how he does them, is not valued quite so highly. Another candidate who lacks the strong track record, but talks quickly, loudly and forcefully about the steps involved in doing things — and who identifies all who would do things a different way, as potential enemies — is valued much more highly.

Phase Four. Once all the projects of any magnitude or importance are managed solely by people with festering, advanced cases of My-Way-Itis, the business goes through new pains.

An interesting aspect of My-Way-Itis is the degree of willingness — even enthusiasm — with which the sufferer will knowingly depart from reality. He labors under the unspoken conviction that anybody who doesn’t follow his ready-made-script for success, will have to fail. Confronted with an example of someone who got ‘er done a whole different way, he makes absolutely no effort to revise the paradigm he just spoke aloud that was instantly debunked; instead, he will regard this alternatively-completed successful project as some kind of evil thing, something that can be the source of absolutely nothing good, something that must be banished. Much in the same way the villagers of olden times might have ostracized a suspected witch, or had her burned at the stake. He becomes the fox in Aesop’s fable about the “sour grapes.”

Another notable symptom is that once the patient is put in charge of weighty responsibilities dealing with the allocation of staff, he starts to show a myopia with regard to understanding specialties; his mind neatly categorizes talents according to “the things I do” and “the things others do,” the latter being completely fungible. In other words, one hour of whatever it is John does, is equal to one hour of whatever it is Susan does, which is equal to one hour of whatever the hell it is Charlie does. And so the business that has been entrusted to him, deteriorates from one extreme to another: Coming into existence specifically for the purpose of making use of a little boy’s parlor trick, it suffers a senile dementia to such an extent that it cannot appreciate a potentially-profitable parlor trick if the parlor trick walks up and bites it square in the ass. After that, it must suffer all the pains attendant to any business that has forgotten what it is in the business of selling; and these are not paper-cut pains. They are life-threatening.

I imagine I’ll be accused, with some legitimacy, of venting my spleen over some specific unpleasantness that occurred within one particular experience. The truth is darker than that: I don’t have any one single experience out of my twenty years that fits this better than any of the others. Except, perhaps, for my very first jobs…in which I was the inexperienced young boy who knew the parlor tricks. I’ve seen this play out, over and over again, in pretty much every position I’ve been placed in as I watched it from different vantage points, playing different roles. Wherever I worked that this did not happen, there was at the very least, a very powerful pull in this direction. The pull is always there, in any business in which a service is needed but not yet acquired. It’s tough to think in moderate, realistic, self-restraining terms about the Holy Grail that is still out of reach, especially when dollars are on the line.

So for all the above reasons, I suppose management by the insane is ultimately unavoidable. A business finds out a parlor trick doth not a profit center make — and then, tragically, it overcompensates, putting the inmates in charge of the asylum.

Computerworld…

I can sum up every article, book and column written by notable management experts about managing IT in two sentences: “Geeks are smart and creative, but they are also egocentric, antisocial, managerially and business-challenged, victim-prone, bullheaded and credit-whoring. To overcome these intractable behavioral deficits you must do X, Y and Z.”

X, Y and Z are variable and usually contradictory between one expert and the next, but the patronizing stereotypes remain constant. I’m not entirely sure that is helpful. So, using the familiar brush, allow me to paint a different picture of those IT pros buried somewhere in your organization.
:
It’s all about respect

Few people notice this, but for IT groups respect is the currency of the realm. IT pros do not squander this currency. Those whom they do not believe are worthy of their respect might instead be treated to professional courtesy, a friendly demeanor or the acceptance of authority. Gaining respect is not a matter of being the boss and has nothing to do with being likeable or sociable; whether you talk, eat or smell right; or any measure that isn’t directly related to the work. The amount of respect an IT pro pays someone is a measure of how tolerable that person is when it comes to getting things done, including the elegance and practicality of his solutions and suggestions. IT pros always and without fail, quietly self-organize around those who make the work easier, while shunning those who make the work harder, independent of the organizational chart.

There’s certainly something to this, although I have to question the “always and without fail” part of it. All in all, on balance it’s one of the most accurate and dead-on articles I’ve ever seen about management in the technology field, if not the most.

If you’ve booked the conference room for an hour, and forty-six minutes into it the business is all settled — adjourn. Adjourn now.

If you tell the guy you’ll have his discs back to him by three, get them back to him by one-thirty.

Give credit to the guy who came up with the idea, by all means. But also give credit to the unsung hero who ironed the bugs out of it.

If the guy works all night and leaves things a small disaster, but if he didn’t work all night it would have been a huge disaster, make sure the big boss knows all about the huge disaster that might’ve been. Don’t assume people know about this stuff.

If the guy does something positive for your project he didn’t have to do, you do something positive for his career you didn’t have to do. No exceptions.

Everywhere “a bunch of work” exists, there needs to be a list saying what it is. If there’s a bunch of work somewhere with no list saying what it is, the work will be tripled…and talented dedicated people will be paid for about one hour out of every two. See to it the list gets made. Do it yourself if you have to. Make sure people know when they can stop working something over, and move on to the next thing…just like you want a firefighter to know when a fire’s out, and he can turn his hose on to the next thing. That’s really what these guys are. Firefighters. Make sure they have water, and they know where to spray it.

Every minute your technical dude has to spend talking to a pissed-off customer about why the pissed-off customer’s demands played second-fiddle to something else, costs your organization four times. The pissed-off customer is losing time thinking he’s talking to someone who can do something for him, when this is not the case; the technical guy is losing time he should be spending working on whatever took the greater priority, instead listening to a pissed-off customer; the thing the pissed-off customer wants worked over, is lying around in limbo, gathering dust, rather than sitting in a stack in the second slot from the top which would be a much better place for it; and I’ll be willing to bet there are a few more technical people working under the technical guy who’s talking to the pissed-off customer, waiting for him to tell them what to do, which he can’t, because he’s busy…you know the drill. Stop the insanity. There’s customer-relations stuff and there is technical stuff. YOU talk to the customers so the technical guy can do what he’s there to do.

Oh, one other thing. You need to jump in if the same people are always asking the same questions, about the same things, of the same people.

Thing I Know #148. Reassurance is a funny thing. People crave it. The more they get, the more they want. Eventually, it becomes impossible for anyone to get anything they want or need, without making one or several bogus reassurances to someone about something. I have noticed when the same people are summoned to provide the same reassurances to the same people over and over again, the next thing that happens is never good.

It’s a fire-fighting business. Learn to smell the smoke.

I don’t talk much in these pages about my work, and that is perhaps the one sound, high-quality, survival-instinct-oriented decision I have ever made as a blogger. Don’t like to poop where I eat. Naturally, that is the one from which we shall backpedal today.

Volunteered the following during a very rare participation from Yours Truly on LinkedIn. By the way, if you work for a living and haven’t joined LinkedIn, do it today. I don’t care if you’re a construction worker, or embalmer/medical examiner, or sex worker. Great repository of all kinds of nuggets of information you can actually use.

Anyway, on the subject of writing quality code…

There are four tiers of quality code, and no I’m not going to cite my source because this is the product of personal experience.

1. I wrote it, it does what it’s supposed to do, I’m so glad we’ll never have to change it because I never want to look at it again. Just like getting done with this year’s taxes.

2. I wrote it, it does what it’s supposed to do, and if you want it to do something different I’ll be able to work in a new feature so fast it’ll make your head spin. But you’d better pay me whatever I want because woe be unto the poor dummy who takes over my job and has to spend the next two years getting “up to speed” with my variable names, class construction, indent style, lack of internal documentation, etc.

3. .I wrote it, and I made sure as I went along to stop and ask myself “If I was a new guy would I need to have this explained” and then I dutifully added the explanation. An experienced developer seeing this code for the first time shouldn’t have to fight too much to figure out how to address any documented defects and do more harm than good…although the expectations for “ramp time” should always be somewhat reasonable.

4. In an effort to acquire and maintain a certification for the ####.###.## standard and comply with the new AAAAAAAAA regulation that goes into effect next year, my company has gone through this code line-by-line and added documentation blocks wherever they are required. Which is everywhere.

I hasten to add there is a correlation between good internal documentation and easily-maintained code that is something like dolphins and fish and things that live in the sea…internal documentation, where it makes sense to have it, is required in order to make the code reasonably maintainable for anyone who doesn’t work with the benefit of personal design-to-implementation familiarity — but all “well” documented code is not necessarily maintainable. The internal documentation is just a tool, nothing more. Too much of it gets in the way. And if put on a new project, I would feel much better about things and do a better job justifying my paycheck if I were working on Tier 3 code than on Tier 4 code.

The composition of the code needs to be consistent in order for quality code to work its way up this tier-ladder. There is overlap between the requirements of the project, and the features to be used in the language(s); if that overlap is diminutive, it will be a challenge to produce quality, maintainable code because the software will be providing focus trying to bridge this gap between what the language provides and what the resulting application is supposed to do. A good architect therefore needs to leverage the strengths of the language, produce coding standards that implement this leveraging, and see to it they are enforced.

I see nowadays the languages have become so capable, that the responsible software architect needs to start making some decisions about what language features NOT to use. This is a somewhat new development, but I see a future in which it will become more and more necessary.

This touches on a beef I have had for a few years, and I think I wrote about it in these pages. Maybe I did and maybe I didn’t. However, if I had to guess about whether I did or not, I’m inclined toward the negative…so for now I shall not trouble myself with doing a search so I can provide a link. I think such a link does not exist. Could be wrong.

But here’s the itch I can’t scratch —

The trend I have been noticing is that software developers, together with the people on higher levels who have the responsibility of managing what they do, just love to bitch and piss and moan about how the code is not well documented. I find this to be reasonable, so far. Poorly documented code leads to questions where there should not be questions. People tie up their time asking the questions, then answering the questions, then misinterpreting the answers, then writing code based on the incorrect misinterpretations of the answers and then destroying the code and taking another crack at it — this all costs time. And therefore money. Copious amounts of both of those.

Now, when it is time to get together and discuss who’s excellent in this craft, versus who is simply mediocre, how is the rating done? Understandably, it is done according to who best facilitates an avoidance of the above frustrating and expensive cycle. And here is where things start to go awry: Software developers start to be evaluated in doublets, triplets, groups. If, when they get together, complex thoughts are syndicated quickly, reliably, and without error…this has the effect of bringing credit on each individual within that group, and if the pattern can be maintained then they will all feel a perceptible career boost out of it. Still and all, at this point all is fair. They are contributing to the bottom line of their respective employers and they are being plied with the rewards for that contribution. This is the essence of capitalism. Nothing wrong with that, huh?

But there is something wrong with it: Software developers, as a general rule, write down only what has become indispensably necessary to write down, and not a single word more than that. It is the work, you see; there is always more of it to be done, than the staff hours allotted to it.

When a group of them enjoy all the benefits attendant to belonging to one of these tightly-knit grouplets, and the demand for their services starts to exponentially ascend due to this success — the first thing that happens is shit doesn’t get written down. Where’s the necessity? Where’s the incentive? Both are gone.

Contrasted with that, if you get two teams together who don’t speak the same way, but they absolutely-positively have to learn how in order to get the job done…things get written down. It’s gotta be that way. This team over here is accustomed to counting 1 to n, that team over there is accustomed to counting 0 to n-1. So before things start working, the technical documentation gets produced and it bears a distinct resemblance to exactly the stuff people bitch about when it’s not there. That’s the way things are supposed to work. But along the way, friction is produced, and with that there is some heat…and it brings discredit on the individuals on both sides of the divide.

So they end up not getting promoted. Even though they’ve gone through the real trials and tribulations of not just making things work, but defining how they need to work. In writing. Which has a bearing on bringing these solutions to market, effectively and profitably. Career-wise, though, they lose out to the “Furbies” who can syndicate with each other by these invisible beams, and because the Furbies can syndicate so effectively with each other, they end up pooling their resources toward the objective of making things actually work. Without writing anything substantial down. Producing, rather than documentation, a dearth of it. For people to bitch and piss and moan about later.

To distill all of the above down to its essentials — we say we want something, and then if you extrapolate what we want by who we promote and who we do not, what we “want” turns out to be the exact opposite of what we say we want. To distill it further — we seem to be laboring under the impression that if we promote those who show signs of this elusive “empathy,” all the pieces will somehow magically fall into place.

The tragedy is not far removed from the damage we are doing to ourselves in national politics, when we choose our leaders. So-and-so possesses this elusive ability to “communicate,” so if we choose that guy, all will be well and we won’t even have to mess with any of the details to make things well.

It’s a fool’s dream.

And as far as software development is concerned, the case can be made that the greatest talent is to be pooled up in those who possess shitty communication skills…at least, when one confines one’s inspection to those who have successfully delivered on the things they were building. After all, the people with shitty communication skills were forced to define the details so they could get them properly communicated, were they not? They had to break things down to their essentials, which means, they had to understand those essentials. The “brilliant” communicators didn’t have to do this, they were able to achieve the right “vibe” about such things, in wholesale, without breaking anything down…so they weren’t forced to comprehend all the atomic elements.

I should mention they probably did understand such things, at some level. To achieve a mastery of both human communication and technical nuts-and-bolts, is not a negligible task by any means. These are very bright people. Very bright. We’re talking Mensa stuff here. They can probably whip the ass of anyone you can care to name at a game of chess.

But if it’s about business — you get a more valuable asset, at the end of it all, if you task people or groups of people who are required to define things down to the inseparable atomic parts, before things start working. It might not seem like it at first, because more time is put in during the initial stages and there’s little payoff for it.

But my point is proven when people start bitching away about the lack of documentation.

It is proven, even further, when developers start leaving the project and have to be replaced. All the “Furby” benefits of these sociable Mensa chess-player types communicating on their invisible beams…they are histoire. What’s being missed is that the method of syndication is endemic to the genius types conducting it. They move on, it moves on. And this is not a concern easily dismissed. The nature of genius is that it isn’t like mediocrity; it is way down at the far side of the bell curve.

Let’s be clear on my meaning here: This is not advice to profile people. We’re all trying to make a living, and whether they benefit from the invisible beams of the “Furbies” or not, has no correlation against the honesty of the associates working to earn the paychecks or the lack thereof. At least, no correlation upon which I will comment here.

The point is that when people communicate in whatever form, it is a messy process. Things don’t get defined any more specifically than they have to be. My advice, therefore, has to do with treating the developers the way a responsible tester treats the elements in a test script: Build according to the worst-case scenario. On purpose. At least some of the time. If you work too efficiently at it, you’re not getting the job done. Do it so you get those specifics.

The specifics, in the final analysis, are where the money is. It is an information business. The information, therefore, is where the gold sits — whether the stakeholders keep this in mind or not.

Read one CIO’s tale of woe, and come to your own decision about how much of your sympathy he can claim…

As the depressed economy lurches along an uneven bottom, I have been trying to selectively upgrade key areas of our team with new talent to get ready for the eventual recovery.

We are training our existing staff in technologies that will progressively reduce our operating costs, but I had been expecting to find experienced workers to speed up the familiarization and assimilation process.

It’s not happening.

Not only am I not finding the people I need, some of the few that I have recruited aren’t sticking around for very long. This is troubling.

Whenever we’ve looked to hire new staff — in good times or bad — we’ve been deluged by resumes of people who did not seem to have read the requirements. It’s as though someone is running a search-and-match engine that uses any vague similarity between what we need and what a candidate claims to have done.

Our own scanning technology eliminates a lot of these resumes. (I have never liked automatic filtering much, so we look at some of the automatic rejections to make sure we aren’t missing a hidden gem.) But we still waste a lot of time screening candidates by phone and in interviews.
:
So, two questions: Where are all the good people? And why are we seeing so much turnover in a supposedly poor job market?

I’ve been looking at these issues for a few months now, and I’m starting to see some patterns, if not answers, in our data.

First, a lot of people are going freelance. I can rent them, but not hire them. They don’t seem to care about (or maybe believe in) “corporate” benefits such as health insurance or 401(k) plans or even performance bonuses. If they have a hot skill, they are willing to roll the dice on being able to keep busy even in bad times.

I have employed several people who work this way. The arrangements can be mutually beneficial, but the complexity of managing a work force that’s less “loyal” (and less accountable) taxes our managers and systems — and may not be sustainable in the long term.

Second, a lot of the skills we need are scarce, and the people who have them — and have jobs — seem reluctant to move, even for more money. Other employers I have talked to see the same thing and most are willing to match an offer to keep the skills in-house.

Third, those who are willing to move keep on doing so. Even if I find someone who will quit to join us, he or she is probably going to do the same if another offer comes along.

It’s as if the available population is dividing into three groups: independent, static and mobile. I really haven’t seen this before — especially not in the three past recessions I have had to manage through — and it’s causing us to rethink some of our resourcing strategies.

When you’ve built an operating model that depends on ready access to skilled technologists and the skills aren’t there, problems loom. We’ll need to get ahead of these challenges quickly if we are to build an organization that’s ready to grow when the recovery arrives.

Well, whaddya think? Can you manage to shed a tear?

My own reaction: Well, he seems to be appropriately inquisitive, but he can’t cover up the nagging sensation he obviously has that maybe he’s overlooking something. And I think he is. We have a lot of technology employers, and recruiters as well, wondering how it is that the “talent” is so hard to find. And yet at the same time we have a lot of “workers” in the force looking for a place, wondering if they’re in the right field, or if it’s time to move on to something different altogether.

We got both of those problems. Something’s obviously busted.

Check out the comments, though. They’re loaded up with input from the folks on the other side of the table. They say they are probably the qualified folks for which the boss has been looking, but many of them have had to move on, get into real estate, go get law degrees, whatever. Not much sympathy. A goodly chunk of venom.

Quit IT because of this stupidity at 8-15-09 @ 10:52 am EST, speaks for me in a comment that was much more civil than most:

Here’s why you can’t find people

1) We need these 15 skills, you only have 14, not qualified.
2) That 15th skill is an obscure 30 year old loader program that no one uses or has hear of anymore
3) We will not train or have you learn that 15th skill, we need people who “hit the ground running”
4) Your experience is in C sharpe, but we need C pound sign!
5) No security clearance, no job, no exceptions.
6) H1B’s work alot cheaper because they have no mortgage and did not go to college so have no student loans.
7) Your resume says SQL but our resume scanner is looking for sequel.
The problems are with the idiots doing the recruiting, the great people are right in front of your noses.

My story is one of gradually migrating into IT from software engineering, and then because of the same frustration these folks found, going back to software engineering. Isn’t software engineering part of IT? If you think that’s so, then I guess I ultimately prevailed and managed to make a living again, after making a months-long pursuit out of something that should’ve been a routine job search. If engineering and IT are different things, then it would have to be said I hit a career-ending cul de sac as many others did, and fortunately fell back on some skills I developed many years earlier.

It really doesn’t matter though. There’s a horrible problem churning away deep under the surface that affects those who seek the talent, as well as those who have the talent and are seeking the work.

People whose job it is to get the talent-demanders in touch with the talent-suppliers, are woefully underqualified. I remember talking to one who was asking if I had such-and-such training. I just came out and asked her: I’ve been doing exactly the work your client needs and I’ve got positive references to show for it, and yet nobody asks if I did a good job at it, they ask about my training. What kind of training do you recruiters have? Frankly, that seems to be more the issue here.

She agreed.

I think the CIO hit the nail on the head halfway through his tragedy. “Our own scanning technology eliminates a lot of these resumes. (I have never liked automatic filtering much, so we look at some of the automatic rejections to make sure we aren’t missing a hidden gem.) But we still waste a lot of time screening candidates by phone and in interviews.” Here’s the problem that’s causing grief on both sides: If 50 resumes is a manageable number but 500 is not, then anything that knocks out 90% is a “good” filtering system. Be it a keyword search, be it the “wrong” answer to a written interview question, be it…anything that doesn’t land you at the wrong end of a discrimination suit. Just get the number down, and don’t worry about how.

The boss knows about this. He looks at some of the automatic rejections to make sure they aren’t missing a hidden gem. But when he’s sanity-checking a process to carve an impossible number down into a smaller, possible number…this just amounts to a partial backpedaling against a rejection process that he knows doesn’t work. He’s figured out the automatic filtering has failed to win over his confidence, so he’s implementing only 99% of it.

The problem isn’t that nobody’s qualified to do the work. The problem is that nobody’s qualified to figure out who’s qualified to do the work.

Meanwhile — the IT profession is not just staffed with kids who are looking for something to do during the summer, and know something about rebooting servers. These are adults who are still paying off student loans, putting down payments on houses, having kids of their own, putting together college funds for those kids…all that good stuff. They need to make a living.

If, every single time it becomes necessary to land another gig, after all the training and all the experience and answering all the questions right, it’s a matter of hoping the ball lands on black-seventeen…there comes a time you have ask yourself the hard question: Is this making a living? And so the promising field of car insurance beckons, or maybe it’s time to chase that other dream of opening a smokehouse restaurant. Then we get more weeping and wailing from CIOs who can’t find the talent. Perhaps they got rid of the talent themselves, and didn’t realize it at the time.

I had no idea there were so many different opinions about the right formula. What a mess!

Cracked. Some language not appropriate for a work/family environment…

Maybe it’s you. Is your problem really so stupid? Not really. If it seems like the level two tech is barely even able to feign interest in what you’re saying, it is because he’s barely able to feign interest in what you’re saying. But it’s not you. They just hate their jobs and, by the transitive properties of unfocused job place hatred, they hate you too.

I’m liking what I’m reading here. Still lots of room remaining for a possible enormous disappointment regarding Windows 7. But this seems to me, at first blush, a heartily sensible way to design an operating system. And, pleasingly, it’s not the Microsoft I’ve come to expect.

To design Windows 7, Microsoft analyzed billions of pieces of data. It studied exactly what PC users do in front of their screens. It tallied hundreds of thousands of Windows surveys. It got feedback from people all over the world who tried different versions of the software.

As a result, every change or new feature in Windows 7 comes with a back story. Here is a sampling of things you’ll see in the next operating system and explanations of how each came about.

What I like here is the presumption that, without a formal study process put in place and then vigorously pursued, Microsoft does not know its user community. And that’s not a slam against Microsoft (although it’s true, by-and-large). It’s just true of all intellectual pursuits: You need to maintain an accurate assessment about what you do & don’t know. And err on the side of acknowledging your limitations.

I’ve been a professional computer geek for twenty-one years now…most of it in software development…and if there is one thing I’ve learned in all that time, it is this. There is a reason why the truly talented software engineers have a reputation for possessing crappy communication skills. And it’s not the reason people expect.

The reason is, this stuff we call “excellent communication skills” get in the way. Think about what they are. They are empathy. And empathy is — talent in conveying and receiving ideas informally. Mental telepathy, body language, chats by the water cooler, whatever ya gotta do.

Over the short term this seems like a wonderful deal. Generically intelligent people working together cohesively: Who can possibly criticize that? But over the long term it hurts, and it hurts a lot. Documentation ends up not being written. I’m not talking user manuals. I’m talking about internal specs…and when internal specs don’t get written, people feel like they can modify stuff when it suits them. The result of this is that the new Module A worked fine, but ended up in the trash heap because it depended on Module B and Module B didn’t hold still. Testing ends up being done inconsistently, and then people don’t want to admit it happened. There was no test-script, you see. Two guys who worked together so well and made such a great team, implicitly understood what “Does It Work?” meant. The criteria weren’t defined for the benefit of new team members. And the new team members did show up…count on that…because fewer questions are asked with greater frequency than “Well, can you meet the new deadline if you have more people?”

People engage other people to get things built on by proxy, “knowing” it’ll get built a certain way, but not really knowing that at all. Generally speaking, people who are ingenious at finding these sixth-sense ways of communicating with their known peers, exude a recalcitrant resistance against writing things down. Friendships, thought to be a foundational layer to the business of getting things built, end up displacing the business of getting things built.

Worst of all, “key” people are key because they “know” the customers need this feature or that feature. When in reality, if you bother to go asking, you find out the customer hasn’t the slightest idea the feature is there, and doesn’t care about it. I’ve seen this. I’ve seen it dozens of times if I’ve seen it at all.

And Microsoft’s been a worse offender than anyone. An application or operating system becomes the de facto standard across the entire western hemisphere, and then they upgrade it. Across the time zones, millions of voices cry out in unison the same thing: “God dammit, there was a way to do this…where the hell did it go??” And…”So frustrating…I know what it is I want to do…I’m burning up the better part of an afternoon arguing with this Microsoft piece-of-crap about doing it.” And…”Chrissakes, this used to take two keystrokes, how come now it takes seven??” Answer: Microsoft assumed you were using it this way, and not that way.

And MS-Word 2007, I’m looking straight at you.

Damn, that felt good.

Yet another dialogue we need to be having right now, that we aren’t having: What does it really mean to educate a child? What are we doing about it? Whatever education we’re providing for them, what does it have to do with forming a vision, designing a solution, and using what’s available to implement it, in ways nobody has ever tried before?

You could always fall back on teaching the toddlers how to be bubbly, engaging, outgoing, cheerful and precocious. From time to time, though, we can all use a reminder that the world doesn’t work solely because of the Guy Smiley folks that are fun to watch. Really, when you get down to it, they’re just here for entertainment…appreciated most fully by people who aren’t getting work done.

Technology is the opposite of adhering to protocol and convention. If we become too obsessed about doing things the way they’re “s’poseda” be done, and being fun to watch so that everybody pays attention all the time, technology can stall. If technology stalls, a whole lotta jobs go away…more than most people think.

Hat tip: Gerard.

I’ve been demoted, or promoted, depending on your point of view. I guess the money should determine that, and the money says I’ve been promoted. At any rate, I don’t have to give PowerPoint presentations quite so much anymore, except to other engineers once in awhile. Friendlies. So maybe this is something I’ll never really need…but you never know.

I kind of miss dealing with executives. You shouldn’t be put-off from dealing directly with someone you know, beyond the shadow of any doubt, understands a great deal more than you do about some things…and is still looking to you to provide some missing piece they don’t have quite yet. It’s healthy. Most executives — all of them, I would hope — have the business sense to hound you like the worst sonofabitch straight out of the gates of hell if you’ve got it coming, and still like you personally and hope for the best out of you next time. That is, of course, what your boss is supposed to do; but that’s quite a bit different.

Back to the “sins.” He missed the big kahuna: Reading the text of the slide to the audience. If PowerPoint presenters understood how people talk about that later on, they’d do whatever it takes to keep from falling into the pit. Everyone either throws their pens and notebooks at the screen and storms out of the room…or wishes that they could.

I’ve been very close to this whole subject for about a decade now, so much of this list came as very little surprise.

I did not have any expectations of seeing #2 or #3 on a list like this though. And I was somewhat shocked at #9, but that has to do with not staying up-to-date on what’s going on with that particular specialty.

“Change is the only constant.” — Heraclitus