Making mentoring easier for teachers: the engineering behind Summit Learning Platform’s mentoring feature
The technology team on the Education initiative is the long-term engineering partner to the Summit Learning Program. Through Summit Learning, students learn through challenging projects that reflect the world around them; meet with a dedicated teacher mentor once a week to track progress towards their personal goals; and develop the invaluable lifelong skill of self-direction.
This holistic school experience is supported by the Summit Learning Platform, an online tool within the program that empowers teachers to customize instruction to meet the needs of each and every student while empowering students to learn in a variety of ways, set and track progress towards goals, and more. More than 330 schools and 60,000 students across 40 states are participating in the Summit Learning Program and using the Platform.
With the start of back to school season, we’re excited to talk about the tech work behind one of the latest features on the platform. Here’s an interview with Tom, an engineer on the education team.
What is the Mentoring Feature?
The mentoring feature takes one of the core components of the Summit Learning experience, which is a strong relationship between a student and teacher, and enhances it through the Platform. Each student is paired with a mentor — a teacher or faculty member who meets with the student on a weekly basis over the course of their entire time at
Our team worked with teachers to understand how they organized their mentoring schedule, and how the platform could help with this. The large amount of time that it takes to meet with every mentee was a challenge. Even if each meeting is only 15 minutes, meeting with a class of 25 students adds up to more than 6 hours each week. Teachers were often keeping track of complicated schedules and notes for each mentee by hand.
We wanted to give teachers a way to schedule check-ins through the platform, and create a shared mentorship experience between the student and the teacher. The platform also solicits reflections from students before they meet with their mentor, so that both mentors and mentees can be prepared for their check-ins.
What’s an interesting problem you solved when building it?
One of the tricky challenges I ran into with this was the complexity of scheduling. We wanted to create something that supported teachers in more easily identifying who needed support, when and with what. We also wanted to provide them with the flexibility to handle a range of scenarios. A student might be sick, or a teacher might want to move a student up a particular week because they need to prioritize them. Even beyond building all of those options, it’s still challenging.
A key strategy was creating a unit test harness that enumerated all the different cases our code would have to handle. For instance, since students are asked to respond to reflection questions for check-ins the day before, what does it mean when a teacher schedules a check-in for a Monday holiday, and it’s currently Friday? Should the check-in get scheduled for Tuesday, or pushed to next week? The technical solution we found was to build a unit test harness to test all these cases before the code was actually written. I basically said, “this is how I expect the logic to behave in all these scenarios,” and then built the logic to meet those expectations.
Even though we created the unit test suite early on, there were cases I hadn’t considered that I eventually revisited. As part of evaluating the usefulness of the tool, I actually used the mentoring feature myself, with my own manager. During our weekly check-ins, we would use this feature to check-in on goals that I set for myself. Being able to see the product in the real world context made bugs I ran into much more visceral. For example, initially, we thought students would only do reflections the day of their check-in. But when I had a 10 am meeting with my manager Monday morning, and couldn’t do my reflection until midnight, it felt like a really blocking experience. I realized students would need to be able to do it the day before, especially for early morning check-ins. When I experienced these situations, I realized how essential some of the edge cases can be.
Why did you join CZI as an engineer? What do you like about engineering at CZI?
I’d spent a lot of time working on consumer products before joining CZI, and felt that there was a large focus on squeezing as much usage out of users as possible, but not necessarily providing the functionality that they needed or were asking for. I wanted to move back to a product where there would be a strong demand for functionality and where what was built was driven by feedback from the users — in this case, teachers and students.
I also felt that the education space didn’t get nearly the amount of tech support that it needed. Getting to contribute to the technology experiences of these students and teachers felt like it offered room to really improve their experiences. One thing I really like about being an engineer at CZI is working on these passionate, well-established teams that are still very small and intimate. I know all of engineers on our team pretty well. I have a rough sense of what everyone is working on. In other organizations, you often lose that sense of cohesion. I’m confident we’ll maintain that cohesion as the organization grows.