Wednesday, September 30, 2009

"Time Keeps on Slipping, Slipping, Slipping..."

My reaction: 
The underlying cause of IT managers' chronic screaming and yelling about projects that never seem to be finished may, in fact, be their screaming and yelling.

An article on procrastination in Psychology Today suggests that procrastination is, at least in part, a response to the screaming and yelling of authoritarian management.
Attention managers: yelling may feel good, but it doesn't work. In fact, your yelling may further entrench the very behavior you seek to change.

So, alright then, what does work?

Kitchen timers. That's right, kitchen timers.

According to a guy named Francesco Cirillo, a simple kitchen timer can help focus an individual's attention on getting tasks started. A description of his "Pomodoro Technique" (his kitchen timer is shaped like a tomato, the Italian word for which is "pomodoro") of time management can be found at



Perhaps the solution for the chronically delayed completion of IT tasks and projects is finding ways of getting them started in the first place? For some procrastinators, a little investment in a kitchen timer might yield large returns in productivity

Saturday, September 26, 2009

Don't Hate Me Because I'm a Customer

My reaction: 

The computer support person in this clip from "The Office" (UK) clearly hates someone. A few questions for discussion:

  • Whom does he hate? And, why?
  • Should this behavior be confronted or ignored? If confronted, how, and by whom?
  • How will this sort of behavior affect this employee's job performance metrics (e.g., support tickets closed, problems resolved, etc.)?
  • What effect might you expect his behavior to have on that of his IT co-workers?
  • What do these kinds of chronic work habits say about the values of the organization that tolerates them?



When it comes to passive-aggressive organizational behavior, acceptance is merely avoidance, and it's a bad option for everyone. Don't tolerate the intolerable, in yourself, or in those who serve.

Sunday, September 20, 2009

A "Buddy System" for Software Engineers

My reaction: 
What's the difference between "head count" and "mind count"?

This post shares an interesting article recommended by a reader of this blog. (Thanks, Chris.)

A recent New York Times article describes a "buddy system" called pair programming that claims increased productivity (specifically, faster coding and quicker debugging) for software engineers.

The thoughtless IT manager might wonder about the business sense of putting two expensive "heads" on one job. The smart manager, however, realizes that, when it comes to cognitive effort, productivity and head count are, at best, only loosely correlated, and recognizes the psychological reasons why, when it comes to writing code, two "minds" can indeed be better than one:
  • Increaded focus and attention on assigned tasks
  • Less time wasted doing "off-topic" things
  • Heightened motivation to finish coding jobs on time and within budget
  • Less "ego involvement" and more common sense in the coding process
  • Built-in mentoring for the junior member of the pair
A few more cognitive activites that might benefit from a "paired-mind" approach:
  • Root Cause Analysis (2nd- or 3rd-level problem resolution)
  • Short-Term Task Management (e.g., implementations, migrations)
  • Product or Technology Reseach, and Selection of Candidate Solutions
Can you think of any others? Leave a comment here, or on the corresponding LinkedIn or Facebook discussion topics.

Wednesday, September 16, 2009

When Did the Wheels Fall Off the Welcome Wagon?

My reaction: 
An e-mail message from a reader reports that, in her last three positions over eight years, she was shown her desk on her first day of work, and then abandoned. 

No manager visited her to describe her job on her first day at work. Or her second. Or even her third. 

Instead, her co-workers showed her the local ropes and explained what her group was supposed to be doing for a living.

IT Professionals: has this ever happened to you?

IT Managers and Leaders: does your company have a procedure for welcoming new hires? If not, do you have one of your own?

Monday, September 7, 2009

Shut up and Reboot

My reaction: 
Q: Why work hard at digging up the root cause of a problem when a simple problem-solving heuristic might alleviate its symptoms and put off having to actually fix it for, like, forever?

A: Tsk tsk, you don't really expect an answer, do you? A better question would be:

Q: Why do IT professionals settle for simple 'rules of thumb' in solving technical problems rather than work to find the authentic solutions that fix their root causes?

A: When (otherwise rational) people, under time pressure to solve a practical problem, judge that the properly calculated solution might be too time-consuming or complex for them to figure out, they often (irrationally) apply easier, more familiar, but less appropriate problem-solving behaviors.  They resort to habitual rituals that have "worked" for them in solving other problems over the years, or fire up some troubleshooting tool or method they've used successfully before, or substitute some simpler analysis of the problem in place of the harder one. In effect, rather than solve the problem at hand, they imagine a simpler one and solve that instead.

"Successful" (that is, more "adaptive") IT professionals can be very good at playing this game. Their solutions may not be "real" ones, but they're often good enough approximations to mask the problem's symptoms for a while, long enough to close a ticket, merit a brisk pat on the back, maybe even earn a bonus.

Sound delusional? Well, it is, but the imagined reduction in the "pain" associated with a superficially addressed problem is often counted as a victory over it, and the resulting short-term kudos, however undeserved, can feel just as satisfying as arriving at the real answer.

This is a cognitive bias called attribute substitution, and it's the root cause of many errors in judgment in Information Technology.

To help illustrate attribute substitution, try solving this example problem: together, a toy bat and ball cost $1.10. The bat costs $1 more than the ball. How much does the ball cost?

Did you quickly arrive at ten cents for the ball? Most people do. Rather than dredge up memories of High School algebra, most people would rather simply subtract the $1 difference in cost between the bat and the ball from the $1.10 total figure, concluding -- incorrectly -- that the ball costs a dime.
Here's the correct answer: Bought separately, the ball costs five cents, the bat costs $1.05, totalling to $1.10 and satisfying the constraint that the bat costs a dollar more than the ball. Attribute substution probably costs the average SAT test-taker 100 points on their math score.

What's the "cure" for attribute substitution?

Where possible, Information Technology managers, leaders, and supervisors need to relax the push to fix things quickly in favor of emphasizing the value of solving problems fundamentally. Do you measure the resolution of technical problems in your organization? Where possible, your metrics should reflect the depth of those solutions.

For their part, IT professionals need to question their own reasoning and emotional motivations in solving technical problems. Do you feel driven to announce a solution first? When someone else solves a problem before you do, do you feel as though you've "lost?" You're prone to attribute substitution if you answered "yes" to either of those questions. 

Q: What's more important, arriving at any plausible answer quickly, or finding the correct answer?



Working on solving a problem? Force yourself to ask "why" at least five times. Probing iteratively is hard work and time consuming, but it arrives at real answers.