The documentation discussion is very useful and important, but you asked soem other questions too!
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. Always be honest. To your management, to your team, and to your customers/clients. Tell them when you don't know the answer, or you or your team made a mistake. > 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. Since you have an existing situation where you are about to manage someone who used to be your peer, you have to find the right balance, especially as you add more staff. You and he or she have to talk about what it means that you are now the manager. Ask that person what they want from you as a manager. Be prepared to tell him or her what you want/expect from them. As you add more staff, you will have to make sure that the one staff person from before you became the manager doesn't get too much "special status" from having been peers before. Of course, since they are (I assume) senior to new people, or at least have been working with you longer, there is going to be some of that no matter what. > 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. Make sure, as a manager, that you establish a good relationship with your technical partners (customers?) -- the applications team and user support team. When I became the manager of my group (I had been the #2, but not allowed to manage), I told them that my #1 job was to enable them to succeed in doing their job. I've reminded them of that, and tried hard to do that. > 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. non-routine issues by definition are a problem -- if they were routine, you could have already solved them via documentation or automation or both. To be able to handle non-routine issues requires deeper understanding of the system, which documentation may not be able to cover. As other have said, often sysadmins shy away from writing documentation, perhaps becuase they aim too high. For complex potentially non-routine issues, don't try and document all the possible problems. Instead, focus on 1) the big picture (what are all the components of this system; 2) pointers to external docs and books; 3) what configuration choices or special cases/exceptions make your installation of this system different from "the book" > * 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. Metrics are difficult. Metrics can change people's behavior -- that can be good or bad. Make sure you are measuring things that are meaningful to your organization, team and useful to you as a manager. The classic extreme example is if your metric is "tickets closed", then everyone has the incentive to close tickets quickly -- even if they aren't handled correctly. I would ask your management how they judge the success of your team (don't ask them to specify specific metrics), and ask your customers what they consider most important. Also ask your team. Then, with your team, see what one or two metrics you can use -- keep it simple, and make sure that your team knows how the metrics are being used. Let us know what works.. we can all learn from each other Good luck! --david _______________________________________________ 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/
