On Tue, Aug 10, 2010 at 9:05 PM, Jefferson Cowart <[email protected]> wrote:
> I have recently found myself promoted from being on a team of two
> network/system administrators to managing the team, and I'm looking for
> a few bits of advice.
>
> Here's a little overview of our team. Right now the team consists of
> myself and one other person, although the expectation is we will be
> hiring at least one and possibly two more people onto the team. We
> support ~75 servers (mostly Windows with a handful of Linux - fairly
> heterogeneous in configuration/hosted applications), about 3 dozen
> network switches, wireless, along with associated storage and backup. We
> also provide networking support for the VoIP infrastructure which is
> primarily run by our phone office. This team manages everything from the
> operating system down the stack on all servers (~50% are virtual on ESX)
> and manages a few core applications (DHCP/DNS/Active
> Directory/E-Mail/etc). Most of our high-level applications are managed
> by a separate applications team. There is also a user support team that
> handles most support requests, although we are an escalation path from
> that team.
>
> In addition to any general comments you may have about managing system
> administrators I also have a few specific questions:
>
> * In a small team managing [what I think to be] a fairly diverse
> environment like ours how do you handle [cross-]training/redundancy? I
> know there are a large number of things right now that no one other than
> me knows how to do. I think I have the everyday issues well documented,
> but non-routine issues may cause issues.
> * What are metrics that I should be looking at monitoring/measuring for
> the team (both as a whole and individually)? There are obvious things to
> look at in terms of outages and support requests (number handled/time to
> resolution), but I suspect there are other things that make sense to
> look at.
>
> Additionally any pointers to books/websites/etc. that you think cover
> this topic would be welcome.
>
> --
> Thanks
> Jefferson Cowart
> [email protected]
I have read this book and can recommend it:
http://www.amazon.com/Leading-Geeks-Manage-Deliver-Technology/dp/0787961485
It deals with the "squishy" side of management, which is really where
everything happens in management.
As tech people, we always start talking about tools to use.
Management is not about tools, it's about the people, tools are just
something people use. Don't focus on the tools as much as the
benefits they give you. Some people here have mentioned wikis,
documentation, etc... which are all valid, but they are not the goal.
The goal is to have both people and technology managed well, and if
you can get that message across to the people, the tools and docs will
follow naturally.
Also, there is a difference between "management" and "leadership".
Management is mostly mundane things like tracking vacation, project
management, etc... Leadership is setting a vision and showing others
how and why to achieve the vision. You want to be a leader and not a
manager (even though you still have to do the management stuff).
For metrics, it's simple: do you feel like people are getting their
work done, or not? Are they doing things in a sustainable way, or
hacking things to get them done quickly? This is another area tech
people want some kind of tool to tracking things, like a ticketing
system or something. You definitely need a ticketing system, but it
SHOULD NOT be used to track individual performance, and at no time
should people feel like they have to constantly update tickets to
*justify* *their* *job* (they need to be updated for other reasons,
but not that).
If you focus only on how many tickets are open/closed/assigned for
each person, you create an environment where the only goal is to close
them, regardless of the quality of the resolution. The best thing to
do is to go through tickets with people once in a while and see if
they need help closing anything, and what you can do as the manager to
help. Taken from the GTD book, ask "what's the next action?" when
doing this (I can also recommend Getting Things Done by David Allen,
since I've now mentioned that as well).
It would also be helpful to study economics and follow some of the
other recent ideas about what drives people to do things. It's not
tech, but neither is management. You need to start studying and
understanding people as much as you do computers.
_______________________________________________
Discuss mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
