Visible and Invisible...Corporate IT?

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


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.


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


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.

Editor's Picks

Free Newsletters, In your Inbox