A little more than 4 years ago, I was at #dlrn15 hearing Jim Groom talk about Domain of One's Own, and Eddie Maloney talking the graduate degree they were developing, the one that would become the MA in Learning, Design, and Technology. I was about to start at UMW, and Jim's talk was daunting to me, realizing what I was about to embark on, where I was about to go. My reaction to Eddie's talk was that I would have loved to be able to get a degree like the one he was describing.

Little did I know that four  years later, I'd be at Domains 19, presenting about my experience teaching in the LDT program with Georgetown Domains.

It was all a little surreal to me, being in that space, in my new roll, around many, many people I had met for the first time at #dlrn15. It feels like an amazing journey many of us have been on, from #dlrn15 to #domains17 to #domains19. Pilots turn into programs and projects, people move and grow with their lives and ideas. We have a quasi-family reunion, a community of people who share the same values and the belief that ed-tech can be done differently.

There's a really interesting and obvious divide in the Domains conference: between developers and development. What do I mean? Most ed-tech conference (at least academically oriented ones that I've been to) run along a different sort of divide (which often gets blurred): vendor and faculty development. Vendors boast about their tools. Faculty developers/technologists show how they helped faculty implimented said tool or technique into teaching. I see the presentations from faculty under the later category: implimentation, and the development of those in the room.

Rarely at ed-tech conferences do you hear from developers, outside of the sales pitch kinds of talks. At Domains, we hear from the developers, those maintaining the back-end of the instals, helping faculty make cool things (or sometimes right out doing it for them), solving problems with code and creativity. And then we also hear from the faculty development side, those who are trying to nurture systemic change within the institution, integrate the values and ethos of a project like Domains into the curriculum, into the culture of the institution.

I like going to both kinds of talks, even though I am firmly in the development end of the Domains community; I was thrilled to learn from a former colleague and friend that the digital fluency plan I spearheaded has been approved as part of the gen-ed update, and they are incorportating a "digitally intensive" course requirement and designation, alongside the already existing writing and speaking intensive designations and requirements. It feels good that a piece of work that I led is being implimented. The development side of my job worked.

But I work closely with the developers, and I enjoy hearing from them and learning from them. In particular, Tom Woodward's talk about faculty wanting hot dogs (seriously, go and watch it) really highlighted the affective work that goes into being a developer around a project like Domains; we care about the product, and so we also care when the faculty don't. That's a poor recap of the talk, but nonetheless, it drove home for me how emotionally difficult our work can be.

The divide, for me, is often that developers aren't interested in the work of development (Tom admitted as much about himself, and I've informally observed the same trend). Institutional change is long and hard and messy and imperfect. And, working with faculty (as Tom rightfully pointed out) can be heartbreaking because, well, somtimes (more often than we'd like) faculty just want hot-dogs, and you know that you could help them make a finer meal than that.

My development side wants to know why the faculty only want hot dogs. I want to understand where they are coming from and develop a strategy (or strategies) that help them get to the point where they don't want hot dogs, they won't settle for hot dogs. This is not, typically, in the job description of the developer, but deeply rooted in the job description for faculty development.

There was so much at this conference about challenging ourselves to imagine things (particularly around technology and surveillance) differently, move beyond our current master narrative (or imagine something other than hot dogs, I guess, to keep the analogy going past the point of it being particularly useful, but when has that ever stopped me). I think master narratives are important and powerful. And I think for Domain to be effective, it has to somehow become a part of the master narrative, of the collective university's imagination.

It's fortunate that Domains can be, well, anything, but that also means it is an ellusive concept or project or initiative for many faculty to get their heads around. But they do have an idea, a narrative, an imagined image of the university where they work, that they have aligned themselves with. How, then, can Domains become a part of that narrative, that imagined image, in order to help faculty understand, accept, and embrace Domains?

Because the developer's narrative about Domains is different than the development one. And vice-versa. It has to be. I call Domains the Trojan Horse for thinking about ed-tech, but most faculty don't think about ed-tech. They think about pedagogy and their discipline and research and students and tenure and promotion and the university community they are a part of. So what is the Trojan Horse that brings Domains to the faculty?

If I were being crass, I would ask, what's your university's Domains program's brand? And it is about branding, but moreso it is about the university's community's collective imagination about their institution.

Tom's conclusion was about finding and doing the work that matters to us. This is the work that matters to me; I want us to start imagining our universities as institutions differently, so that our students may start imaging the world differently. I think, no, I know that Domains can play an important role in this change (but is by no means that only one). I want to do the development work, with the developers, in order to figure out how.

You can check out my and many of the other #Domains19 presentation on the Reclaim Hosting YouTube channel.

Photo by Simone Hutsch on Unsplash