Years ago, science fiction writer Jerry Pournelle used to rant in his Byte Magazine column about the tyranny of the "high priesthood" of computing that stood between computer users and computers. Pournelle thought that the advent of personal computing was going to eliminate that priesthood. In a lot of ways, it did. Data manipulation and writing now happen on the pc — or tablet — not the corporate mainframe. It's been a lot of years, and we may have forgotten that it was a real battle to make this change. People smuggled PCs into their offices, downloaded data to them on the sly and fought against staid IT staff that forbade it.
The battle's still being fought in lots of organizations — over web publishing. And, ironically, one of the insurgents of the last war is now sitting in the gatekeeper position: the departmental (or small business) webmaster.
I was reminded of this by seeing yet-another advertisement by a university department seeking a webmaster. Qualifications: light web design, knowledge of "XXX" blog system, light system administration, some PHP/Javascript helpful. Job description: maintain and enhance the departmental web site; publish information from faculty and staff on the site.
Does your organization have a job with this description? If so, you've got a bottleneck. Your webmaster may not be a high priest guarding a mainframe, but she or he is none-the-less the gatekeeper for your major communications channel. And, instead of distributing responsibility for your web content throughout your organization, you've concentrated it.
Years ago, that webmaster position was emancipatory. It meant that your organization didn't have to go through the university or corporate IT folks to get your content online. But, now that position is a solid barrier that prevents you from becoming an aggressive user of the web.
It's hard to break the webmaster's lock. Your departmental web-publishing system was probably chosen by a webmaster who had a single criteria: does this system make it easy for me, the webmaster, to control and maintain a web site? Questions of whether or not the software would make it easy to distribute responsibility into the organization were probably not considered. A symptom of this is that your web-publishing software began as a blogging system for techies. The title "content management system" got tacked on later. But it still, all these years later, is more oriented to empowering the webmaster than distributing web responsibilities through the organization. And, years later, you're composing a job description centered around that software.
It gets worse
Yesterday's departmental webmaster may have graduated to become a school or division webmaster. Now, she or he is helping select the next generation of web-publishing software. And his or her first question may be: does it make it easy for my successor (with my old skills) to control a departmental web site? This is how solutions that are poorly designed for distribution of responsibility end up being the standard solution for a large organization.
What's the solution?
If I knew how to break bureaucratic inertia like this, I'd probably have a different job description myself. But here are a few ideas.
For the departmental or small-office webmaster, consider a different job description. How about: train and assist staff and faculty in maintaining and organizing their own content. Will work with multiple departments or organizational units. Information architecture expertise sufficient to evaluate site organization and interface problems and recommend solutions. Excellent communication skills key. Programming or system administration experience not required or helpful. A communications or library science degree could be the ticket.
OK, you say, but somebody's got to maintain the web-publishing system. Frankly, that should be happening at least a level up, by a person with excellent (not light) system administration or dev-op skills. Programming experience in shell-scripting and two or more of Python, Perl, Java and Ruby. And she or he should be maintaining the content-management systems for several departments. And, should have excellent (not light) design/UI people available as resources. None of those people are writing content or helping people get it in the right spot in the website.
And the school or division "webmaster?" First criteria is knowledge of web-publishing software that goes far beyond systems that began as blogs. They should be comfortable with terms like workflow and privilege separation. They should care about distributing web responsibilities to the nodes of the organization. She or he should know a lot about security and authentication; terms like "granular permissions" shouldn't make them blink. And the word "webmaster" is not in the job title.