Friday, February 24, 2012

Where Do Bad Managers Come From?


On a recent flight out of Chicago, I found myself seated next to Jack, a IT manager in a medium-sized company. Jack was on his way to interview for the IT manager in a larger corporation. He explained that he had reached the limit of his present job, and his only chance to advance himself was with a company with a larger organization.

"Why don't you stay with your present organisation and move into general management?" I asked.

"That was my goal when I took this job three years ago," Jack said, "but there's not a chance. The president of the company sees me as a technical specialist, lacking skills to become a 'real' executive. So I'm looking for someplace else, where I'll be appreciated."

"But three years isn't a very long time with one company," I said. "Perhaps they don't feel you've had enough time to prove yourself to them."

"I've done a lot for them in three years, but they don't appreciate how much work it takes to manage in the present crisis environment."

"What do you mean?"

Before I could hear his answer, one of the cabin attendants came by to ask for our choices for lunch. She beckoned the other attendant to come over and refresh our drinks. By the time all the fuss was over, we had our lunches, but I had forgotten their was an unanswered question still suspended between us. But Jack hadn't forgotten. He seemed eager to dump his woes on me while I picked at my sirloin tips.

"Technology is changing every month, and I can't find good people. It's impossible to keep a technical staff together long enough to make improvements in present systems, let alone keep up with the new technology. Junior programmers demand inflated salaries, and if they don't get them, they jump ship to some other company that is desperate enough to pay them. And senior programmers ..." He stopped talking and unrolled his cutlery.

"What about senior programmers?" I asked.

"Why talk about it?" Jack said bitterly. "There's no sense even thinking about hiring a senior person, let alone starting to search for one. You give them the moon, and a year later they want the sun. They seem to think they could get rid of us managers and run the place without us."

I could see why Jack was so bitter. In effect, he was being squeezed from both top and bottom. His management did not want to let him advance, and he felt the pressure of his own employees trying to advance up from below. Still, I had a hard time feeling sorry for Jack. I'm always suspicious of managers who speak badly of their employees.

I almost told Jack the Army saying: "There are no bad soldiers, only bad officers." Instead, I dipped the tiny spoon into my dessert custard. I had a feeling Jack wouldn't appreciate Army wisdom.

Of course Jack has problems with employees. But a manager's iob is to deal with such problems, so if Jack complains about bad people, he's telling me he's not doing his job. Jack says his people were leaving for better salaries, but salaries are roughly tenth on the list of reasons technical people switch jobs. The first reason they leave jobs is poor management. Probably the second and third reasons, too.

Jack himself was leaving his job because his own management did not understand him. They would not give him the opportunity he thought he deserved, nor would they guide him to the self-improvement he needed to advance his career.

Jack complained that his bosses never supported his requests for management training, but when I asked him about training his own people, he said: "Why invest in training them? They are going to leave before I get a return on my investment. My staff is turning over at a rate of 25 per cent a year. Technical people have no company loyalty whatsoever."

By changing jobs every three years, Jack himself was "turning over" at a rate of 33 per cent a year. His management, knowing that "technical people have no company loyalty," refused to take Jack's own executive aspirations seriously.

Jack, like so many IT managers, was locked in a "disloyalty cycle." His management did not take him seriously as a person, so he was not loyal to them. Because he was not loyal to them, they refused to take him seriously as a person. In his own career, Jack was modelling the problem he was having with his own staff.

Not every IT manager has Jack's problems. Some have broken the "disloyalty cycle," or stayed out of it in the first place. They are not panicked by the pace of technology, but insist on developing their own employees.

They may hire experienced people, but do not try to "buy" instant expertise. They know that the expertise they buy is more likely to be bought again by someone else. They have excellent technical staffs, with low turnover, but their pay scales are merely competitive, not exceptional.

Their employees tend to be loyal to their companies because they know their managers are also loyal to their companies. One of my clients has a IT manager who budgets a minimum of 20 days per year of training per employee, and woe to one of his managers who fails to reach that minimum for each employee. He does not "waste" this investment because most employees want to stay at a company that actively demonstrates loyalty to them. Sure he has some turnover, but around six per cent, rather than Jack's 25 per cent. Moreover, he tends to turn over the people he would rather lose, rather than the ones he would rather retain.

IT managers like Jack cannot have it both ways. If they want to become "real" executives, they will have to start acting like real executives. That means taking responsibility, rather than blaming their employees. It means developing good people, not trying to pirate them from other companies and then griping about how other companies are pirating from them.

But Jack does not have time to develop his employees. If he does not get promoted in three years, he will not be around to reap the benefits of his investment in them. He will be out looking for a new job that will show him more "loyalty."

"Real" executives take the long view. They are the kind of people who, at age 60, can be found planting trees. IT managers who think that fast moving technology requires short-term quick fixes are stuck in a middle management mentality. They will never become real executives.

Managing Yourself and Others

Wednesday, February 15, 2012

Where There’s a Will There’s a Murder

I've been slow posting on this blog for the past few weeks, and now you know why:


I've been finishing the next novel in my Residue Class Mystery Series: Where There’s a Will There’s a Murder




You can buy it now for Kindle, Nook, or at Smashwords for any other reader format. Just click the link above.


Note on PSL 
Problem Solving Leadership Workshop for May is almost full. We are considering a session for the overflow, so if you want in, get in touch with me right away. Jerry Weinberg

Wednesday, February 08, 2012

WIGGLE Charts—A Sketching Tool for Designers (Part 2)

Wiggle Charts (Part 2)

Perhaps the nicest feature of WIGGLE charts is the way they can be used with just about anybody's diagrammatic technique.

The following figure shows a Hierarchic WIGGLE, or a WIGGLE Visual Table of Contents (WVTOC) for use with a HIPO system. In this application of the WIGGLE, the overall size of the boxes can be used to indicate (roughly) how big an effort we anticipate in building this box. Alternatively, it can be used to approximate how much execution time or other resource we expect to be consumed here.


A WIGGLE visual table of contents from a HIPO system (Each box has input on left end, output on right.)

The next figure shows a Nassi-Shneiderman WIGGLE. In this chart, the size of the wiggles in the diagram indicates roughly how uncertain we are of the particular part of the design. 


A Nassi-Shneiderman WIGGLE
The vertical loop wiggle is quite small, perhaps indicating we're not sure if the loop is to be done N or N+1 times. Similarly, the slanted wiggles on the decision are small, indicating perhaps we don't yet know just where the "equal" case will go. But the large wiggles dividing the right branch of the decision into three boxes are very large, indicating great uncertainty about the functions to be performed here.

All these conventions may be applied to sides of boxes, regardless of the shape of the box, as well as to arrows or other lines connecting boxes. Each of these charts should be sufficiently "clear"—as sketches—to readers who can read the original, unwiggled, chart.

Just for completeness, the next figure shows a key to the use of the WIGGLE. Using this figure, you should be able to begin sketching your favorite design pictures using the WIGGLE, even if you're still in love with good old flowcharts.


The WIGGLE system condensed to a few simple rules applicable to any graphic scheme

Source
This material is adapted from my book, Rethinking Systems Analysis and Design.