################################################ # # # ## ## ###### ####### ## ## ## ## ## # # ## ## ## ## ## ### ## ## ## ## # # ## ## ## ## #### ## ## ## ## # # ## ## ###### ###### ## ## ## ## ### # # ## ## ## ## ## #### ## ## ## # # ## ## ## ## ## ## ### ## ## ## # # ####### ###### ####### ## ## ## ## ## # # # ################################################ The following paper was originally presented at the Ninth System Administration Conference (LISA '95) Monterey, California, September 18-22, 1995 It was published by USENIX Association in the Conference Proceedings of the Ninth System Administration Conference For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: office@usenix.org 4. WWW URL: https://www.usenix.org ^L From Something to Nothing (and back) Gretchen Phillips - University at Buffalo ABSTRACT This paper addresses the experience that I have had in making the transition from technician (UNIX systems administrator variety) to management. It discusses some of the issues that I have had to cope with in this unfamiliar territory. If this paper has any management-speak in it, it is only because I have included it by accident, as my background is as a technician. I won't say that nothing, but likely very little, in this paper has anything to do with management theory; rather it is just the experience that I have had over the past several years. Introduction - A Brief History It's been seven years since I presented my first LISA paper (Monterey) and six since my last (Austin), and something has happened to me in the intervening years. Where could six years of my life have gone? Have I done anything interesting in System Administration in this time? Have I done anything interesting in *any* field in this time? I'd like to address this paper to those system administrators who have grown from their technical roots and branched into what from a technician's point of view, appears to be nothing and to those who may one day step into the void. My daughters visited the office with me last fall and when we went home at the end of the day, they said "Mom, all you do is talk all day. What's your job?" I tried to explain to them that I go to meetings, I talk to people and I read (and sometimes answer) my mail. But after saying this, I realized that I too felt like I didn't really "do" anything anymore. I didn't have xmeters running on my screen watching the machines; I had extracted myself from any mailing list that actually monitors machines; I delayed in learning PERL until nearly every other human on the planet knew more than I did about it; I hadn't written a useful script of any kind in a very long time; I was feeling quite dissatisfied about the amount of work that I would get done in any day; sadly, I had become a manager. Persisting in this depression much longer than anyone would like, I finally snapped out and realized that not only do I do something; I go to meetings, I talk to people and I read (and sometimes answer) my mail; but that what I do is important and clearly some of the techniques that I'm using are valuable. This revelation occurred after returning to work after being sick (and I couldn't work from home) and finding a huge pile of things that needed attention on my desk and in my mailbox. And, not one of my technicians (system administrators) had attended to these matters. In fact, several projects were waiting for me to help them along to the next step. Making The Transition Making the transition from technician to supervisor has been one of the most challenging of my career. I am (IMHO) a good technician and from my annual reviews, my supervisors have agreed. Why was I picked to be the supervisor of a growing group? Well, to be perfectly honest, I was the group. So because of seniority, technical skill and potential (all nonsense in this case), I became the supervisor. Now, several years later, the group has seven members, and I am in the process of hiring four more as I write this paper. We have already started usurping available people from other groups just to keep up with our projects. Two of these will be transferred to my group when the current hiring process is over, giving a grand total of thirteen. It has not been an easy road and supervising twelve people is not at all like supervising one or two. Who Should Be Boss Sometimes a supervisor is promoted from within, sometimes they are brought in from the outside. Choosing a supervisor for technicians can be tricky. In my limited experience, I have found that technicians (system administrators) can be a fussy lot. Each one has their own area of specialty. Each one has their own way of doing a job. Each one has their own peculiarity(ies). Supervising a bunch (group to be articulate, horde to be precise) of system administrators can be a challenge. Picking the right supervisor can be equally challenging. Qualities of a Supervisor: What to look for I think that there are two levels at which someone should be evaluated when being considered for a position in management. The first level is abstract and includes qualities like: + the ability to learn and understand the material + the desire to work hard + initiative + creativity + personal integrity These qualities set the tone for the work environment. While exact technical skills may not be necessary, the supervisor must be able to understand both the material and the problems that the technicians will face. I think a supervisor cannot competently assign work if there isn't a clear understanding of the resources, time and expertise required to get the job done. It has been my experience that I work harder now as a supervisor than I did as a system administrator. (Is that possible?) I'm constantly concerned with all the projects, the big picture and the details of picking up the slack. If I didn't like to work hard, I'd be in the wrong job. Initiative and creativity are related to how projects and problems are approached. Both are necessary for the supervisor to be a leader. Finally, I think that there is no substitute for personal integrity, either inside or outside the work place. If I say that I'm going to do something, I'll do it. If someone else tells me they are going to do something, I expect that they will. If they don't, I'm likely to start avoiding interactions with that person. Supervisors aren't perfect with all of these qualities at all times. I'm not. My supervisor isn't. However, they are a foundation upon which good leadership and supervisory skills are built. At the second and more practical level, a supervisor must be able to (minimally): + delegate responsibilities + accept that a job might not be done the way she might do it herself + see the big picture + behave in meetings + speak in complete sentences Some of these may seem obvious, but they aren't to everyone. In fact, two of the things on the list may seem like they are a joke. They are not. It is important for a supervisor to be articulate and to have some self-control, thus the meetings and sentences entries on the list. The job of a supervisor isn't primarily technical. It is important to understand the work that your people do, but most of my time is spent going to meetings, reporting status, writing job descriptions or performance programs or other non-sysadmin stuff. There are some advantages to having a system administrator background before becoming a manager. I do understand the work that my group does. I can fill in when necessary if jobs get dropped on the floor. I use my organizational skills a lot because most of my time is now spent, going to meetings, talking to people, and shuffling paper (or bits). Becoming a Supervisor: What to work on Being a good technician doesn't automatically mean that you will be a good supervisor. The list above is a place to start when evaluating your skills. Start with the big picture and see if you can see where you fit as a worker into the organization. Start to appreciate the strengths of your co-workers. As a supervisor, you will need to appreciate the technical skills of others, so start to recognize them for what they are. They are not the competition. This is particularly important if you have the opportunity to move up within your organization (rather than changing companies or departments). I've heard it said, "Be polite to your enemies; some day they may be your friends." If you haven't had the opportunity to lead a project, ask for it. Take the lead on a new project and enlist the help of others. If this isn't possible, then start to show your talents in other working groups in which you participate. Ask the project leader for extra assignments. This will help you practice for leading a project of your own. But try not to get stuck doing all the managerial work without ever getting a commensurate recognition. Campus Network Committee Chair is the canonical example of work with no recognition. Be careful about taking projects that have no return. Learn (and use) the basics of spelling and grammar. You don't have to be an expert and know the proper time to use "that" or "which" but do learn the difference between "site" and "sight" and "your" and "you're". Simple things, like complete coherent thoughts, go a long way towards increasing your value as a supervisor. Management is a communication job, so points need to made clearly and with context. Self-control is an essential boss feature. Unfortunately, I never got in line for this quality, so I have had to learn it. Start practicing early. Learn when to speak and when not to. Play nice. Now, I don't mean cave in when pushed or sit silently at the abundant meetings, but do the things of playing nice at work. Be prepared; don't expect someone else to do your work. Be thoughtful; take your time when expressing yourself and think about how what you do and say will impact the situation. Be consistent; make sure people know what to expect from you and then give it consistently. Finally, be ready to politely stand your ground. I have found that having a good model to watch has been particularly useful in learning self-control. You needn't limit yourself to one role model and you can pick one from a variety of places. I learned a lot from my softball coach when he moved me from second base to third for one season. I complained and he said that he was the coach of the team and then gave several reasons, (that I understood and remembered at the time) one of which was for my own self-discipline. Watching how he handles the team gives me a model different than that of watching the various supervisors in my building. Observing how people respond and to what they respond helps me decide how to handle myself in different situations. Being generally more observant has been beneficial. Learning to be observant is again a matter of self-discipline. Finally, I still struggle when the people that I'm dealing with don't understand the material and I must repeat or restate or resend things. Often it isn't that they aren't listening, it's that they aren't understanding. In these cases, I need to be much more patient and give them time to absorb. I'm Your Co-worker and Your Supervisor Stepping into a supervisory position can be difficult, no matter what the circumstance. If you are hired from outside, the technicians can be justifiably tentative in the new situation. If you are promoted from within, there can be feelings of resentment, instead of good will. Making the transition to supervisor can be particularly difficult after having been one of the group. However, my own situation is neither of these, since there was no group until someone was hired to work with me. In the early days of my little group, the two of us worked together on all the projects, and while I was the supervisor on paper, we were more like a little team. As the group began to grow, and I did less technical work and more paperwork, there were times when my authority was challenged. I was looking at the big picture, all of the projects, while my technicians were primarily looking at their projects. Not only was our group growing, but the role of UNIX in the university was growing and changing. UNIX was becoming mainstream and used not just by the Computer Science Department or School of Engineering. My staff didn't like it when I said something had to be some way that was new or constraining. For example, picking the date to go to Solaris was a real battle. My supervisor wanted it as soon as possible, my staff wanted it never and I wanted it only when it would be reasonable. I must admit that we went forward with some of the staff kicking and screaming. I Am Your Supervisor Being the supervisor isn't a role that is inherited, it is a role that is earned. Dealing consistently with staff, remaining technically sharp and getting the job done are all important features of being a supervisor. These are important not only from the point of view of the workers but also from that of the supervisor's supervisor. My supervisor would pass me over in a second if I had a group that wasn't producing. And yet, he doesn't second guess my recommendations because we are getting the job done and we are working within his bounds. One thing that I think is important in the supervision process is having the authority that goes with the job. Fortunately for me, and my group, my supervisor does permit me to make decisions that directly affect my group. He isn't particularly concerned with which individuals I hire because I am the one that must work with them day to day and supervise them directly. He doesn't particularly care which software solution we might choose as long as it meets the criteria that we define at the outset. This hands-off style allows me the position of really being in charge of my group. In turn, my group looks to me for leadership, rather than looking past me to my supervisor. Sometimes, I must defer to his judgment or wishes, but for the most part, he lays out the projects and we solve them as we see fit. What's Important Figuring out what's important in the management role can be a difficult task. I wanted to keep doing the work, and for some period of time this was appropriate, however as my group grew, I had trouble (and sometimes I still do) figuring out what is important for me to do. It turns out that for my particular job, it is very important for me to talk to people. It is important that my technicians know what to do and that our clients know what we are doing. So, given a choice between working on a technical challenge or informing clients or staff about project status, it is more important for me to do the communicating and leave the technical challenge to my staff. Communication skills and communicating activities are important parts of my job. Letting Go and Hanging On It was hard for me to let go of my technical work. I am a fussy technician and like work done in a particular way. It was very hard for me to let go and see others do my work in a way that was not the way I would do it. Guiding the group, performing a leadership role, while letting go of the implementations is an important balance. If I tried to dictate every detail, my workers would hate me and I would be frustrated because the work still wouldn't be done the way I would like. Still, I can't have them running around doing things however each one pleases. I have found that developing their individual expertise, encouraging their ideas about how projects should be done and keeping them satisfied can be done by keeping my fingers out of their work, just as my supervisor keeps his out of mine. Additionally, when talking with other managers about collaborative projects, if it seems appropriate, I make the effort to mention specific good works of project members (no matter who the supervisor is) as well as mention to my supervisor when they are doing good work. This puts the credit where it belongs. I cannot hang onto credit that is not mine. Keeping Workers Happy It is possible to keep workers happy? I wasn't happy about my job as a manager for a long time because I didn't understand my role. Technicians can suffer from this same problem if they do not understand what their job is and how they fit in, and I don't just mean performance programs. As a manager, it is important to understand the dynamics of the group of people you work with. What Really Makes Happy Workers? There are some simple basics about what make people happy at work. In no particular order, they include: + Compensation + Flexibility + Recognition + Getting jobs done + Satisfactory working conditions (even better: excellent conditions) + Interesting projects I work for a state organization and compensation can be a serious problem. Salary figures are below industry for similar positions and direct benefits are usually satisfactory but not necessarily outstanding. I have found that making sure that my workers have satisfactory equipment to use from home (at office expense, not theirs), workstations, modems, office phone by-pass systems, travel to conferences and the like, is fundamental to making their work environment pleasant. Additionally, offering them the flexibility to work from home improves their working conditions and in turn their mood about the job. Providing simple things like printers in office areas, rather than only at the central print site, makes their work more efficient and makes them feel that their time and work is important. (It is.) Working conditions are an important part of the total workplace. Having a chair that fits, a table that's right and lighting that is agreeable are all simple but important ways to make the workplace more pleasant. Lighting and eye strain problems are pervasive in the workplace. Allowing each worker to customize their lighting to satisfy their personal needs can have great rewards. The workplace isn't a one-size-fits-all place. Each worker is has different recognition needs. Some are satisfied to work for a job well done and don't need special encouragement, while others need to be recognized with a good word. It doesn't cost me anything to say, "Thank you," when someone completes a job. If I get in the habit of appreciating and acknowledging the work of each of my technicians, it then doesn't matter who needs acknowledgment and who doesn't care about it, because everyone's contribution is being acknowledged. Finally, fitting the available work to the available staff can be a challenge too. In the long run, if technicians feel that their projects are stimulating, then I think, for the most part, things will be OK. Of course repetitious jobs are boring, but some people like that. Some really like the end user part of the support, some like the installation, others like the problem solving. Making sure that every one has some projects that they find truly interesting is important. Again, the workplace isn't one-size-fits-all. What Makes The Boss Happy (and Productive)? I find myself being surprised at the things that now make me happy at work. As a student in Computer Science, and later as a system administrator, I worked on projects for the adrenaline flow that came with accomplishing a task, finishing a program, or having a user finally go away happy. As a manager, I rarely get to have one of these encounters, so I must find other sources of satisfaction. I particularly enjoy the hiring process: the hunt for new technicians, the thrill of finding good ones. (More on this later.) I am finding satisfaction in the growth of my group; in the apparent confidence that my supervisor has in my management ability. These types of people interactions aren't something that I previously thought I would enjoy. Getting Things Done What does it mean to get something done? I know for sure that I am not a 100% type. However, I can't decide if I'm a 95% or a 105% type. By this I mean, some projects get to be 95% done and that's good enough and I say leave them. Others are finished and yet I want them improved, changed, or done to the final detail. As a technician, I was more in the 105% category. As a manager, I cannot demand 105% from my technicians, nor from myself because sometimes some parts of a project are out of my control. So, we just do the best we can and go to the next thing. As a manager, it is my job to say when a job is finished or not. The Big Picture Part of any management job is looking at the big picture; seeing all of the tasks that all of the technicians do. Having some idea about how they should be assigned and prioritized is important. Additionally, it is important to know when a project is complete enough, relative to other projects and priorities, that it can be closed, left behind or ignored. I get a feel for the big picture based on many things. These include: where we are in the academic year; where we are in the fiscal year; how much money we have left; what projects we currently have active; client resources for projects that need my staff; and of course, who wants to take a vacation and for how long. There is a certain cycle to our work based on the academic calendar; we have fixed deadlines that can't slip for some projects while others can slide weeks and sometimes months. Deciding what priority any particular project should have is a mixture of the resources and deadlines along with some amount of gut feeling when no clear priority exists. The Details Technicians are often detail driven. (I am.) Just one more feature, one more bug worked out, one more install finished. Details can prevent the big picture from being seen; the old forest and trees problem. It is the manager's job to decide which details are important (need attention) and which ones are the last 5% that can be ignored. This is a skill that I've had to learn. It has not come naturally. If a project is stalled, perhaps waiting on a controller or disk, I may be inclined to ignore the detail of price and say that we should pay whatever price is necessary to keep a project rolling. Under other less critical circumstances, I may ask more than one staff member to shop around, looking for the best price on hardware configurations. The detail of price sometimes can, and must, be ignored. The details ignored on any project are most often related to the deadlines of the project. Finally, sometimes details aren't ignored, they are simply deferred until resources are available. Preparing For New Duties Some of duties of a manager are different than those of a system administrator, and yet some of them are similar. Organizational skills are still important, just different things being organized. Users don't go away totally, their faces just change. My method of preparation has been to use my intuition in areas where I think I have some and try to read up on areas where I don't. Formal education is always a possibility but not a particularly simple one. If you decide that you want to go back to school and study management, be prepared to do a lot of work. There are many facets of the management role. The following sections give a brief overview of the kinds of things that I've encountered. Hiring Process Hiring for the State University of New York is a complicated process: papers filled out in a certain way, job description and postings of only 6 lines, review panels and the like. Finding a suitable set of candidates is one problem, picking one is another. Evaluating resumes turns out to be one of my favorite tasks. Some of the candidates are obviously inappropriate but as the field gets narrowed down, the adrenaline begins to build. I look forward to meeting these people, finding out what they really know and selecting one to work in our group. Doing the initial phone interviews is one of my least favorite parts of the hiring process. Speaking to someone who may be my potential prize, trying to determine if they are worth a personal interview is one of the hardest parts for me. The phone interview is a necessary part of the process though. A 15-20 minute phone interview can tell me if the candidate has potential since I don't have time to schedule personal interviews with all candidates who might be minimally qualified. Preparation for the personal interview can be as much work for the interviewer as for the interviewee. Figuring out what kinds of skills a candidate has and if those skills fit appropriately in your group can be a challenge. I try to focus on problem solving and ability to learn new material, rather than on specific facts known. In my most recent personal interview, the candidate asked me, "Don't you have any more questions for me?" I think he was genuinely surprised that I didn't ask many questions with right or wrong answers but focused more on his problem solving skills. Perhaps he wanted to show off some obscure tidbit that he had recently acquired but apparently he didn't get the chance. Performance Programs and Evaluations Depending on your organization, performance programs and evaluations may be either a big or small part of your job. I've found that using performance programs that are similar is an effective way of cutting the amount of time that I must spend preparing them. Customizations come in the details but the layout and tone are all the same. If your organization provides some template or form, by all means use it or make one of your own. Using evaluations effectively is another challenge for me. I want to use them primarily for a big praise of my technicians. It is often the only time the upper bosses ever see or hear the names of my people. I also try to make effective use of them for recognizing areas of improvement and suggesting other items where improvements are possible. Wording these can be a tricky task but I think worth it in the end. Meetings I go to meetings. I was unprepared for the amount of time that was consumed by going to meetings. It seemed for a while as if I spent most of my week with my notebook, going from conference room to conference room, office to office, meeting with people. As time passes, I am trying to teach others that information can be passed without face to face meetings. Although some days still seem as if I spend the entire day with a parade through my office or on the meeting circuit. With two groups, we have gone from weekly meetings to monthly updates with actual work happening on-line. One of these groups was a mixture of managers at my level and technicians from our groups and the other was of technicians from several different groups. This has not been an easy task but meetings are not my favorite thing so I've made an effort to encourage people to meet less and work more. The New You (Politics In Disguise) Most anyone will tell you that all work places are political entities. They are both formally and informally structured. People have supervisors and workers and there are unsaid political organisms also. I (like many others) prefer to keep as far out of any overt politics as possible, however there are some practical things that I have learned in the past several years. The thing that it has taken me the longest to learn, and I am still learning it daily, is to keep from stating my opinions as facts. The technician part of me can see a clear path from A to B or for solving problem Q but my clients don't have that mindset. They want to know the options, and ultimately want to make the final decision. Helping clients make the right choice is one of my new developing skills. This means laying out options and consequences and making sure that they fully understand the implications. Another simple maneuver is to refrain from expressing anything with the word you in it. This keeps clients from feeling that they must be on the defensive. Notice the difference in tone between: + If you don't back up the disks and there is a failure, you will lose data. + If the disks are not backed up and there is a failure, data will be lost. It's a matter of rereading everything that I write and a small price to pay for the good will that it creates. Keeping Technical Skills Sharp Keeping my technical skills at a reasonable level continues to be a difficult task. My primary difficulty here is finding the time to keep up. I depend heavily on my staff to help me keep up to date. I often find myself asking, Where do we keep ...? or How did you ...?, but my staff doesn't appear to mind telling me as long as I don't repeatedly ask. Also, this gives them an opportunity to talk about what they've done and demonstrates that I think that it was interesting enough to ask about. (I think that as long as I don't act like a user, I'll be OK.) I gave up reading the trade rags and now just glance through them when I see something interesting. Again I am depending on my staff to let me know about things that are not obviously thrilling but perhaps interesting in our environment. Is Management Vocabulary A Waste Of Time? Part of my so called management training was an invitation to Service Excellence Assemblies. I carefully avoided attending these meetings but there was a lot of chatter among other managers about thinking up projects that would provide examples of service excellence. I was coerced by my then-supervisor into writing up one of my then-current projects and submitting it for consideration for a Service Excellence Award. I got the award. In my opinion, service excellence isn't a matter of contrived projects; it is a matter of excellent service. The concepts that are the foundation of the buzz words of management, like diversity and team building, only became clear when I experienced or really observed them in their natural forms. Contrived team building is a waste of time. Setting people to work together on a common goal with shared responsibility and due recognition is a worthwhile project. I genuinely think that the vocabulary makes no sense until there is some concrete context and even then it still sometimes appears artificial. This isn't to say that the vocabulary is a complete waste of time, simply that the vocabulary should be neither the means nor the end, it should be the descriptor. Diversity Some people might say that my group is diverse because we have a rich racial mix, or because we have 4 men and 3 women or because we come from a wide variety of social backgrounds. While these things may be building blocks of diversity, I have found that in fact our group is in some ways quite homogeneous. We are all in the 25-40 age range, we all consider our work our hobby and are amazed that someone pays us to do it, and every one has that just-right smattering of compulsive personality. Our work habits are about the same, as are our hours and one person can, for the most part, pick up work that another has dropped with little difficulty. Yet, there is diversity in the group. I learned this lesson the hard way when I jokingly told one of my young members to lose his tie. He dutifully left it at home but I later realized that he was more comfortable wearing it since he was working with administration personnel and all of his clients were wearing them. They were expecting him to meet their dress code and I was expecting him to meet mine (I foolishly thought I didn't have one). Another area of diversity is learning styles. I have some technicians who just dive in and try things out, others read the manuals, while still others learn best with formal classroom training. It is important for me to provide them learning environments that fit their learning styles. It is equally important for them to understand that it isn't appropriate to send everyone to the same kinds of training. Related to this is assigning projects that work with learning styles. Troubleshooters need to be the type that dive in and figure things out. End user support might better be done by those that love to read the manuals. Finally, I have people in my group who love the end user part of system administration. I have others that hate it. I have one worker who will gladly pitch in on any project and the others find it comforting to know that he is available to help if they need him. He isn't my best technician but I wouldn't trade him for the world because he adds stability and kindness to our group. Team Building/TQM I will gladly lump Team Building and TQM into the same worthless vocabulary box. Applying artificial mechanisms on the top of a broken management technique doesn't work. I worked for a man who tried this. I can attest from the bottom that it doesn't work so I wouldn't try it from the middle or top. However, the underlying theory of having workers not only feel responsible but be responsible for their situation does work. If I have achieved this at all, it has been by allowing my technicians the opportunity to voice their interest in specific projects and then by giving them both the responsibility and the credit for projects well done. If things appear to be going not exactly right, I'll ask if they need anything, resources, help, or whatever. Often, knowing that I'm available with resources is enough to help them through. Everyone realizes that we draw from the same pool of resources so if they are short this time and call out extra resources, they know that they'll be called upon in the future when someone else is short. Actually, the group is now large enough that there are some subgroups beginning to form where they independently help one another out on stressful projects. Time Management About two years ago, I was assigned the task of surveying all of Technical Services to see what skills the technicians would like to improve. Several said they needed help with time management. (My group didn't answer me at all, I guess that they didn't have time.) I have no key to solving the problem of too many projects and customers and not enough resources to handle them all. One relief that I do offer my staff is that if they are having trouble prioritizing their tasks, they can feel free to ask me to do it for them and I will then take any heat that they get as a result. They have found this to be a workable solution because they can spend their time working on projects, rather than explaining to any particular customer why that project isn't being done at the moment. Basically, I run interference for them but it does free up their valuable technical time to get projects done. Time management for myself is a different problem as I spend way too much time in meetings and talking on the phone. But, as I have realized over the last several months, this is in fact what I'm being paid to do. Things I still hate I sometimes think that I would be much happier if I were still exclusively a technician. Some of the parts of being a manager really do not appeal to me. Yet, I am aware that I would be much less happy if someone else were trying to tell me what to do, or leading projects in a way that I didn't like. As a result, I do things I don't like. Performance Programs and Appraisals I understand the need for technicians (and even managers) to know what their jobs are and to be able to know what is expected of them. I also understand that it's good to know how you are doing on your projects. The bureaucratic organization that I work in makes it almost impossible for me to reward good performance and yet I am required to annually review the performance of all my technicians. My group will soon expand from 6 direct reports to 12. This means more paperwork than I will ever want to do in my entire life. Time Wasters Finally, the thing I dislike the most are those projects, meetings or people that waste time. It frustrates me to no end when people say they want to have a meeting about some nonsense thing or they want their Graduate Assistant to come an interview me about my input on some project that has no bearing on my group or our work. I am a technician at heart. I'm goal-oriented and like to see concrete results. I like to see projects completed, be they machine installations or finishing the paperwork for a new hire. To this end, I try, as best as possible, to avoid things that don't give me that satisfaction. Conclusion While this paper does not cover the traditional areas of System Administration, it does present the experience of a technician turned supervisor. I hope that it has been of value to those who are supervisors, those who want to be supervisors and those who aren't and don't want to be. For that last group, perhaps understanding better how to get the best out of their boss will help them be more effective in their jobs. Is there conclusion? I by no means feel that I know all the issues related to management of technicians. I've only just recently learned that management has content. There are many things for me still to learn. Also, my management environment has changed frequently. I have had three different supervisors, worked in two different divisions of CIT, and had my group grow from just me to 12 full time direct reports. I don't expect there to be a time where I think, This is it. I've arrived. There are always new things to learn, new projects to tackle and improvements to be made. However, I do feel that despite all my idealism (and perhaps naivete), that there is no substitute for treating people kindly, caring about their needs and making their work experience as pleasant as possible. This is, after all, how I like to be treated by my supervisor. Acknowledgments This paper would not have been possible if, somewhere along the way, someone hadn't thought that I had supervisory potential. Thank you to that someone. Thanks to my supervisor, Chuck Dunn, for giving me the work environment that I have and for thinking it was a good idea to write this paper. Also, thanks to Lisa, Paul, Daniel, Zach, An-Tzu, and Andy for putting up with me daily. And finally, thank you to Dave Carr, John Quarterman and Gail Rein for reading this paper while in progress. Everyone should be so fortunate as to have friends like you. Thank you. Author Information Gretchen Phillips is the Manager of the UNIX Support Group in Technical Services at the University at Buffalo. She has been working in UNIX System Administration since 1983. She can be reached at gretchen@acsu.buffalo.edu References Schoenberg, Robert T.; The Art of Being a Boss Harper & Row 1978 Shurter, Robert L.; Effective Letters in Business The Gregg Publishing Company 1948 Tarshis, Barry; Grammar for Smart People Pocket Books 1992 Yate, Martin; Hiring the Best Bob Adams Inc. 1993