In many larger organizations, there is often a push to put things in a certain “order” that administration (non-educators and non-developers) is comfortable with. In the case of higher-ed, especially with its large, cubicle-seated, vertically organized groups, there is a strong trend to divide technology into The student learning management system (LMS) that covers “all” students’ teaching and learning needs, and into The content management system (CMS) that, managed by marketing people, is meant for “administrative” websites. And, of course, research is under a separate VP and thus needs to have its own systems and staff. And so on, for all the lovely silos. The more broken down, the merrier; this system creates more bureaucracy, more reporting and analysis. It is disconnected both from within itself and from its users, so it requires more staff to keep it going, more managers and more analysts.
This approach is a very typical and also very wrong one, as the expertise and resources needed to run and support, let’s say CMS (seen as “administrative” or “marketing” tool, though some of the best research or teaching and learning websites are built using UBC CMS), are identical to those of an open publishing framework for teaching and learning (such as blog or wiki platforms) and shouldn’t be separated – one general, flexible and robust platform is capable of responding to most web needs. To further complicate things, in the administration’s desire to do things “properly” (like mid-’70s-IT properly) we are introducing too many flavours of unnecessary overhead or waste (Lean terminology), known as learning or web strategists (my title actually, though I wear few other hats), project managers, business analysts, faculty liaisons and many other fancy names.
We work (teach, design, code…) in the environment of rapid and constant change (perpetual beta) and by building so many layers between the faculty member who wants to experiment and embrace change, and the developer who wants to give, hack and create change, we are actually killing the experiment and killing the change itself. We kill creativity and innovation, while we are supposed to support it. By stripping down web developers to the role of only coding whatever project manager or business analyst requires (and because managers and analysts are not creators and producers, they are not in business of inventing, hacking, dreaming and designing), we kill the much needed seeds of agility and entrepreneurship and we leave very little room for linchpins in us, with hard and practical skills.
That’s the shame, because the best of Web2.0 is telling us that we need to simplify things, not over-plan or over-analyse. Hear the idea, build, measure, learn. That’s why instead of many unnecessary roles, we need developers to be more of the generalists (Scott, thanks for this find) – for typical web company that’s the person that does information architecture, UX, coding front-end, back-end, db, scaling, bit of design; at the university, it is all of that plus bit of pedagogy and learning design. Not a biggy, few months of the right exposure for a reasonably intelligent individual.