Re: Number of admins per number of users

[Jim Dennis <jimd@starshine.org>]

> Bennett> There are only two of us, administrators, at the site.
> Bennett> Lately I have become overwhelmed with things to do.  It
> Bennett> is probably a common thing but I was wondering
> Bennett> "typically" how many admins are there at a site like
> Bennett> ours.
> Bennett>
> Bennett> At the risk of "boss bashing" I am the only technical
> Bennett> person at the site.  They, (HR), have mad mention about
> Bennett> hiring a person to support me.  I don't know what the
> Bennett> norm would be.
> Bennett> 1) Should we all be working on the same things?
 
> For a small shop, IME this is the way to go.
 
> Benefit: Having all resources able to work any task helps increase
> the timeliness of response.  Vacations and sick time don't cause a
> crisis.  You're forced to better document your work, since someone
> else might be the next person to pick it up.
 
> Drawbacks: The overhead of keeping each other informed goes up.
> It's easier to justify training if each person specializes. If
> each person specializes, the time to resolve a problem drops
> because that person has more relevant experience.  (I once worked
> in the electronics shop of a mid-size hospital.  We had a tech who
> maintained over 400 aging televisions in a few hours a week.  He
> had literally seen it all - he could usually diagnose the ailing
> part over the phone.)
 
> Bennett> 2) Should we departmentalize?
 
> Not in a shop of this size, unless you have data to show that
> you can divide the areas in such a way that the work is roughly
> equal.

	I think a hybrid approach is usually the best.  (It's also
	generally what the situation evolves into).

	So, you should each perform the core and routine operations
	while each specializes in some of the more specific issues.
	For example, one of you might be much more experienced with
	'sendmail' (or whatever MTA you use) while the other can
	knock out named.conf (or named.boot) files with wild
	abandon.

	Since the configuration of new servers, mail and DNS domains
	is relatively rare and usually planned for well in advance
	there's no business need to both cross-train in them
	extensively (You each might personally *want* to, as these
	are important SA skills you can use anywhere you go --- but
	that's different than a business case).

	At the same time general help desk responses, user and
	group management, deployment of new workstations, backups
	and recovery testing --- these are all core operations that
	you both *must* be adept at.
 
> Bennett> 3) Am I "not really" overwhelmed, but just think I am?

	If you have to ask...

	An SAs job includes "capacity planning" and "performance
	monitoring."  Your management almost certainly expects
	you to know when disks are full, mail is getting backlogged
	due to insufficient bandwidth, RAM, or CPU power, etc.  
	You are probably expected to plan for these capacity 
	problems and either deal with them or recommend coping
	and/or expansion plans to your management.

	What you really want to understand is:

		You are a corporate resource.  You have a set of
		capacities like any other resource that you manage.

	So, to be effective you must monitor your own performance
	and recognize when you are "approach full."  

	Each of us has a limited amount of time and expertise. When
	the demands presented to us in our roles as SAs approaches
	those limits, the only responsible thing to do is to 
	cope with them as we would any other critical resources
	for which we are responsible.

	In general your options for coping with personal limitations
	are:

		burn out:  Work yourself to death --- put in
			immense amounts of overtime; usually as 
			unpaid contributions to your employer.

		* (Note:  I do NOT recommend this.  Unfortunately
		   it seems to be particularly popular among SAs
		   --- probably evidence of some widespread
		   towards feelings of inadequacy, inferiority
		   and insecurity among our ranks)

		increase your capacity:  You may be able to increase
			you expertise.  You might be able to
			automate some of the work you do now.  This
			is the old "work smarter not harder" saw.

		* (Note:  Notice that I said "may" and "might" ---
		   it may also be that you are already at peak 
		   efficiency.  Since "almost anything" under Unix
		   is scriptable or programmable it is likely that
		   *some* things that you do could be automated.
		   However, you are presumably a sysadmin and not a
		   programmer.  Although most of us do *some*
		   programming there are reasonable limitations to
		   what you management and users should expect of
		   you in this regard.  I've recommended "get a 
		   programmer" to my employers in the past.  It was
		   probably the best and most appropriate advice on 
		   those occasions). 

		delegate and/or re-distribute:  You might be able 
			to shift some of the responsibilities to 
			others in your organization.  This will
			probably require some training for the
			delegates --- presumably with a concommitant
			extra load on you (as the most likely
			trainer).

		* (This may be the best situation if there are
		   some employees at your site that are
		   "underutilized" but have the aptitude).

		recommend/aquire more resources:  Hire someone.


	Notice that I've made a list of possibilities.  I've noticed 
	that management usually responds better when given
	alternatives in the form of recommendations.  

	It is important to realize that you are involved in an
	ongoing process of negotiation.  This is true (to some
	degree) of all employees.  However, it seems to be
	frequently overlooked by sysadmins (and some other technical
	professionals).  I suspect that part of the reason for this
	stems from the nature of the job.

	Typically SAs are given responsibility for any technical
	duty for which there is no on-site specialist.  Thus some
	SAs handle all the telco maintenance and management at their
	sites.  Some SAs are DBAs, some do configuration management
	(they are the "buildmasters" for their sites --- which is
	more of a programming role than most).  Many SAs are web
	masters and some are CGI and Perl programmers.  Most of them
	either provide help desk services for their sites or are on
	the escalation path for their help desk personnel.

	Consequently our own management often doesn't know "what
	we do."  They will tend to shunt things our direction until
	things go haywire, or we start throwing things back.

	The trick is to know how to throw things back in a
	responsible and business-like manner.  This boils down to 
	"negotiation."
	
> You really can't determine how many sysadmins are needed by
> looking at the number of machines.  There are too many free
> variables, such as how much OJT you are expected to provide, how
> time-critical different problems are, and the diversity of
> problems you encounter.

	Yep.  A very rough rule of thumb is about 30 user/systems 
	per SA.  But I even hesitate to utter this number since
	there really are just too  many factors to consider.
 
> I would suggest that if you feel overwhelmed, you are.  However,
	
	ABSOLUTELY!

> this may not indicate a resource problem.  I would talk to your
> boss, and ask whether your job is to make the computers happy or
> to make the users happy.  (Don't accept his/her first answer,
> "Both!").  Tell him/her that you will work a reasonable number of
> hours a week (negotiate a number between 40-50).  Indicate that
> you are willing to work off-hours if needed to avoid
> inconveniencing users; ask for a scheduled downtime if it will
> help.  You want to be seen as a team player.  If you're routinely
> working more than 45 hours a week something is wrong, or you
> should be receiving additional compensation.  Then - tell your
> boss that you intend to do a ruthless prioritization based on what
> he/she told you your job was, and that some users may complain.
> From that day on, every request fits into this 2-D continuum:

	I would elaborate on this point a bit.  Prioritization
	and requirements analysis are the basis for all of your
	negotiations.   Your boss probably doesn't have a 
	comprehensive list of your current responsibilities.  He
	or she probably has no idea how much time you spend on 
	what.

	If you make such a list, with estimates of the cost
	(in terms of your time) of each (and preferably with
	estimates of the costs or outlines of the risks for
	any failures that relate to them) --- then you are in
	an excellent negotiating position.

		"These are the things that I've been doing.
		 Which ones should we consider deferring or
		 re-assigning?"

	(In some cases you can recommend contractors and/or
	consultants to peform "catch-up" on short-term
	backlogs.  In other cases it will be obvious that
	additional permanent/indefinite help is required
	--- full or part time).

 
> 	      Important     ---->     Less Important
>          ----------------------------------------------------
> Time     |
> Critical |
> |	 |
> |	 |
> |	 |
> |	 |
> V	 |
> Less	 |
> Time	 |
> Critical |
 
> Start working jobs in the upper left corner, and tell users that
> jobs in the bottom right corner probably won't get done.  Then let
> the users and your boss decide whether they need to apply more
> resources.

	Yes!  Prioritization is an ongoing process.

--
Jim Dennis  (800) 938-4078		consulting@starshine.org
Proprietor, Starshine Technical Services:  http://www.starshine.org