The Parable of the Christmas Lights

A Holiday Allegory for Information Technology

Growing up, as I recall, the otherwise festive Christmas holiday season held forth the dreadful prospect of wrestling with a box full of Christmas tree lights.

Ignoring the fact that it’s cheaper and easier to replace them each year, perhaps as a matter of honor and tradition, it had become my family’s policy that no new tree lights would be purchased until every attempt had been made to untangle and revive the old ones.

In keeping this tradition, I found myself in the same familiar mess every year as I set out to decorate our house with lights. No matter how carefully I may have coiled and packed them away at the end of the previous year, the many separate strands of lights seemed somehow to have found each other during the off-season and hopelessly entangled themselves. This made me angry, as though they’d deliberately, even spitefully, knotted themselves into a perplexing mass of bulbs, plugs, sockets, and wires.

So, as punishment every year, I dealt with them the same traditional way. I shook them vigorously, hoping somehow that the individual strings of lights would repent and separate themselves from each other. When they didn’t, I dived aggressively into the middle of the knot, pulled at it from within, stretched it, embraced its confusion and became a part of it. Eventually, one by one, each string of Christmas lights would somehow drop away from the others, until, at last, mission accomplished! But the achievement was always more by accident than design, and never without my fair share of pain.

Still, primates being what they are, even the tiniest and rarest success will strongly reinforce habitual behavior, the bad habits as well as the good. As I looked with pride at the untangled lights, each individual strand now laying on the floor vanquished and submissive (a few literally broken as well), next year’s application of the mindless “shake and hope” method, notwithstanding its obvious stupidity, had been assured.

Breaking with tradition is never comfortable, but, one year, for a change, I deliberately calmed myself down and thought about the problem first. I reasoned that, in years past, I had concentrated too hard on the problem’s most obvious in-your-face aspect, that infuriating knot of bulbs and wire. In anger, I had traditionally attacked it, literally, from the inside. This may have felt good, but it got me nowhere. After a lot of shaking and complaining, the problem eventually solved itself, but the solution always took longer, and broke a lot more light bulbs, than it needed to. Looking back, my “tradition” was really just the bad habit of injecting energy blindly into a confused situation, hoping for the best. Eventually, when a solution finally presented itself, it was only at random. A paint shaker could have done as well.

That year, a little deliberation made all the difference. Knots, I reasoned, are best untied from the outside, by first finding the parts of each string that aren’t in the knot, the ends, the terminal sockets and plugs of each separate strand. One by one, I found and threaded the ends out of the knot. Gradually, the un-knotted ends became longer and longer, as the knot ─ my problem ─ became smaller and smaller, until, eventually, it was gone.

It was tedious and a little boring pulling those ends out of the knot one at a time. Emotionally, this new approach was less satisfying than shaking and tugging at the knot until it finally learned its lesson and fell loose. Still, for achieving predictable results economically, the systematic start-with-the-ends approach beat my traditional flailing-away-at-the knot method hands-down.

Questions

• Where does an IT communication network “begin?” Where does it “end?”
• How can an IT specialist’s narrow technical point of view cause her to get lost in the “knot?”
• Privately inventory some of your bad thinking habits. What are you doing to break them? Or, do they feel so good to you that you'd rather not?
• When addressing technical issues, counterproductive emotions like anger and pride can feel like reasonable behavior. Why is this? How can we overcome it? How can organizational leadership help?

_______________________

The POInT Organizational Transformation Program helps diagnose and correct the cognitive biases that can prevent IT professionals and teams from finding and solving the root causes of technical problems. Work smart. Learn more at:

http://point-cmc.blogspot.com.

And, Happy Holidays!

The Parable of the Beach

I remember playing outside my home one bright summer morning, a very young child surrounded by all of my happy little friends, when my parents approached me with a proposition.

“We’re going to the Beach today!” they pronounced through broad smiles.

I was only five years old, had no idea what “the Beach” was, and, besides, I was having a grand time with my friends in our yard. So, I politely passed on the opportunity and kept playing.

That’s when my parents pulled out their PowerPoint slides and started their pitch.

The Beach

• Water!
• As far as the eye can see
• You can walk or swim in it
• You’ll be completely safe
• We’ll hold your hand
• We won’t let go
• Sand!
• As much as you want
• You can dig holes in it as deep as you like
• We’ll even let you bury us in it
• Candy and Ice Cream!
• Amusement Rides!

OK, ok. I still wasn’t sure why, but I was sold. I sent my friends home, climbed into the car with my parents, and off we went.

And went, and went, and went. As we drove, my five-year-old brain struggled with the idea of being stuck for so long in the car. Hours! When you’re only five years old, a couple of hours is a very significant percentage of your life to date.

Looking ahead through the windshield, straining to see as far up the road as I could, I tried to spot this Beach I’d been sold. I’d see a house in the dim distance, or a tall tree, and, being a child ignorant of things like the horizon and the curvature of the earth, I’d figure, surely, that house or tree way up ahead along the road must be the Beach.

A few minutes later, though, we’d motor right past that house or tree and keep driving, so I’d ask, “Are we there yet?”

At first, my parents would smile and explain that the Beach was farther away, but that we’d be there soon.

So, I looked ahead again as far as I could see, and spotted a telephone pole, or an office building, and figured, “well, then that thing surely must be the Beach.” But we’d drive past it a few minutes later, I’d ask again if we were there yet, and my parents would repeat, through thinner smiles this time, that the beach was farther away and we’d be there soon.

Our collective patience waned pretty quickly as I asked over and over, until finally they ordered me to stop asking, suggested I take a nap, and told me they’d wake me up when we got there. I wasn’t one bit happy about it, but I got the point and fidgeted myself to sleep.

Eventually, of course, we made it to the Beach, which was very hot, and very crowded, with impossibly long lines of sunburned tourists trailing up to every amusement ride. Yes, there was plenty of water, but it was dirty and rough and full of strange people and very, very cold. And, as promised, there was plenty of sand everywhere, including in my ice cream, on my candy, and especially in my bathing suit and sneakers.

We packed up after a few hours and headed silently back home in our car, and I put the whole miserable experience out of my mind, until I began work as an IT consultant.

Information Technology often feels like my childhood trip to the Beach. Various vendors and consultants sell us, as IT professionals, on their particularly wonderful destination products and services, each offering a marvelous future wherein everything works and everyone’s happy: “the Beach!” And, off we go.

Along the way, we spy up ahead the oncoming virtual future of promised technology – Cloud Computing, Virtualization, SOAP, Open Source, whatever – and, like children, we naturally confuse each with the Beach. These milestones come and go, though, and, as our real future unfolds, it seems to offer new experiences of the same old frustrations. Things still don’t work perfectly, and our users still aren’t totally happy. The “Beaches” we buy never quite materialize, and our ride just seems to go on and on.

We work in a profession that reveres closure, one that pressures us to provide decisive technical answers quickly. How can we possibly find peace in the inevitable conclusion that Information Technology has no destination?

Information Technology, like everything else in our human experience of life, is all about the ride. As we drive along, past one imperfect technical solution after another, the key to getting along with everyone else in this car we share lies in our individual search for honest answers to three basic human questions:

• Who am I?
• Who are you? And, how can I help you?
• What practical situations are we facing right now? And, how can I work with you to deal with them?

Awareness is the key to long-term success in Information Technology: awareness of self, of the others who surround us, and of the endless passage of practical situations in which we, as IT professionals, find ourselves. Finding the freedom to answer these questions for ourselves, then setting others free and helping them to do the same, are all a part of growing up along our way.

_______________________

The POInT Organizational Transformation Program smooths the journey for IT professionals and organizations, and Al Cini is the POInT Program’s tour guide. Learn more at:

http://point-cmc.blogspot.com.

Hey, Way to Micromanage!

If you’re getting second-hand reports (they’ll rarely tell you to your face) that the people in your organization have been complaining about your micromanaging ways, maybe it’s because you’re doing it wrong?

This instructional video might help:

Is Micromanagement Ever a Good Thing?

Is there a proper way to micromanage (or nanomanage, or picomanage…) IT people? Or, is all micromanagement just plain bad management?

As with most of the people-oriented mistakes that people make, the answer lies in the unconscious intentions that misguide our behavior.

Bad Intention #1: Ego Defense. “I was the best there ever was, I’m the best there is, and I’m going to make sure that everyone knows I’m the best there ever will be.”

Before you became a manager, you were technical, and, if you do say so yourself, you were darn good at it. You really miss those daily opportunities to prove yourself, by coding rings around everyone else on your team, by amazing end-users with your uniquely excellent tech support skills, or by being the first to adopt the latest and coolest product releases to design, install and configure your organization’s IT infrastructure.

So, as a manager, you compensate by competing with your subordinates, by repeatedly teaching them the one and only right way to do their jobs: your way.

Bad Intention #2: Managing Up by Micromanaging Down. “To climb my way up within my Company, I need to be seen doing things the Company Way.”

Your company’s developed or adopted some methodology to help ensure that the highest-quality technical work will be done on time and within budget. As a middle manager who’s on the move, you want to be perceived as ready, willing, and anxious to do whatever it takes to please upper management.

So, you breathe, eat, and sleep every detail of your company’s mandated quality and productivity programs. You make sure everyone under you does, too, by regularly comparing their work with your company’s published methodology templates. When you find employees who aren’t doing things right, you criticize them as loudly and publicly as possible – not just to correct their unprofessional behavior, but to maintain and strengthen the widely held impression that you’re the ultimate professional “company guy.”

Bad Intention #3: The Boss Knows Best. “I’m the boss, which makes me responsible for everything my people do. And, as Spider-man’s Dad said: ‘with great responsibility comes great authority.’ (umm, no, wait…)”

When your people fail, you fail. And, left to their own devices, people will always fail, won’t they? Well, in your organization, failure is not an option.

So, you map within your mind every task and sub-task of every technical project for which your team is responsible, and, at the many team meetings you call for this purpose, you require that everyone review their progress on an intricately detailed task-by-task basis. This exposes, before one and all, the slackers and malingerers, and makes clear that, in your organization, such behavior will never be overlooked or tolerated.

Micromanagement: Be honest. How’s it workin’ for ya?

As one of the hallmarks of the authoritarian personality, micromanagement can trigger the kind of passive-aggressive organizational behavior that stalls collective effort and inhibits collaborative progress. That’s a pretty steep downside risk for a technique that, on its face, seems to promise the upside of a job well done.

Is All Micromanagement Bad?

On the other hand, people sometimes lose sight of the goals their organization sets for them. Talented and experienced technicians can sit, utterly disengaged, in a state of professional torpor, for days or weeks on end, unable on their own to find their way back to productivity. If ignored for long, this malaise can spread, infecting others in the organization.

Foundering employees need to be identified quickly. In a calm and organized way, perhaps with help from HR, they need to be confronted (privately), and either helped or reassigned. Reminding them of the goals of the organization they serve, and reacquainting them with the details of their jobs, can help get their efforts back on track. In this context, while it can – and should -- feel uncomfortable to the manager who has to do it, micromanagement is good management.

Is micromanagement bad or good? Perhaps that’s the best test: Effective micromanagement should always feel uncomfortable. When micromanagement feels good, it’s self-serving rather than others-serving behavior, and self-serving micromanagement is always bad.

Questions

• For managers: when has micromanagement worked for you? (Extra credit: can you admit that you do it? Can you explain how it’s hurt you?)
• For recovering micromanagers: tell us how you overcame your compulsion to micromanage?
• For everyone: have you ever needed micromanaging in your job? Was the situation handled well by your manager?

The Surprising Truth About What Motivates Us

In Information Technology, it seems you can’t buy employee commitment.

In fact, when it comes to encouraging people to work cognitively, on brainpower tasks that require creativity or abstract thinking, cash is more of a de-motivator than a motivator.

Don’t believe me? Take ten minutes to watch this surprising video.

“Bottom line: If we treat people like people, instead of like horses…”

The conventional wisdom is that you “pay for performance.” The truth is, well, something else altogether. Instead of inspiring quality effort, extrinsic monetary rewards actually discourage high-quality work.

So much for extrinsic motivators. To learn about a very effective system of intrinsic motivators, click here, then come back and answer these questions.

Questions:

• Leaders/Managers: On your team or project, or within your organization, which extrinsic incentives (e.g., money) have you used to motivate people? Which have worked? Which haven’t?
• Everyone: Which intrinsic motivators best inspire you in your professional pursuits? Do you work within an organizational culture that understands and respects this? If so, how is this expressed in that culture? If not, what do you think management can/should do to correct it?

Measuring ≠ Accomplishing

t+0: Helpdesk Support Ticket opened

t+5 seconds: Helpdesk Support Ticket closed

t+forevermore: User Totally Frustrated

Notes:

• Both people feel they’re doing what their company wants them to do.
• Neither is listening to the other.
• The user's problem isn't resolved.
• Yet, according to the helpdesk ticket’s statistics, "Mission Accomplished."

How is this possible?

Thoroughly researched over many years by countless organizational and social psychologists, cognitive dissonance enables people to perceive failure as success. Ironically, the systems IT organizations use to measure success can be “gamed” to provide cover for such misperception.

Questions:

• Do you believe that the metrics you use to manage your people capture the acts of service they perform?
• How do you follow up on your systems of measurement to ensure that they do?

Dumb Like Einstein, and Another Important Heresy

 

 

“God doesn’t play dice with the Universe.” Thus tweeted the Great Albert Einstein in 1926. And, ever since, folks everywhere have been retweeting this profound revelation about God, straight from the Gospel According to Albert.

Problem is, Einstein didn’t exactly say that. Here’s what the man actually wrote, in a letter to pioneering quantum physicist Max Born:

“Quantum mechanics is certainly imposing. But an inner voice tells me that it is not yet the real thing. The theory says a lot, but does not really bring us any closer to the secret of the 'old one'. I, at any rate, am convinced that He does not throw dice.”

Albert’s Intellectual Limitations

Turns out Einstein, the man who by 1926 had earned copious major honors by revealing the architecture of the Universe at Large, wasn’t really referring to God in his letter at all. The Great Genius was, in fact, confessing his own difficulty in grasping the basic architecture of the  Quantum Universe of the Very Small. Biased, perhaps, by his subjective familiarity with a personal Almighty, Albert’s “inner voice” had  misinformed his objective understanding of the nature of reality’s littlest things.

Einstein strongly (stubbornly?) believed that randomness in scientific observations resulted from human imperfection in observing and understanding. Make perfect the instruments and sharpen and deepen the theory, he figured, and, poof! like a god, you know everything, and can therefore predict the cosmically enormous set of all possible future events, even the very tiniest ones, with 100% certainty.

This Determinist Einstein just couldn’t accept what his contemporary particle physicists were demonstrating over and over again in their labs. Where certain behaviors of really little things like electrons and photons are concerned, no matter how smart the physicist or perfect her instruments, making certain kinds of predictions about the outcomes of certain quantum phenomena are, well, just plain uncertain.

So, in his oft-paraphrased and widely misunderstood 1926 letter to Max Born, the Great Albert Einstein was, duh! just plain wrong – at least about quantum physics, and perhaps even about God, Who may indeed have some sort of Supreme Gambling Problem.

(Still, “God doesn’t play dice with the Universe” sure sounds right, doesn’t it?)

The Psychological Limitations of “Process” in IT

Wait! Duh! Don’t stop reading. This story has everything to do with Information Technology.

Information Technology’s leaders, of projects and of people, emerge from the fundamentally deterministic world of machines, wherein every action has a 100% predictable outcome. This world, of course, has its unexpected bugs and breakdowns, but the reliable solution for buggy machines is process: time-proven repertoires of well-understood and clearly documented procedures that help mitigate the risks of faulty technology by rigorously squeezing out its pesky uncertainty.

This successful experience with managing machines can easily spur a Quantum Misstep of twisted logic in managing people. “After all,” our inner voice reasons, “aren’t people really just like machines? Of course they are!”

The conclusion sounds right, but it’s dead-wrong. Unlike machines, people, cursed as they are with Free Will, behave, like quantum particles, in fundamentally unpredictable ways. Psychologists have long recognized  a “Human Uncertainty Principle” of sorts: the more confined people feel by the processes their leaders impose on them, the less predictable their organizational behavior becomes. IT leaders see process as governance, but those so governed often perceive it as micro-management. Especially in the most talented and creative, micromanagement triggers rebellion rather than compliance.

Frustrated by process, followers find creative ways to avoid following their leaders. In turn, their leaders, dismissing these little mutinies as failures of their Human machines, sharpen their procedures to tighten the harness and regain control, which only provokes further mutiny. As leaders lend greater and greater weight to following process in order to reduce the degrees of freedom for failure in the groups they manage,  they unwittingly generate a psychological “black hole” that ensnares all chances of success as well. Individual efforts stall, projects slip, and neglected infrastructure eventually sputters and fails.

A Way Out of the Psychological Singularity

Of course, process certainly plays a role in effective management, but it can’t guarantee effective leadership. Go here and begin learning about the non-deterministic, Zen-like principles of Servant-Leadership: that the true path to leading people starts with serving them; that the most effective way to shepherd their efforts is to set them free.

When you come back from reading, try this new kind of “Non-Process” on for size in 2010:

Step 1. Accept intellectually that people behave in non-deterministic ways, and that, particularly in knowledge-worker fields like IT, this necessarily limits your ability to govern their actions.

Step 2. Once you’ve accepted the basic uncertainty of human behavior, you will naturally begin to question your feelings about your colleagues and subordinates. This fresh uncertainty, while uncomfortable at first, is very healthy. Let it teach you:

• The people you “like” best aren’t necessarily your best people
• The people you “like” least may, in fact, have the most to offer
• While, by behaving unpredictably, machines can only bitterly disappoint you, people, with your permission and support, can very pleasantly surprise you.

Step 3. Beyond articulating the details of tasks, your transcendent role as an IT (or any) leader is to reveal the human value of the larger goals you choose to serve.

Step 4. Once the human value of your organization’s goals have been revealed to them, people will drop the heavy baggage of their personal egos and begin to gravitate toward helping you to achieve them. Remember that they aren’t following you as a leader; they’re following your lead toward something larger than each and all of you. Congratulations! By tapping the source of authentic leadership, you’ve entered the larger world of the Servant-Leader.

Step 5. Never, ever play favorites. Everyone has value, whether you like them personally or not. Treat everyone with respect and, as you support them, they’ll all work hard with you, each in their own wonderfully different way, to help you achieve your organization’s goals. (Remember that, on the other hand, you cheapen the work you’re trying to inspire when you treat it like a win-lose game. You may think you’re being clever, but you undermine your own leadership in the long run when you “play” people for short-term gain.)

Step 6. Full- or part-time employee, contractor, consultant, whatever --everybody’s somebody. Be prepared to recognize everyone for the value of their contributions, regardless of what’s printed on their business cards.

Step 7. Every organization needs its “operators,” the go-to-guys, the t-crossing and i-dotting detail-oriented folks who devise and follow effective processes. But beware the hidden trap of settling for the merely routine and declaring it “excellence.” Excellence is something more.

Which prompts the most important of questions for any organization or society: what is Excellence?

Einstein Finally Redeemed

Is dancing purely a matter of process? Does clear and precise choreography determine the quality of a dance performance? Does putting your feet exactly where and when you’re told make you a dancer? Will carefully following a really precise floor chart make you an excellent dancer?

Dancing, especially good dancing, transcends choreography. Excellent dancers exceed the specifications of choreography. They amaze an audience, and pleasantly surprise their choreographer, as they freely capture and ride the spirit of a performance.

Likewise, in all the work we humans do, how can excellence possibly emerge from simply following a process? Can a really good paint-by-numbers Mona Lisa elevate anyone to the level of a DaVinci?

Following process and meeting expectations is adequacy, and adequacy is virtuous. Adequacy has its place.

But excellence is more. Excellence is the miracle of exceeding expectations. Perhaps because we fear failing to repeat it, we sometimes tend to mistrust excellence. So, we shy away from it, perhaps most often by withholding, from ourselves and others, the freedom on which excellence feeds, which it needs to survive.

Here’s where old Albert, after nearly a lifetime of saying his share of dumb things, got one absolutely right (Out Of My Later Years, 1950):

“Everything that is really great and inspiring is created by the individual who can labor in freedom.”

The Twin Illusions of Conflict and Power

Aesop's fable, "The Dog in the Manger," concerns a barnyard dog who one afternoon lay down to sleep on top of the hay in the barn's manger.

On being awoken, he growled and barked. "Woof woof!"

He ferociously kept the animals from eating the hay in the manger, even though he couldn't eat the hay himself.

A frustrated ox offers the moral of the story: "people often begrudge others what they cannot enjoy themselves."

The modern discipline of Information Technology gives Aesop's centuries-old fable fresh relevance. Imagine that you're the technical person in charge of your company's newly installed state-of-the-art information system. It might be a complex software tool, like a big-deal Oracle database management system. it might be something simpler but just as important (and expensive), like EMC's latest and greatest networked disk drive array.

You may have helped your organization evaluate and select it. Perhaps you supervised its installation and initial configuration. You've gone over and over its manuals and technical notes for many weeks or months as you've mastered its elaborate ins and outs. You've updated its software and firmware, tweaked and tuned it to perfection, and demonstrated its cool features with pride to your colleagues and management. And, of course, you've upgraded your mental resume, and maybe its embodiment on paper as well, to reflect all of your wonderful new experience with it.

Then, one day, inevitably, others in your organization approach you to make use of it. They ask you for its administrative password, inform you that they plan to migrate some corporate division's data to it, advise you that they intend to connect it to some backup/restore system. In short, they announce their intention to take it from you.

How do you feel about this? After all, it's your system, isn't it? How do you act on those feelings? Do you look for ways to say "yes," or do you look for ways to justify saying "no?"

Thomas and Kilmann Conflict Modes

According to Kenneth Thomas and Ralph Kilmann (1974), conflict is a matter of perception rather than fact, and, as such, people can imagine it where it doesn't actually exist. Experience suggests that Information Technology professionals, who tend to entangle their subjective sense of personal self-worth with the objective details of the tools they master, are perhaps more likely to misinterepret as an attack on their ego the logical next-step of handing their beloved tools over to be applied in practice by others. I've known many a colleague who, after insisting that they wanted nothing to do with the day-to-day details of some subsystem they'd installed, nonetheless resisted stubbornly any others who dared try to assume responsibility for it themselves.

Come to think of it, I've been that colleague, and more than once. Was I rightly defending an important technical resource from possible misuse? Or, was I merely defending my own bruised ego? In hindsight, I can tell you that those weren't exactly my finest professional hours.

According to Thomas and Kilmann, people choose to respond to conflict, whether real or imagined, in one of five behavioral modes (see diagram above). There are two ways to cooperate: assertively, by working with the conflicting parties, or more passively, by simply accommodating their wishes.

Thirdly, there's the neutral middle-ground choice of seeking compromise.

And, finally, Thomas and Kilmann posit two ways of saying "No," of refusing cooperation: assertively, by competing, or passively, by avoiding conflict through uncooperative resistance.

Thinking back, as I reacted to the imagined threat my colleague posed when he asked me to hand over that storage subsystem, what choices did I imagine I had?

Active cooperation and passive accommodation would have meant sharing continuing praise and credit for a job well done, my job, with someone else. The middle ground of compromise would have meant surrendering it altogether.

On the other hand, I couldn't actively compete with my colleague for ongoing ownership of the new system, because management wouldn't have supported me, and, besides, I really didn't want that job myself.

So, I resisted. I chewed onto ownership for as long as I could. I snarled at requests for access to the subsystem's passwords. I dogged those last steps needed to make the subsystem operational. And, in doing all of this, I starved my organization of something it needed, delayed others' projects, frustrated others' goals.

What's another word for passive-aggressive behavior? How about "Woof woof."

Discussion Questions:

• In your experience, in the context described in this post, would a typical IT manager be more likely to support or change an IT practitioner's passive-aggressive behavior?
• What would be a manager's best strategy for dealing with this situation?
• How might a frustrated IT practitioner go about changing a passive-aggressive colleague's conflict-handling mode from competitive to cooperative?