After Hours

General discussion

Locked

The Mumbling Manager

By Shannon Kalvar ·
Tags: Off Topic
blog root

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

How to Let Go the Hard Way

by centeno In reply to How to Let Go the Hard Wa ...

<p>add another scenario....<br />you're the CIO (call it whatever you want), but also the helpdesk, the hardware repair guy, and almost everything that blinks or as a button falls in your desk.<br />In Portugal we're used to be "smartasses", and we play all the jobs, on contrary of being experts in a field. I don't yet know if its a better or worse aproach, but i can tell you that all my users pass by the problem  of having a very small situation taking 3 ou 4 times more time to be solved.</p>
<p>hoo, and planning doesn't play any role where. I've millions of plans (snort, hylafax,...) in my head, but that stupid HP930c had gone out of paper again! let me go and put some paper on it, because the guy from the telecom is arriving for the negotiation the new site where oppening. (300Km away!!)</p>
<p> </p>

Collapse -

How to Let Go the Hard Way

by clangl In reply to How to Let Go the Hard Wa ...

<p>This really hits home for me.  I have recently resigned from my position as a Director of IT and one of the reasons was along these.  My current boss wants to be in the middle of everything.  I never thought about it but I do it myself as well.   The other problem with not delgating is that you are setting up your entire department to be just like you.  </p>
<p> </p>
<p>This really hits home!!!</p>

Collapse -

How to Let Go the Hard Way

by clangl In reply to How to Let Go the Hard Wa ...

<p>This really hits home for me.  I have recently resigned from my position as a Director of IT and one of the reasons was along these.  My current boss wants to be in the middle of everything.  I never thought about it but I do it myself as well.   The other problem with not delgating is that you are setting up your entire department to be just like you.  </p>
<p> </p>
<p>This really hits home!!!</p>

Collapse -

How to Let Go the Hard Way

by Marcelo Thalenberg In reply to How to Let Go the Hard Wa ...

<p>You do not work on a fire rescue, the systems should run 24 X 7 365 days a year not you. I worked on the same way and same philosophy you wrote and I gave it up. It is not a change management question, it is about a person me or yourself and our own emotions and anxieties it is hard to change our own behavior.</p>
<p>I changed step by step, understanding the emotions and planning, taking one action after the other, teaching my team to organize theirselves and improving their planning using Outlook or Notes. I worked so hard figuring out better ways on delegating and supervising and I wrote about it at Facilitating Teamwork chapter in the book Managing your Business with Outlook For Dummies. Read it and maybe will help you one way or the other.</p>
<p>MarceloThalenberg </p>
<p>   </p>
<p>     </p>

Collapse -

Visible and Invisible...Corporate IT?

by Shannon Kalvar In reply to The Mumbling Manager

<p>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.</p>


<p>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.</p>


<p>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??</p>


<p>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.</p>


<p>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.</p>


<p>Now, caveat
inserted, lets get on with the show.</p>


<p>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.</p>


<p>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.</p>


<p>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.</p>


<p>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.</p>


<p>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.</p>


<p>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.</p>


<p>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.</p>


<p>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.</p>


<p>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.</p>

Collapse -

Visible and Invisible...Corporate IT?

by Stryker08 In reply to Visible and Invisible...C ...

Shannon,<br /><br /> First off I would like to say great article, I work at a college IT department(Internship) and I can completely relate to what you are saying about the difference in styles. I am partnered with an extroverted person and we motivate each other/keep things going as I am introverted. I must say that I am particular to the invisible approach but working at this college the visible approach seems to pop up more often then not. It's great for the department but I often find that users will seek me out and refuse/dislike talking to my colleagues about their problems. <br /> I am also an RA at my college and they cover the differences in personalities/working with a variety of people in depth during our training sessions. It's always interesting to notice the little things people do/how they behave when put in a given situation to determine which type they are. They don't even know they are doing it most of the time, which leads me to ask, can people really change who they are? Or do they simply modify their behavior/condition themselves to a different response?<br /><br /><br />

Collapse -

Managing Conflicts Between Creative and Reactive Work

by Shannon Kalvar In reply to The Mumbling Manager

<p>Today I sat and
thought. I only had a handful of meetings today, so I actually took
the time to work with my team, get things moving for the week, and
even finish some of my own analysis tasks. It's hard, sometimes, to
cram all of the thinking I have to manage into a day. Which seems, I
suppose, kind of a lame thing to whine about.</p>


<p>However, the idea
does lead me into a far more interesting topic: how creative thought
works in an reaction dedicated environment. Creating actionable
information out of raw operational data takes a lot of sitting and
thinking. It's the kind of task you have to pick up, ponder, put
down, go get some tea, go off, pick back up, ponder, try some things
out, find they don't work, ponder, etc, ad nauseam. Meanwhile an
reactive environment emphasizes rapid response to issues, hopefully
before the escalate into disasters. The tasks come in and go out at
a fearsome rate, usually with hastily constructed workaround wrapped
around them.</p>


<p>Now, I don't know
about anyone else, but I have trouble really digging into a creative
analysis when I have to react to incidents ten or more times a day.
Incident resolution is all about the quick fix; you have to get the
user up and running as fast as humanly possible without breaking
anything else. Creative analysis is about the steady application of
thought to isolate and ferret out the problems causing the issues
uncovered by incidents; it takes huge amounts of time for potentially
very little gain.</p>


<p>In my case,
though, I'm not just worried about my own psychological hang-ups.
I'm pondering how my team works and what I can do to help them
achieve greater throughput. My job isn't just about doing; it's
about making sure my team knows what needs to happen and can actually
do their jobs.</p>


<p>Recently I've
taken on kind of a ?sorter? role, as I've mentioned earlier. I
organize the serious issues and dole them out to the appropriate
resources. This approach works reasonably well for keeping the fires
at bay, but does little to further stabilize the environment. To do
that I need to get my team focused in on the problems, working in a
creative rather than reactive mode, and building serious resolutions.</p>


<p>I don't know if I
can do it with my entire team though. Just to start off with, they
worked in a purely reactive environment for years before I arrived.
Reactive activity is addictive; not only does it give you an
adrenalin rush but it also stops you from having to plan out your
next activities. It shortens your time horizon to the next major
disaster and you can just kind of coast from day to day without
really pushing your own limits.</p>


<p>More importantly,
I cannot change the environment. I need to build strength, either in
my team or in another team, to absorb some of the reactive work while
we reach out to resolve problems. Culturally that will pose us with
a major challenge. Politically I don't have the resources to pull it
off. Practically...well, that's a different story. I think I have
the support of my peers in pulling together a much stronger response
than our previous approach.</p>


<p>Unfortunately the
change will not solve my immediate problem. I will still have to
sacrifice some of my team to reactive work every week. There's
enough of it that it could consume two FTEs if I let it. Right now I
divide that into one FTE and two halves, with the remaining halves
devoted to creative activities and project work. That drives the
team members stuck in that half-way role insane, though, and I'm not
sure what to do about it.</p>


<p>I'll probably feel
better once I get my senior resource back. He's off on vacation this
week, after spending the last seven weeks being eaten up by a
project. I need some backup on all of this analysis work. I'm
decent at it most days but it takes too long to get though it all.
We got more done on Friday last week (when he stopped by the office
to idle away the last day before vacation) than I got done all the
previous week.</p>


<p>Which makes me
wonder if I'm pursuing this all wrong. Maybe the answer is not to
worry about shielding the team members but to make sure they work on
creative problems in teams. Hummm...if it works for snipers it might
work for us.</p>


<p>Or not. Something
else to ponder, I guess.</p>

Collapse -

Managing Conflicts Between Creative and Reactive Work

<p>I just turned down a rather prestigious job where I would be working with a good friend of mine because I knew that I would be working in an entirely reactive situation. My friend was a bit incredulous. Your post appeared at a good time for me.</p>
<p>I would like to add that some of these people that you think are being reactive only are being creative in other matters that are costing your company productive time anyway. So, yes, you have resource issues, but if you present the creative issue properly, I think you would find that you would more productivity out of the same resources. That is, you would merely be changing the focus of their creative activities.</p>
<p>Hope this make sense.</p>
<p> </p>
<p> </p>

Collapse -

Managing Conflicts Between Creative and Reactive Work

by rahammers In reply to Managing Conflicts Betwee ...

<p>Our lives are are filled with too many meetings however this type of issue may require yet another one.  What has been successful for us in the past is a root cause annaylsis meeting.  In this meeting the problems of the week are quickly reviewed and categorized.  If the "system" issue cannot be determined in the meeting the most appropriate resource is tasked with getting to the main issue and working on a resolution.  This seems to work for the minor and annoying issues.</p>
<p>In my opinion, major issues requiring an immediate fix are easier to deal with and success has been found with the exact opposite approach.  By standard operation procedure we have predetermined that 30 minutes is the acceptable time to look for a resolution.  All hands work on the problem and try to assertain a corrective measure to fix the system problem.  Once that 30 minutes is up, we take a 10 minute time out to review the situation and then split into two groups.  One trying to correct the system issue, the other into trying to implement a work around thus commencing with restoral of services.  Should the work around be implemented to satisfy users, the issue then goes to the root cause annaylsys stage described in the beginning.</p>
<p>In the interest of full disclosure I must point out that I work in the field of Networking - switches, routers and such.  Much less of an art than programming.</p>

Collapse -

Managing Conflicts Between Creative and Reactive Work

<p>I worked at a help desk/network monitoring department for some time. It was a completely reactive environment. The phone rings or an alarm goes off, and you took action. If the phone was not ringing or the networks were fine, you were sitting doing nothing. Yet, I managed to get an extreme amount of creative, proactive, non-reactive work done. The secret is mutlitasking. Let's face it, 95% of the help desk phone calls are old hat that require zero thought on the part of someone taking the call. The hard drive is dead, the a wipe/reload is needed, they just need to reboot, they have caps lock on, etc. Or whatever the common issues are for you. I was able to write code to help the department out, run reports to see where our common pain points were, write training manuals, etc. <strong>All while on the phone with customers.</strong> It was quite a trick (and sometimes it was a bit embarassing, telling the customer about the hard drive RMA process because you are writing about it, when you are walking them through some network troubleshooting). But overall, it was quite possible. I was able to troubleshoot networks on my terminal while troubleshooting tape drives over the phone while writing internal Knowledge Base articles. If you are not very good at multitasking, this obviously isn' for you (of course, it's great practice!). But if you are, this is the only way to do it.</p>
<p>In a reactive environment, management has optimized the workforce to smithereens, taking a zillion statistics and "rightsizing" to the point where the hold time is always 10 seconds less than the contract specifies as a maximum, and making sure that everyone spends their entire shift on the phone. But the employee who is able to generate those KB articles, or analyse incidents to find common problems to pass back to Engineering, or who can do two tasks at once, or is available to assist other workers via IM/email while handling incidents etc. is the employee who gets the raises and promotions. I know, because I got raise after raise and promotions came very quickly for me in that environment, mainly due to that ability to multitask and produce needed, creative work in addition to handling the reactive work well.</p>
<p>J.Ja</p>

Related Discussions

Related Forums