One of my biggest concerns about the Sakai community from Day 1 has been the need to involve more teachers more directly in the design of the platform. I think that when people hear that they sometimes think of those painfully ineffective design-by-committee initiatives that universities always try and that never work. That’s not really what I had in mind. At the Amsterdam conference, I heard Michael Korcuska express my concern in a way that’s much more clear and effective than anything I’ve formulated on the topic.
He said the Sakai community needs a Product Manager role. And that’s exactly right. We need product managers, many of whom should be teachers.
Maybe Michael’s point resonates with me so strongly because it fits so closely with my personal history and personal inclinations. I am literally a product manager. I started off as a teacher who wanted better teaching tools, and who wanted to use better teaching tools to give teachers more and, occasionally, better ways of teaching. I have ended up working at Oracle Corporation with the job title of Principal Product Manager. My job is to understand the needs of the users and to be able to express those needs in ways that are useful to the developers. I need to know a bit about technology and a bit about user experience, but mostly, I’m a translator. I speak both Teacherese and Geekese.
If you look around the educational technology community in general and the Sakai community in particular, you won’t have to look too hard to find folks with similar stories. Craig Counterman of MIT once said, “I am a technologist, but only out of self-defense.” There’s no question that some of our developers are also gifted and passionate teachers. But we need to broaden the base. We need art historians and musicologists, cognitive psychologists and anthropologists. We have the perspective of teaching different disciplines to different students. We also need teachers who can learn what they need to communicate with the technologists but don’t take to it so naturally that they begin to think like technologists. We need people who know how to write use cases and functional requirements, and who also know how to elicit use cases and functional requirements.
So how do we do that? How do we find those people? We use the same method that open source uses to find talent in general–with a big spigot pouring into a meritocratic funnel. You attract as many participants as possible, and then you let the ones who are most able (both because of skill and because of drive) to have more say in what actually gets built. The meritocratic part is relatively easier, particularly since the community is getting very good at sharing designs and soliciting feedback early in development. The harder part is getting a big enough spigot in the first place. We’ll know we have a big enough talent pool when the Sakai pedagogy forum is at least as busy as the Sakai development forum.
So how do we do that? How do we gain participation? Well, it’s a bit of a chicken-and-egg thing. Once again, following the lessons of successful open source projects, we should recognize that people join first and foremost to scratch their own itches. The trouble is that it’s a bit difficult for non-developers to scratch their own itches in this environment. We need to give them back scratchers to get them started.
I suggest that the Sakai community put together a strategy for identifying on-campus product management talent and then drawing that talent into greater community-wide participation. Chances are that many community campuses that are engaging in development work with a couple of these folks already. You can probably think of the ones at your school of the top of your head. They’re the ones who always pester you with crazy brilliant ideas for new tools. They’re the ones that drag you to the white board to sketch out what’s in their heads. They’re the ones that won’t leave you alone.
Let’s get some of those folks together. Put them through U-Camp. Make a point of holding up their contributions to the community. Start a social network. There are lots of ways that we could do this. I’m convinced that all the raw materials exist in the community for this to happen. We just need to connect the dots.
Jason Shao says
Since Rutgers Sakai team has good contact with many of our teachers, though few developers I’ve had some discussions with the FLUID folks about how we might engage. Given that we have an integrated development/support/instructional design group it seems to be a very doable model, and one I’m hopeful we can get traction on going forward.
Michael Feldstein says
That’s great to hear, Jason. Have you thought about giving a presentation on how you work together at one of the Sakai conferences?