All Posts in Policies and Procedures

|In: Leadership|Last Updated:

I have, in my day, gone through lots of leadership training.

I’ve learned how to recognize excellent personal and team performance with recognition and a variety of financial and non-financial incentives. How to deal with difficult situations, like personal crises, policy violations, substandard performance, and terminations. How to facilitate meetings. Delegate tasks. Coach employees who make mistakes without demoralizing them.

Serious stuff.

I have to be fair. I’ve also received training in how to provide small rewards and incentives as morale-builders, such as T-shirts, pizza, or tickets to movies or plays. The small stuff is important in creating an atmosphere where good work and good attitude are appreciated.

But in all my training, I never once heard anyone talk about the single most common situation most managers have to deal with: Minor infractions.

I’m heartily sick of the phrase, “… potentially leading to termination.” Regular readers will recall an employee who received a one-week suspension without pay for sending a joke over his company’s e-mail. As Mom used to say, they made a federal case out of it.

Have you established techniques for dealing with minor infractions? Small stuff like lateness for meetings, dead-horse-beating in discussions, or slightly too long lunch breaks? It’s important to do so. If you let minor matters go unchallenged, they eventually grow into significant problems. On the other hand, if every time you see some trivial problem you call the offender into your office for a solemn conversation, you’ve established an image … as a pompous twit.

So if you can neither ignore the problem nor counsel the offender, what can you do?

I learned the answer the hard way. After a reorganization I walked into the weekly staff meeting of one of my new teams 5 minutes late. Another attendee, who’d apparently arrived 4 minutes late, breathed a sigh of relief and said, cheerily, “You bring the donuts next week!”

A front-line supervisor in a company with whom I’ve consulted has a similar strategy: When someone breaks the rules he holds a “kangaroo court” and when the accused is found guilty they impose the cookie penalty. You guessed it — the guilty party has to provide cookies for everyone.

Donuts or cookies, it was minor, good-natured, expected, and public. Since the penalty directly benefited the team it boosted morale in the bargain, even if it did harm the aorta a little bit. And these are the keys.

Keeping your penalties small emphasizes your own sense of perspective. Mom would have approved — no federal case.

Keeping the atmosphere good-natured reinforces the desirability of an open, casual environment where you don’t lead by intimidation.

Unlike rewards, where inventiveness is the key, minor penalties should establish a team tradition. Traditions are important in building teams, just as with any other kind of community.

It’s important to publicly razz the trouble-maker in this kind of situation. You get to make the point to everyone that whatever the behavior is, it isn’t appropriate. You again reinforce an open communications environment where nobody has to measure every word they speak.

It’s important for the penalty to benefit other team members, which is why desserts are such a great punishment, as is making the guilty party take notes at the next meeting. Since the offender does something good for teammates, the sentence amounts to community service and builds up the team (whereas each minor infraction incrementally damages team cohesiveness).

And although some companies (for example, those whose IT departments gripe about screen-savers) don’t seem to value it very much, you get to make the workplace just a wee bit more fun.

Maybe you’re the kind of sourpuss who doesn’t see the value of all this. If so, I have the perfect solution.

You get to bring the next plate of cookies.

Comments

|In: Career Management|Last Updated:

If the road to hell is paved with good intentions, why do we need so many deadly sins? As with the afterlife, you can fail in the tough job of managing Information Systems even with the best of motives.

If you really want to get into lasting trouble, though, you have to work at it. Here are seven surefire suggestions — admittedly less fun than the real deadly sins—for getting yourself mired right in. Another difference: With the real deadly sins you’re generally off the hook if someone else commits them. You’re guilty of the Information Systems Deadly Sins if any member of your organization commits them.

That’s what leadership is all about, isn’t it? So, let’s dive right into our cesspool of systems malfeasance to find out how you and the rest of your organization can go straight to perdition.

Sin #1: Arrogance. Arrogance is a lot like pride, the unforgivable hubris of legend. And like hubris, arrogance taints your judgment by blinding you to your own limitations.

Systems arrogance takes many forms, so look for the symptoms. Do you hear help desk analysts swapping dumb user stories, or using the popular acronym RTFM (Read The Friggin’ Manual)? Then you can bet your bottle of Pepto Bismal end-users gripe about the “helpless desk” while they long for the days when they bought their own PCs in defiance of IS.

How about your systems designers? Do they complain about users who are unable to reach consensus on system specifications just before they start another endless argument over the best way to map their normalized data model to the persistence layer of their object class hierarchy?

Arrogance is a veneer — a thin covering of excuses hiding deep performance deficiencies. As penance, develop a cultural exchange program with key department heads, and have the offending analysts work at end-user jobs for a few months. Even if they don’t come back humbled, they’ll understand a bit more about the business.

As an alternative, force every analyst who sneers at an end-user to memorize the instruction manual for your VCR.

Sin #2: Grandiosity. Systems professionals engage in systems thinking. Be thankful for it. Part of systems thinking is extending ideas to their natural boundary.

Unfortunately, there’s a sort of one-upsmanship that goes along with this, so if one analyst generalizes the need for a purchasing system into something that covers the whole raw materials life cycle, the next one will extend it further to Computer Integrated Manufacturing. The one thing everyone agrees on is that the person who requested the system is too narrowly focused, and that failing to design for the bigger picture will result in colossal expenses a few years from now.

End-users call this “designing the universe”. It makes them nervous because they thought of the project in the first place, and now some arrogant systems know-it-all (see Sin #1, above) is expanding it into a monstrosity that can’t be built.

As penance, assign the offending analyst to work with Marketing to implement changes to your Web site. Since Marketing asked for the changes last week and wants them in a month, that should break the grandiosity habit.

Sin #3: Project-itis. In medicine, the suffix “-itis” refers to inflammation or swelling. Project-itis refers to a systems manager’s desire to sponsor a Big Project.

This sin is closely allied to both grandiosity and arrogance, but where grandiosity came from a sense of design and arrogance from self-doubt, project-itis comes from a desire for self-improvement — in the career sense, that is. The sponsor of a big project is looking for a promotion: probably to CIO, most likely in a different company, and almost certainly halfway through the project, just when the cracks are starting to show.

Big projects are a sin because anything longer than nine months is forever and will never happen. Projects only succeed when there’s a sense of urgency, so your project planners should break every big project into manageable chunks that stand on their own.

In the meantime, you have to establish a penance for managers exhibiting project-itis. Make them manage the help desk for a while — that should do it.

Sin #4: Jargon. This is the sin of analysts needing to demonstrate they know something end-users don’t. Why use an perfectly good old word when a new one sounds better? That’s especially true if your key end-users have diligently learned to communicate with your analysts.

So, when end-users bought into structured analysis, it was important to introduce JAD and RAD, so you could patronizingly explain that they stand for Joint and Rapid Application Development, respectively. What if the end-user pointed out that you’ve been designing applications jointly for years and it’s been your analysts who have insisted on doing it the slow way? You get to explain that this is different, because there’s a methodology behind it, which is jargon meaning some consultant wrote a book saying it’s okay to do it this way now.

Jargon has to evolve, because the old words end up attached to discredited ideas. There was CASE (Computer Aided Software Engineering), for example which was just perfect for huge projects that never saw the light of day.

So when CASE went out and objects came in, it was perfectly natural to introduce “Use Case Analysis,” introducing a flock of new an useless terms. Here’s what makes Use Case Analysis especially groovy: Its proponents claim credit for inventing the idea of working directly with end-users instead of tossing requirements over the transom — I am not making this up — and they also explain that, unlike traditional forms of systems analysis, Use Case Analysis and the resultant creation of object class libraries deal with normal business concepts.

If you hear your fully buzzword-compliant analysts spouting off to a group of end-users, the penance is clear: Assign them the task of creating a systems glossary. After they finish, compliment them on its quality — and heck, they did such a good job you’d like them to keep it current!

Sin #5: Methodologism. No, not Methodism — we’re not talking about trivial issues like religion, we’re talking about the important matter of adhering to the methodology.

Since nothing gums up a perfectly good methodology like project deadlines and an emphasis on actual business results, methodologists are quick to emphasize that in the long run the methodology will pay off, usually in reduced maintenance costs. Methodologists often commit the sin of project-itis too, since they stem from the same cause — a desire to build an impressive resume to make departure to the next company easier and more lucrative.

Penance? Buy into the methodology … but cut the preferred tools out of the budget, because “We had to choose between buying the tool for you and your two team members or hiring a dozen programmers, and we need the programmers now.”

Sin #6: Control. “We can’t let the end-users do X. If we did, Y might happen!”

The sin of control is expressed through a variety of unappetizing behaviors. A favorite is the creation of unnecessary standards, and an emphasis on enforcement rather than end-user benefit. The creation of standards is not, of course, a sin. The relationship between standards and control is the same as the one between eating and gluttony. One is necessary, the other excessive.

Key to control is prevention. If you hear conversations about how to best prevent end-users from loading their own software, building their own applications, or invoking their spell-checker without first obtaining permission, you’ve got it bad. A sure sign: lots of discussion about headaches, none about business benefits.

As penance, make a speech at your next staff meeting emphasizing the importance of IS setting the example. After all, like Caesar’s wife everyone in IS must be above reproach. So anyone within IS who violates standards and policies will be subject to immediate termination.

Sin #7: Supplier Mentality. Who do you work for? Do you view yourself as part of the company, or as an independent supplier?

The supplier mentality is expressed through unwholesome behaviors and attitudes. Do you view other parts of the company as your “customers”? Do you ask your customers to sign formal contracts? Do you negotiate system features with them as part of the process?

If so, you’re a supplier, not a partner. And as a supplier you don’t need to worry about doing penance. You need to worry about being outsourced — that is, being replaced by a better supplier.

* * *

Okay, so these “sins” have been overstated, but every one can sabotage your relationship with the rest of the company, so they’re worth the exaggerated emphasis. It’s your relationships that represent the foundation on which you build your success. Your behavior and that of everyone in your organization either reinforce that foundation or tear it down.

There’s only one way to choose the right path: Don’t sin.

Comments