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 -

Spinning the Solution Wheel

by Shannon Kalvar In reply to The Mumbling Manager

<p>Mondays are good
for melodrama. Everyone's rested up from the weekend and filled with
good intentions. Sometimes people even come up with good ideas after
a few hours away from their keyboards. My own team, for example, had
some excellent points to make about things we need to accomplish.
So, either they came up with them over the weekend or I finally
slowed down enough over the weekend to really listen to them today.
Probably, given the nature of the world, a little bit of both.</p>


<p>It's the ?a
little bit of both? really struck home with me today. When people
get to moving fast, and pushing hard, we tend to focus in on one or
two things we believe to be important. These key issues become the
sole things we work on, regardless of everything else going on around
us. We work at them until we resolve them, then feel honest surprise
when the overarching problems do not go away.</p>


<p>In reality a lot
of problems (rather than incidents) in IT stem from multiple causes.
Most real, reoccurring problems involve some process pieces, personal
issues, misapplied or incorrectly configured technology, along with
some good old fashioned bad luck we didn't notice at the time. It
all kind of lurks around in the background until some relatively
random event creates an incident bringing all of the related causes
to the surface. Sorting out what's really going on, though, can take
a lot of work and a level head.</p>


<p>Right now, for
example, we've just finished work on an incident which disrupted
service for almost five days last week. Everyone involved struggled
with the system; we eventually fell back and punted rather than keep
fighting with it. The workaround did stabilize the situation for
now. With luck it will keep things mostly stable while we figure the
rest of it out.</p>


<p>Everyone's focus
currently rests with the effort we went though. Yes, we did not
communicate as well as we could have. Yes, our teams did not always
share information in an actionable way. It also took us a while to
figure out a good workaround.</p>


<p>My interest, and
where I've asked my team to focus in on this week, falls squarely on
the problems the incident exposed. The lack of technical planning,
environmental consistency, and practical methods for troubleshooting
just start the list. Far more fascinating was how the incident
displayed preconceptions and fractures in the lines of
authority/responsibility surrounding the technology in question.
These are long standing architectural and systemic issues no one can
solve quickly. Seeing them in action, though, renewed my commitment
to initiating slow change.</p>


<p>Meanwhile, in
another forum, the same problems played themselves out during our
preparations to restart a project plagued by technical glitches. It
made for interesting listening, even though I mostly stayed out of
it. I'm still questioning that decision, but if after working with
the project manager, my senior on the project, and a half dozen other
folks we couldn't win the battles that mattered I probably need to
find another job. Fortunately we got what we needed in terms of
scheduling; everything else was a sacrifice we happily made. Tying
my senior up for two more weeks wreaks havoc with my scheduling, but
I want to make this work for a lot of reasons.</p>


<p>That doesn't mean,
though, that the team isn't feeling the heat from having the senior
out of action for this long. I've pushed an assessment job down onto
one of my intermediates; he's a good guy and very talented. But its
his first serious assessment and its not something he's ready for.
That said, he'll do a **** of a job with some help and coaching. I
just have to somehow get the time to do that coaching while still
making it to all of my meetings.</p>


<p>The same problems
also came to a head over on another team's plate this afternoon.
Generally that's something which causes me to offer my sympathy. In
this case, though, it directly impacts all of my projects and my
currently deployed systems. The other team's work is good but I have
to question whether we've lost sight of the core technical problems
they want to address. More importantly, if we have lost sight of
those problems what can I, as an outsider and not a well liked one at
that, do about it?</p>


<p>So, it's the usual
mix of negotiations and scheduling planned for the week plus a heavy dose of coaching for everyone involved. Including, I
hope, me. I'm going to try to get in touch with one of my mentors to
discuss some issues that came up last week.</p>

Collapse -

How Incidents Become Disasters

by Shannon Kalvar In reply to The Mumbling Manager

<p>Well, its been a
busy week. We learned a few things, stuck to the plan as much as we
could, and went out with a bang. Fortunately no one got seriously
injured in the process, though I had to drop my pride in a bucket
again. And again. And again. They tell me it's good for me.</p>


<p>You see, we had
several issues arise this week. The fact that the issues themselves
arose doesn't come as a shock to anyone; life as an IT person tends
to involve incidents of varying magnitudes. However, the concept in
my last blog came into play heavily.
</p>


<p>Incidents bring
issues to our attention which we then address first though
workarounds and then though problem analysis and resolution. You
find this method, described different ways, in all kinds of customer
service and operations approaches. What they don't talk about is the
catalyzing effects of incidents on the general systemic problems
</p>


<p>Let's follow the
logic. Many incidents begin as random events. You load patches
you've loaded a dozen times before and the server bombs out. You try
to install software on a server image already in production on fifty
servers and the installation generates a run-time error. A user
calls in because a Windows server's print spooler decided to stop
working.</p>


<p>The repercussions
of the event, though, play out within the context created by history.
The server which bombed out may be part of an ongoing dispute
between two departments, a dispute raging over half a decade
regarding the importance of a system which accidentally became both
mission critical and without a business continuance plan.</p>


<p>Resolving the
incident by working around the issue requires good technical skills.
You need to be levelheaded, determined, and willing to take some
risks. You need to know when to wait, when to gather information,
and when to plunge forward knowing you might not have THE ANSWER but
that you have an answer which might work. Mastering those skills
takes quite enough time and patience from anyone.</p>


<p>Now add to that
the understandable panic of people caught without a business
continuance plan. So now the business has stopped, enterprise-wide.
The blame gets laid at your feet, not to mention the heat you
personally feel because, despite what others may think, IT folks
generally want to do a good job. We don't like taking down systems,
especially after our test showed we wouldn't.</p>


<p>Now add on top of
the previous two points that the system, due to political
compromises, never performed well. Your leadership knew it was going
to go down disastrously at some point. It went down twice a week in
a modestly controlled fashion before four months of tuning brought it
into an almost stable configuration. So now a fractured management
team must face their worst nightmare; they gambled and lost. Big
time. How they respond will tell you a lot about who they are and
why they do what they do.</p>


<p>Just to put a pin
in it, make it so the system drops on the evening before another
system is about to re-pilot after being down for a month for repairs.
The system that dropped is in the same group as the other system, so
in the end the same managers become ultimately responsible.</p>


<p>It's not that all
of our hard-won technical skills mean jack. It's just that, in the
anatomy of a disaster, the actual technical incident only modestly
affects the events as they unfold. We can resolve the incident,
create workarounds for the issues exposed, and resolve the problems
yet still lose the war. An incident may close in a matter of hours,
yet it will reverberate for months as structural issues play
themselves out.</p>


<p>So, what do we do?
As a leader I try to keep the non-technical elements of the disaster
off my team's plate. As a manager, accidental or otherwise, I try to
keep the team focused on activities leading to greater operational
stability. As an IT architect with training in risk mitigation and
system design I feel deep and abiding pain every time I look at the
way the organization chose to deploy some systems and support others.
That last is just pride, though, and does not belong in the role I
currently play.</p>


<p>Thus back to my
comment about swallowing pride. I don't make decisions; I just try
to keep people from getting destroyed by the choices they make.
Sometimes my team can pull it off. Other times we've got too much to
do and not enough time to follow though with the basic mantra of
incident to issue to problem I laid out above. Without each part of
the team playing their part we really cannot do it.</p>


<p>But no one wants
to hear about the problems. It's all just ?excuses?. The user
community does need help and they need it now.</p>


<p>Ah, Monday's going
to be great fun.</p>

Collapse -

How Incidents Become Disasters

by charles.harmon6 In reply to How Incidents Become Disa ...
Collapse -

How to Let Go the Hard Way

by Shannon Kalvar In reply to The Mumbling Manager

<p>I hate falling
sick. I hate being sick. I hate going to work, realizing I need to
spend quality time with my bathroom, and coming home. I hate
dropping all of my work off onto my team...</p>


<p>...oh, wait. My
primary work supposedly revolves around assisting my team in
organizing their time. Doesn't it? Or have I fallen into that old
trap of trying to do too much as an ?individual contributor?,
proving my worth by doing rather than helping.</p>


<p>It's hard to tell
when you are on the right path. As a rule I try to pass tasks from
me to my team; I act kind of like a task collector, moving though the
environment and pilling up work, which I then hand off to more
capable people to accomplish. When a task comes up suddenly,
especially a busywork task I don't want disrupting my team's work, I
take it on my own plate and get it done as fast as possible.</p>


<p>Today, for
example, I meandered into work early to help with some reboots. I
don't like asking my team to come in before 6AM as a rule and I
thought I would be at my desk most of the day, baring meetings.
Besides, I may be rusty but I can handle remote rebooting an NT
server. Shutdown.exe is an old and dear friend.</p>


<p>Should I have
given that task to, say, the department on-call person? Probably.
He is paid to come in to deal with that kind of thing. But the
servers were my responsibility. I wanted to get some planning work
done before the day started. Yada. Yada. Yada....there's always a
reason, always a noble intent behind taking on more activity rather
than doing my work.</p>


<p>Being sick
actually helped me. It forced me to let go of a lot of excess tasks
I horded up. My team can handle them, mostly better than I can, so
long as I define them properly. Doing just that took most of the
morning. Apparently I horded a bit more work than I thought I had.</p>


<p>Now they've
dispersed, though, and I might actually be able to do my job of
planning and assessing the operational and project needs of my team's
lines of service. After I get back from spending more quality time
in the bathroom.</p>

Collapse -

How to Let Go the Hard Way

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

<p class="MsoNormal"><font face="Times new roman" size="3">It is not easy to judge how many jobs should be delegated to next level. Only ?good? manager can do it right. (I have to admit that I am not the one.) However, we ought to keep this in mind and try to do it everyday, every time. You cann't be success unless you have started your first step.</font></p>
<p class="MsoNormal"><?xml:namespace prefix =" o" ns =" "urn:schemas-microsoft-com:office:office"" /><o><font face="Times new roman" size="3"> </font></o></p>
<p class="MsoNormal"><font face="Times new roman" size="3">On the other hand, you should able to aware any potential problem and step in at the right time before it is too late. </font></p>
<p> </p>

Collapse -

How to Let Go the Hard Way

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

<p class="MsoNormal"><font face="Times new roman" size="3">It is not easy to judge how many jobs should be delegated to next level. Only ?good? manager can do it right. (I have to admit that I am not the one.) However, we ought to keep this in mind and try to do it everyday, every time. You cann't be success unless you have started your first step.</font></p>
<p class="MsoNormal"><?xml:namespace prefix =" o" /><o><font face="Times new roman" size="3"> </font></o></p>
<p class="MsoNormal"><font face="Times new roman" size="3">On the other hand, you should able to aware any potential problem and step in at the right time before it is too late. </font></p>
<p> </p>

Collapse -

How to Let Go the Hard Way

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

<p class="MsoNormal"><font face="Times new roman" size="3">It is not easy to judge how many jobs should be delegated to next level. Only ?good? manager can do it right. (I have to admit that I am not the one.) However, we ought to keep this in mind and try to do it everyday, every time. You cann't be success unless you have started your first step.</font></p>
<p class="MsoNormal"><?xml:namespace prefix =" o" /><o><font face="Times new roman" size="3"> </font></o></p>
<p class="MsoNormal"><font face="Times new roman" size="3">On the other hand, you should able to aware any potential problem and step in at the right time before it is too late.</font></p>

Collapse -

How to Let Go the Hard Way

by Ivy Clark In reply to How to Let Go the Hard Wa ...

<p>My team leader does this to me, and I hate it when he's not around.  I also hate not being able to provide the answers I need to (during his absence), as I do not have any idea as to what's happening.  It makes me look silly and helpless in front of my users.</p>
<p>It's also difficult for your colleagues to take on tasks you have been hoarding when you're away, if they have not been kept in the loop regarding the tasks and procedures involved.  Being able to pass on tasks while you're around helps ensure things run smoothly when you're not. So, you're really helping yourself - unless you want to remain available and accountable even when you're on that special holiday...</p>

Collapse -

How to Let Go the Hard Way

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

Not letting go of work is also one of the main we always think our team
members are not mature enough to handle sepcial tasks. Where as in fact
they do specially when you are physically away. I know of people who
always assigned their task to others and tried to stay away from
involving in minute details, these people later moved one to be
promoted and appriciated. The team we have is at our cost when
executives see us the count the team too. <br />
<br />
<br />

Collapse -

How to Let Go the Hard Way

by Ivy Clark In reply to How to Let Go the Hard Wa ...

yea..., it's a sign that the supervisor does't think his/her team members are ready to take on responsibility.  And whether it's a reality is another story.  Sadly, this is how upper level managers will view the team as well.  As a result, the whole team will miss out on opportunities of bigger, better, or more exciting projects. Everybody loses.

Related Discussions

Related Forums