The Organizational Drift

Several contradictory experiences of the last week allowed me to see a pattern. I had a few frustrating moments trying to navigate through UNC’s on-line catalogue. To say it is a mess is an understatement. Just try to find Elementary PTEP, the largest teacher education program on campus. The system of internal references broke down, the Index is incomplete, inconsistent, and confusing. No one can navigate it. At the same time I know that the University’s IT team is highly competent, and the web administrators are also very knowledgeable and dedicated. We have a problem that like most, cannot be blamed on individuals.

Our School had a retreat, a very productive one. It made me appreciate again the professional strength and dedication of my colleagues. Meetings like this make me remember why I chose to work in higher education: to hang out with smart people. I also had to look at some curricular pieces in the last two weeks, and was again impressed with the thoughtfulness and expertise that went into development of the programs and individual courses. Yet our programs seem to have gaps and overlaps.

What happens is what I would call organizational drift; it is somewhat related to the concept of organizational entropy. What happens is really simple. Let’s say a group of faculty have developed a new course together; they have a good understanding of the course, and all teach similar things. Then some of the original group members are replaced, so they teach the course slightly differently. The original authors also change and update the course as a matter of good pedagogical practice. While each section of the course is improved in comparison to the original design, they also drifted apart, sometime significantly. This creates a problem of inconsistency: the same course taught by different professors looks completely different.

Of course, the original course was designed to fit into a specific program or even to several programs. While the program was originally designed in a certain way, each of the courses have been continuously improved or just changed because of the faculty turn over. The drift is natural, inevitable, and wholly expected. The same happened to the catalogue: it is a complex system with internal references among multiple parts. Different people are in charge of the individual parts, and no one can have a view of the entire system. As the parts drift apart, the references disintegrate and the system collapses. Our programs are not in the Catalogue’s position yet: the systems were designed relatively recently, and designed rather well. They are small enough for some communication to take place and to maintain their integrity. Yet the tendency is evident; where there is flexibility, there is also the drift.

One solution is to limit change: to redesign once and for all, and them limit any change. Some organizations do that: here is your syllabus, here is your textbook, and this is how you’re going to teach. It leads to stagnation and turns people off, but such a solution hold the drift in check. It also very difficult to enforce in Academia: people chose to work here because they are creative, and like to experiment and be independent. Without change, we simply would not survive for a long time, because education is in constant flux, and we need to run just to remain on the same place. The standards movement is another version of the same solution: it seeks to limit certain parameters of change by introducing a permanent set of references around which everything must order itself. It does not work like this, because professors largely ignore the standards. Or, rather, we claim to follow the standards after the fact of delivering curriculum. We do this not out of stubbornness or defiance, but because standards are too crude to keep the system organized. We understand that standardization means the death of the system that loses its ability to innovate. On the local level, the curriculum approval process seeks to limit the drift. However, as everyone know, most people ignore officially approved syllabi, for the same reasons.

Another solution is to make all changes transparent and encourage all parts of the system to react to every change in one individual part. In other words, the solution is to have constant meetings, and make all changes totally visible, while adjusting every little part to every little change. We are planning to do something like this in our in-service days. Smaller institutions do that constantly, and are often very successful in designing coherent programs. They can do this over a lunch meeting with a few people. But for a larger organization like ours, such efforts if they are continuous would take enormous resources. The constant information flow will become incredibly taxing in terms of time and resources. Going back to the catalogue example, the second solution of that problem looks like this: all school directors plus the registrar staff plus IT (about fifty people?) would have to spend a day or two going through the catalogue page by page to ensure the coherence of the entire system. Of course, we simply cannot do that even if we wanted to. If I remember correctly, groups of Microsoft staff at one point read together millions of lines of code to eliminate bugs; this was a very expensive solution, and their programs are still buggy, mainly because they are so huge and because of the drift.

The third solution is, I a way, a combination of the first two: you’d break the system into smaller chunks, explicitly define responsibilities of each one towards another, limit any changes in relationships among the chunks, but allow changes and abundant information exchanges within the chunks. This solution has its own limitations. For example if we were to create small teams, one in charge of literacy instruction, and another in charge of, say Social Studies and Math methods, and then another working with Art, Music, and PE, OK, they would work fine to improve their specific area, but then the areas will start to drift from each other. As a result, we would have no unity on matter that run across different areas: knowledge of diversity, classroom management, sound assessments, etc. In other words, we would export entropy to a different level, as biologists might say, but there will be about the same amount of it in the system. And this is what we have been doing anyway.

The radical solution will have to be based with self-organization processes and with alternative ways of information flows. I don’t have the solution; I just have a vague idea, even less than an idea, an image, a dream. Somehow, I see our students keeping track of their own learning needs: what they already know, what skills they still lack and need to work on, and what they should learn. I see them constantly checking these skills and knowledge with a constantly available testing service and then entering requests for specific knowledge into a database. Here is what I need to learn in the next semester… Then the computer matches those requests against our faculty’s expertise, and voila, it delivers a schedule. It does not look like our present schedule; it is a lot more complex: we have courses that last from one day to the whole semester. They have long names like: Elementary Social studies curriculum with use of storytelling and ideas on classroom management in urban classrooms. Or: philosophies of education plus professional writing skills plus research skills. The schedule is different every semester; it prompts professors to gain expertise in areas that are in high demand, and constantly update what we already know. Those professors whose expertise is not in demand, have to leave or work as assistants to other, more effective professors. Students are in charge of their own learning; those who cannot master skills, are forced to leave; those who can do most of their learning on their own, save time and money. The distributed knowledge makes the system self-organizing: no one knows everything, but everyone knows what she or he needs.
Anyway, that’s my Saturday afternoon dream?