Advice for Future Implementations

Part of the InTeGrate Gustavus Adolphus College Program Model

Consideration of Context

Gustavus is a relatively small institution (~200 faculty members; ~2400 students) with a strong sense of community among the faculty. For example, our college has a shared-governance structure, which means the faculty are already actively involved in college affairs and members know each other fairly well. Therefore, when our leadership team sought hosts to participate in this project and develop modules, our colleagues already had a sense of our team members' abilities and personalities. We believe that made it easier for us to recruit participants for this project. Even so, we spent time issuing personal invitations and department-specific invitations, with our best attempt at suggesting discipline-specific possibilities for climate science modules. For example, our email to the Political Science department posed questions that illustrated how climate science might fit into their existing courses: 'How and why has climate change become such a partisan subject in the U.S.? How are scientists involved in the political process? How do international treaties like the Kyoto Protocol evolve and succeed or fail?'

In an institution where faculty do not already know each other and/or are not in the habit of working together, we encourage you to personally reach out to colleagues in other departments to establish trust and a shared vision. This may take the form of personalized emails, phone calls, short promotional visits to department or division meetings, or inviting colleagues out for coffee. This advance work can be time-consuming, but you will likely learn a lot about your institution and be more able to succeed in this effort.

Also, our faculty feel very busy and are often not able to participate in 'extra' activities like this. Therefore, we believe the small monetary stipend we were able to provide was important. Several - though not all - participants mentioned that as an important factor in their decision to participate, because it acknowledged the value of their time and effort.

Things That Worked Well That We Would Do Again:

Small groups of faculty working together

Teaching circles consisting of 4-5 prospective host faculty members and 3-5 developer faculty members proved to be a good scale for sharing ideas and launching module development. We began with a short demonstration of what a module might look like, and then asked participants to talk about what they hoped to build into their courses. Some hosts came with plenty of enthusiasm but only a very vague idea of what a module might look like in their course. Other hosts were able to quickly generate learning outcomes and lesson plans. Either way, the limited size of the teaching circle meant that they could gain inspiration from each other and begin moving forward on plans. In the second half of each teaching circle, we assigned host-developer pairs based on the subject matter and expertise we had available.

Project led by faculty, not administrators

At our institution at that time, it was important to our faculty that this was not a "top down" project. We did have respected and tenured faculty on the leadership team, including some department chairs and the Faculty Senate vice-chair. The administration was very supportive of our efforts, was aware of the project, and was interested in the outcomes. However, the administration was not directly involved in any of the planning or execution of the work.

Enable and encourage communication between faculty members

This kind of teaching collaboration is hard work, particularly when partners are far apart in pedagogic style (e.g., humanities' discussion-oriented classroom culture vs. science's lecture-oriented culture). We developed a form to help facilitate communication of key information between development partners (Module process form (Microsoft Word 2007 (.docx) 15kB Sep20 16)). After exchanging that information, development partners were expected to spend 1-3 hours exchanging ideas via email and/or in personal meetings, depending on the complexity of the module topic.

We found that it was crucially important to test each module in a mock classroom; we used other developers as an audience, and the module was test-run with the host faculty member in the room. That gave the host a safe space to suggest and request modifications, to ask questions about the content, and to invite feedback from other experienced faculty, before the module was delivered to students.

Be clear about the end goal for each module

When we began the project, our goal was that each module would eventually be 'handed over' to the host and become self-sustaining in the host course, without continued participation from the developer. However, we learned that in some cases, the host faculty member placed very high value on the continued participation of the developer, and/or did not feel comfortable teaching the content themselves even after a couple of iterations. Sometimes the developer enjoys and wants to maintain ongoing participation in the host class, but that may not always be feasible. Therefore, hosts and developers need to be clear about whether they can have an ongoing co-teaching relationship. If the module must be truly self-sustaining, then it needs to be carefully designed so that the host is entirely comfortable taking over.

Setbacks

Sometimes, faculty retire, leave the institution or change their courses. Sometimes the modules you develop are not going to find a home right away. We have several modules that don't presently have a course home. However, we think that the content is applicable to a wide range of courses, and we're continuing to work with departments on campus to adapt these modules to different courses.

In addition, developers have changes in their priorities and demands on their time: they go on sabbatical, change their courses, etc. The team has to be adaptable and large enough to accommodate faculty work changes.

Things to Think About Before You Start This Type of Project

It's challenging

Interdisciplinary teaching collaboration is hard work and can be time-consuming. Therefore, adequate time must be allotted for developing and testing modules; they cannot be rushed into the classroom. While we would not change anything about the model we have here developed, we would suggest three things:

• Alert participating faculty to the fact that this is challenging work, and provide guidance when possible (e.g., the Module Process form above).
• Encourage faculty to visit each other's classrooms before developing the module, so they can better understand the full range of pedagogic possibilities and limitations.
• Encourage your institution to acknowledge both the importance and challenge of this collaborative work, and to compensate faculty accordingly.

Think creatively about your team members

Our team included traditional geoscientists (Geology and Geography) but also members of our Education, Physics, Biology and Environmental Studies departments. At small schools, lone geoscientists can find allies in unexpected places. The key characteristics for developers are familiarity with the climate science literature, and the willingness to adapt that content to diverse courses.