Product Team at Minerva

Our mission is to nurture critical wisdom for the sake of the world.

Education has the power to transform individuals and enable them to solve the world’s most critical problems. We deeply believe that it’s critical to invest in education. We get the opportunity to do this every day and are transforming education at every level. We started with higher education, as that is the category the world looks to as the pace setter in education but we are branching out from there into professional learning and high schools.

We actively engage with our users at all levels. We are in the rare position to have a technology team working hand-in-hand with a stellar academic team asking how to make education better every day. In addition, we get to directly interact with students at Minerva Schools, watching them grow and thrive as the result of our work.

We get to work on hard and challenging technology problems. We are creating Minerva Forum, which is pushing boundaries of WebRTC and dynamic real time web applications in order to create a compelling education environment. You can see a video of Forum at work, learn more about the future of our platform, its latest features, and how it supports our global partnerships as part of this panel discussion at the ASU GSV Summit 2019 with our CEO Ben Nelson.

We are a collaborative team and our engineers, PMs, and designers work closely with our academic team members.

To support the interests and strengths of everyone on our team, there are various roles you can try out, or grow into. This isn’t a requirement, and thus some team members choose to focus on depth instead. Below is a little more information about what each of these roles do and who may be interested in them:

Product definition

One way that breadth shows up in this role is the overlap with product management work: sometimes, we need to be comfortable taking a high-level goal and figuring out how to get there, without a detailed spec. A few examples of these projects areas are performance optimization, capacity planning, and improving product stability. Other times there are more tangible specifications that come from working with our designers, product managers, and members of the academic team, like building specific new interfaces, product features, or entirely new products.

Tech lead

For folks who have not previously been in a technical leadership position but are interested in developing those skills, we have a tech lead role per engineering pod. We see Tech Lead as a role to play for a period of time, rather than a commitment along a career track.

High-level engineering support

We believe that being in touch with the challenges that our faculty and learners are running into helps to build a healthy sense of empathy and sense of product quality. We have engineering support rotations to periodically help out our frontline support staff.

Recruiting and interviewing

We include folks from across our team in the interviewing process. Whether you are seasoned at running interviews or completely new to it, we want to offer a way for you to be included in the interviewing process. We use pairing and shadowing in interview sessions to onboard and share knowledge.

We strongly believe that to be productive at work, you need to live your life in balance.

We built this into the culture from day one, ensuring everything from time in the office to vacation policy supports this. Yes, we occasionally need to sprint hard, but we rest up to make sure we have the energy to do so.

We have an unlimited vacation policy, and our Chief Product Officer sets an example from the top by actually taking PTO. We encourage folks to take at least four weeks per year, and many take up to six. We know how important it is to unwind away from the office and will gently chide someone (we’re looking at you Brian 👀😂) if they haven’t taken a vacation in a while. The office also largely shuts down around the December holidays.

We value new parents, and with our paid leave policy (12 weeks for the birth parent and 6 weeks for the non-birthing parent), we’re flexible about doing it all at once, parceling it out over time, or tapering back into work with a few days per week and extended work-from-home.

We didn’t start as remote workplace at first, but as we grew into a distributed team we strive to be remote-first.

And after all: one of the core pillars of Minerva as an educational system is that high-quality collaboration and deep intellectual contribution and growth can happen even when we are separated by great distances.

Our team is distributed across geographies and timezones. We are roughly 50% in the San Francisco Bay Area and 50% across the US and Europe. Thus our collaborative activities like meetings, pairing, and code reviews are designed to be remote by default. We try to keep the bigger team meetings in the Pacific Time mornings (usually 9am-11am), so that folks in the eastern US and in Europe can comfortably attend. Finally, we make sure to all meet in person at least once per year at an all company gathering, called Unitas. In addition, remote employees come through SF on as needed basis.

Everyone sets their own hours while ensuring they can attend scheduled team meetings and respond to requests from their teammates for questions and code review. Some folks start earlier or later to accommodate child care in the morning or afternoon, and others take an extra hour before or after lunch for the gym. Other members of the team travel for a few months during the year. Provided we've communicated this with the rest of the team in advance, we enjoy quite a bit of flexibility here.

Students and staff at an event in Berlin, one of the Minerva Schools global rotation cities.

We believe to have a fulfilling job as an engineer, you should be involved in a project from its earliest days, if not its conception, to the rollout and support amongst our users. We’ve adopted processes that encourage this at every step of the way:

1. Ideation and discovery: On the product team, you’ll work with the academic and business development teams to understand how software can support new curricular and pedagogical developments as well as secure and support partnerships. Everyone on the product team can submit proposals into our planning process, and is involved in the prioritization discussion at the beginning of each 15-week episode.
2. Full ownership over the implementation path: You’ll work on architecture, implementation, automated testing, code review, all the way through to shipping to production, which we do several times per week.
3. QA and operation: If it isn’t right, it isn’t complete — we own QA for our own features, and we’ll reach out for review or verification from our stakeholders when that’s helpful. We also run our deployment and monitoring infrastructure, and are responsible for whether our systems are working or not.

Students, faculty, and staff at a Minerva Schools year-end celebration.

Minerva is an education company built on a foundation of technology.

While we do make technology bets — our platform is predicated high-quality real-time video and collaboration across the globe — when it comes to planning what work we do, it’s all driven from the product perspective: how can we improve the student and instructor experience? How can we improve student learning outcomes by collecting information and surfacing feedback at just the right times? How can we improve A/V and platform reliability to make the technology fade into the background, so instructors and learners are deeply engaged in their discussions? What can we do on the Forum that we can’t do in physical classrooms?

To facilitate the Product first approach, we use a series of divergent and convergent exercises. Design sprints help us brainstorm new products and features in a structured fashion, and we give a large degree of autonomy to engineering pods to figure out how to best achieve their goals. These are often paired with constantly asking “How might we…?” to solve a scenario. To start converging, we use storyboards, prototypes, quick user testing, and finally episode planning.

Minerva students on the Forum.

Structured career development starts on day one.

At Minerva Project, we place a strong emphasis on professional development. This begins with a structured 90-day onboarding, which includes a plan for shipping code during week one. By day 90, you’ll have a comfortable foothold on one (or more) of the products outlined in your professional development goals and will be working with your manager to line those up with pods and projects.

The relationship with your manager is a two-way street. You should feel comfortable to regularly discuss potential areas for growth so your manager can advocate for you to take on appropriate stretch projects. You and your manager will regularly revisit your professional development goals. Just like we split product planning into multiple chunks during the year, we have multiple layers of professional development from high level year long goals to per project initiatives to make clear how your efforts at Minerva will grow your career.

We also have a budget to expense any technical book needed to help you learn more and a tuition assistance program of $3K per year for professional development events such as conferences, trainings, and workshops. For example, our teammates have been involved with Grace Hopper Celebration of Women in Computing (GHC), PyCon, and more. We also run internal book clubs and workshops, with recent examples including book clubs on The Manager’s Path by Camille Fournier and Switch by Dan and Chip Heath, and an introduction to Docker and Kubernetes workshop.

Staff and faculty at our all-company event in 2019.

It’s important that team members feel safe taking risks and showing vulnerability in front of each other.

Here are a few examples of techniques we use to ensure the team feels safe together:

After issues or outages, and as a regular check-in twice per quarter, we conduct blame-free retrospectives. The person facilitating the retro is responsible for making sure we focus on facts, actions, and effects, and critically evaluate the process that led to an event, not the individuals involved. We then put action steps in place to change our behavior for the future.

Product team members in lead positions model vulnerability by asking questions and discussing their failures in group settings. We also have a weekly informal dev Q&A discussion where we pose questions and geek out about various parts of our codebase. This reduces siloing and spreads knowledge, but it also sets an expectation that we’re all still learning and demonstrates that asking questions is warmly encouraged and met with enthusiastic and helpful discussion.

One of the most unusual aspects of our culture is that we run periodic peer feedback sessions. These sessions are unrelated to formal reviews or promotion. We provide coaching on tools like the Situation-Behavior-Impact model for these. These sessions both allow individual engineers to better understand what other members of the team are doing. But more than that, they are training ground for both how to give and receive feedback – skills that are often unpracticed and untaught until someone is suddenly promoted to management.

Minerva staff and students at Graduation 2019.