Patches our design team created for the event

I'm an engineer at Gusto. In my spare time, I teach middle- and high school-aged girls how to code. I do this because I want girls to know about all the career options that are available, even if their communities don’t.

As I was researching the best ways to get students interested in STEM fields, this sentence stood out:

"Girls become interested in so-called STEM subjects around the age of 11 and then quickly lose interest when they're 15."

Up until this point I had only focused on getting younger (i.e., elementary school) girls interested in computer science, hoping that the spark would last through college. But now I realized that I was missing a huge part of the equation.

Why girls lose interest in STEM starting in high school

High school is angsty.

Photo by Ben Mullins on Unsplash

I remember worrying about being liked by my friends and wanting to be noticed by a boy, all of which made it harder to focus on the future and who I wanted to be.

Had it not been for my desire to rebel against what society told me I couldn't accomplish, I don't know whether I would have continued to focus on STEM.

Today, most of my friends who are in STEM fields became interested in it after college. Welcoming people without formal training into roles they are capable of may be more common today, but it is still easier to prove to a prospective employer that you're worth hiring when you have formal training and start earlier.

This means that keeping young women interested in STEM — well beyond middle school — opens up more career opportunities for them earlier in life.

What we’re doing about it

While developing a program to keep girls interested in STEM, I was inspired by shadowing sessions we did with a Denver code school called Turing. In these sessions, post-high school web development students came to the Gusto office, took a tour, asked questions about working here, and then worked with an engineer for an hour.

Now that we were targeting high school students, who are younger, we needed to adjust our tactics. So here’s how we kicked off the program.

  • We partnered with Girl Scouts of Colorado, which has a large pool of engaged high school students. They set up an application for our event and included an announcement in a newsletter they send to high school Girl Scouts. Creating an application helped us find girls who were genuinely interested in the event and willing to put in a bit of effort to be part of it.
  • We made the experience worth students’ time. Since we anticipated that girls would be driving into Denver from the suburbs, we wanted to make each session longer (about four hours). This would give them a better travel-to-activity ratio.
  • We targeted all levels of experience. We assumed that some girls would have written code before and some probably wouldn't know the basic concepts of coding.
  • We went beyond just engineering. Unlike the Turing students who were further along in their STEM-journeys, we couldn’t assume that these younger girls had decided to do anything related to STEM. To account for this, we expanded our scope to include Product and Design.

Photo by STEMShare NSW on Unsplash

How we announced the program

I sat down with teacher-turned-engineer Stephanie Bentley, to go through the Colorado Academic Standards for Computer Science and draw connections between what we planned to do and what the state expects students to learn about CS.

For the announcement and application, our blurb looked like this:

Girl Scouts is partnering with Gusto, a Silicon Valley- and Denver-based technology company, to teach girls entering 10th, 11th, and 12th grades what it’s like to write code that solves a real-world problem! Gusto will host a group of girls for three (on November 16th, April 12th, and June 28th) four-hour (from 10am-2pm) "jam with software developers, product managers, and designers" sessions with lunch included. In each session, girls will get a taste of an average day as a developer - from creating a feature to finding and fixing bugs in the code. Over the three sessions, we’ll go through a design sprint to define a problem to tackle with software and design a solution. We hope to inspire a future cohort of computer scientists!

Missing school can be hard to justify, which is why we made sure the program addressed the state's computer science standards:

1.4 Large, complex problems can be broken down into smaller, more manageable components
2.3 Computer software is written for specific purposes
2.5 Client considerations drive system design
3.1 The creation of a computer program requires a design process
3.3 Collaborative tools, methods, and strategies can be used to design, develop, and update computational artifacts
3.4 Client-based design requirements and feedback are essential to a quality computational product or service

Planning beforehand only required a few hours a week for a few weeks, including a couple of meetings with Stephanie to make sure we weren't totally missing the mark.

The day of

On the day of the event, I met the girls and their parents, and signed them in. Then we all got on the same page by discussing:

  • Our goals for them
  • Our expectations for their participation
  • Who we are.
    • What are the teams here?
    • What is the structure?
    • How do Engineering, Product, and Design work together?
  • What do they want out of this?
    • What’s their background?
    • How familiar they actually are with code? (Depending on what they knew, we could target who they were shadowing.)

During the design sprint, we explained why we do design sprints and then what our goal for the day was — to pick a problem to tackle in the coming sessions.


We started by brainstorming. In ten minutes, each of us got a stack of post-its and a pen and wrote as many problems that we encounter in our daily lives as we could think of. We then explained each idea to the group and tried to group problems together as we went. Then the team voted on which problem we wanted to tackle together.

Once we had a winner, we spent the rest of our time digging into what problem we really wanted to solve and which angle was most interesting to all of us.

At the end of our session, we landed on the problem: Teenagers and adults have a hard time getting past discussions about the weather and into a deeper conversation. So how can we fix that?

Since the group was pretty evenly split between teenagers and adults, we felt particularly able to explore and solve this problem.

Talking about the generational gap is valuable on both sides: adults can share their school and work experiences, and teenagers provide fresh insights. In the design sprint sessions to come, we will nail down the root cause of this gap and start designing a solution to the problem and define an MVP.

High school kids are smarter than you think

One of my concerns at the start of the day was that we were throwing too much at these students in such a short period of time. However, no one was too shy to interrupt, ask for clarification, or express particular interest in a concept.

While explaining a tool that my team manages, how we deploy, and what happens as a result of deployment to one of the students, I was grateful that I had jumped right in and allowed her to pick our direction by asking good questions.

In our debrief at the end of the day, we asked everyone:

  • What was the most valuable part of the day?
  • What could you have done without?
  • Do you have any general feedback on how everything went?

We learned that while it's still valuable to ask participants what they thought in-person, there might be a better way to do this. Maybe we could have asked throughout the day, for rankings 1-10 for different activities, or in a way that gave them anonymity. This is something we'll be changing before the next two sessions.

Re-reading the articles that led to this program, I remembered that girls often have misconceptions about STEM. When we ask for feedback in the next two sessions, I'll focus on understanding whether we are addressing these common issues:

What we hope to do next

In the next five months, we'll have two more sessions like this where we finish our design sprint and continue to demonstrate the social, logical, and transformative nature of writing software. Designing and creating a solution to a problem transforms it from a nebulous annoyance into a functional product.

By pairing with the girls, eating lunch together, and allowing them to observe engineers working together, we hope they see that good code is written when people feel comfortable to bounce ideas off each other and pool their collective knowledge.

I'm excited to see what we learn about why girls do or do not pursue STEM — and whether our program can make a difference.