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 sinceanything 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 toeither 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 uniquedemands.
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 thewrong 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 toreinforce 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 ornothing 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 toan inability to deliver very, very common in the world of IT.