Our district recently lost a couple of long-time staff members. As most of you know, when you work in education for a while, it is very easy to absorb a myriad of functions. It is also rare that anyone writes down exactly what these functions are or how to do them. Imagine as IT personnel - How many of your passwords are documented? How many other people know administrative passwords, sites, or even server architectures? How many people in your school could reset a router or administer a firewall? How many people even know where your firewall is?
If you have a large IT support staff and savvy teachers and administrators, then you're probably quite replaceable. On the other hand, if you are part of a small district or have limited resources for IT staffing and support (a far more likely scenario in K-12 ed tech), then there are going to be some very clueless teachers and administrators walking around if you get hit by a school bus. Or bail for greener pastures in the private sector, or have a baby, or get abducted by aliens, or whatever.
So what's my point? When we lost the above-mentioned staff, we very quickly realized that no one in the district fully understood the payroll system or knew any of the administrative passwords on the district servers. Fortunately, I happened to remember a generic password that one of our hardware vendors used frequently and was able to reset passwords as necessary. In terms of payroll, we brought back a retired accountant as a consultant to train the remaining staff and still didn't manage to get paid on time.
What this all really comes down to is documentation. Sure, network admins (at least in Windows-Land) are a dime-a-dozen. But if no one knows where your backbone switches are, or where the wireless routers are located in the ceilings, or who to call when the T1 goes down, your replacement is going to be in very sorry shape.
Some people consider a degree of secrecy to be an essential ingredient in job security. However, a high degree of competence should be the only security that most of us need. Part of competence in this field is the ability to document systems ad nauseum. Staff who have fallen into an IT role may struggle a great deal with this, but those of us with a bit more experience understand that detailed documentation of all systems makes those systems transparent, easily maintained, and easily taken over in the event of problems. In fact, documentation of this sort makes your job easier in the long run even if you don't get hit by a bus. How much easier is it to delegate if clear documentation exists for any given system? How much easier is it to redesign or improve a system if you fully understand what you're working with?
Documentation with excrutiating detail may be painful for all of us who would really rather be pulling cable or building databases or designing new approaches to ed tech. However, it is not nearly as painful for you as a transition period after a tragic bus accident is for your end users or your replacements. This is not only an issue of best practices, but also of work ethic and moral responsibility to ensure that your systems can successfully outlive any one human being.