This week actually
turned out fairly well for the team. They knew what they had to do.
They adapted when operational problems manifested themselves as
system wide incidents. Three out of four tracked incidents back to
their core technical issues and addressed them with the quiet
intensity I so adore. No muss, no fuss; just solid work performed in
the background. The fourth closed up a project then dived right into
a knotty analysis complex without a moment’s complaint. Pretty much
what I’ve come to expect from these gentlemen.
With my team doing
a bang up job, though, I’m given leisure to ponder other things.
Well, with my team doing well and me on my back most of the time from
being sick, otherwise I should be out there doing something. What I
ended up pondering this week was the difference between what I think
IT should act like and how I often see it done.
A few years back I
wrote two articles for Tech Republic about two styles of
consulting: the visible and the invisible. Visible consultants, in
effect, use their position to promote necessary activities.
Invisible consultants support their hosts, providing knowledge and
service to those who need it. The first style might be best
characterized by the statement I’m here to help; the second by
How can I help you today?
These ideas
translate reasonably well into the operational and project world I
find myself in these days. On one hand you have individuals who want
nothing more than for their whatever to save the day. They strive,
seek, and never yield. On the other hand you have folks who want
everything to work so well that, frankly, no one ever knows their
names.
Before I go too
much further let me say something right up front. I know no one
actually adheres perfectly to one style or the other. Everyone comes
down somewhere in the gray area and their position along the spectrum
changes they do.
Now, caveat
inserted, lets get on with the show.
At the furthest
extreme those who hold to the concept of visible operations
want their involvement with business critical systems known from one
end of the organization to another. They want people to understand
just how valuable IT has become. They seek out highly visible
activities, work hard to get the word out, and frequently develop
reputations as organizational champions.
This approach does
have a lot of attractions. To start off with, it’s a lot easier to
demonstrate value when you have some major victories to point at.
Having saved the organization some seven digit number in dollars
makes a powerful argument for your continued employment. The more
you are seen to do, the more people believe you can do. It’s also
kind of a rush; knowing you and your team can stave off the flood
makes some of the really unpleasant parts of the job endurable.
On the flip side
we have the invisible approach. At the furthest extreme you come to
the proverbial system administrator sitting in his dark cubicle. No
one dares approach him, for fear he will cut off their access to the
network. Yet his long hours and constant vigilance protect the
organization from problems most people do not even know exist. Less
extreme versions of this approach lead to people working quietly on
processes or building management tools to automate complex and
repetitive tasks.
This approach,
frankly, involves a heck of a lot less stress than the first one.
The invisible folks want the system to just run and take the steps to
make that happen. They get in front of issues before they become
crises (see the blog a few posts back about that) and do a good job
keeping the environment documented.
Either approach
creates an unbalanced environment when left unchecked. The visible
folks charge from one activity to another, leaving a host of half
finished systems in their wake. They manage crises with methods a
firehouse might envy while simultaneously ignoring the risks piling
up all around them. Meanwhile the invisible folks resist change and,
if left to their own devices, auger in projects with whatifs.
The trick, I
think, lies in building teams and departments with an appropriate
balance of approaches. This doesn’t necessarily mean balancing
personality types, though that’s another way to think of it. If you
have a strong, visible team leader balance him with a senior who
would rather no one knew what floor the IT department was on. If
your department manager likes to take an invisible approach help him
by giving him a team lead who wants the world to know just how much
the IT department saved the company this year.
The danger lies
when you create, by accident or design, large concentrations of a
single approach. Two conflicting styles prod each other into motion
and keep themselves in check; a monolith just reinforces itself. A
critical mass of visible actors, or visible actors in a direct
reporting relationship, can very quickly reach their extreme
behavior, spinning the solution wheel until a massive operational
problem distracts them. A similar group of invisible actors tends to
quietly vanish, perhaps never to be seen again. That’s alright for a
year or two but they will eventually become out of date, potentially
even a burden to the organization.
Personality
conflicts increase the dangers of matched styles in direct reporting
relationships. Two introverts who take on a visible style can find
themselves at loggerheads in a matter of minutes over approach and
intent. Two extroverts seeking invisible IT sometimes end up
undercutting one another as they struggle over priorities and
alliances.
So, what does this
have to do with my team? Well…not much just yet. It’s a bit of
analysis I hope to transform into another view of the activity data I
have. Eventually, when I have enough views, a hologram will emerge.
Once that happens I can, perhaps, make some real decisions.