This week was decidedly odd. I spent

it driving around, getting lost in various places I used to know, and

getting lost. I spent one glorious afternoon completely out of my

mind, effectively, lost in an area I once knew so well I could almost

walk down the streets blindfolded. Sixteen years of change, combined

with some deterioration in my interior map, put me into a fugue from

which I’ve only now fully recovered. It’s been literally years since

anything similar happened to me.

Or had it? In retrospect, it was just

a stress-exaggerated version of what we all feel when we sit down in

a changed situation. We rely extensively on our mental “map” of

the world; when that map does not match with what really exists

things get ugly fast. We go though a period of confusion, then

frustration that what we think is so is not so, then move on to

either denial or relearning so the map can change.

It’s this seemingly unstable map which

makes IT so difficult as a career. As professionals we live, and

must thrive, on change. Bugs crop up, causing incidents while we try

to discover workarounds. Patches come out, sometimes fixing the

bugs, more often adding a few new wrinkles to the system as well.

New products, approaches, and clients come and go, each with unique

demands.

Probably the worst examples of this

particular problem, for me anyway, come up when I pick up a new

version of a product I’ve not worked with for a while. The better I

knew the product, the worse the experience feels. Things don’t work

the way I expect. Buttons shift around; menu items change or

disappear. It took me about an hour, for example, to work out how to

make some changes to a WISE package. I’d done it dozens of times in

the past, but two versions back from the tool I end up using. What I

wanted to do wasn’t even hard – I just kept going about it in the

wrong way.

Most infrastructure people I know can

move quickly from the frustration stage to the rebuilding stage.

It’s something we find enjoyable, actually, which certainly makes

life easier for us. But each time we have to relearn something it

takes a toll. The more we push it, the more things we touch on, the

more stressful things become. The harder we try to keep up with all

of the changes the less energy we have for other things, like our

lives. The more we try to maintain a clear focus on multiple

technologies, the more difficult it becomes to keep them all separate

and functional in our heads.

The stress builds up over time. If you

have to shift rapidly between multiple, quickly changing products you

wear down quickly. If you work with a single product, or a small set

of intimately related code-bases, you learn more about a particular

product and encounter the need to radically change your mental map

less. I suspect, but cannot prove, that this tendency helps to

reinforce the silo approach so common in IT shops all over the world.

Managing that stress in ourselves is

hard enough. I know when I really dig into something I get surly and

difficult to deal with. My wife even comments on it form time to

time. But as leaders we have another challenge entirely: managing

the stress of others as they try to get the business’ job done. Note

that it’s not always our team’s job; often we find ourselves

wrestling with problems in infrastructure which have little or

nothing to do with us in the end.

Hummm. Helping others to manage their

own stress brings us full circle to my comments about fugue states

earlier. Allowing people to push themselves to the breaking point

does little good for anyone. It breaks down the individual’s

productivity. It shatters the team’s focus. Ultimately, it leads to

an inability to deliver very, very common in the world of IT.