Who Actually Works in Tech

At a Glance

Lesson Plan Notes Who Actually Works in Tech

Many students sign up for computer science classes because they love video games and want to create them. They typically don’t realize that there are more people involved on the team beyond the coders and designers. They don’t know a Product Manager exists. They’ve never heard of QA. UX and UI are treated as the same thing, or as an afterthought. Helping students to see that there’s a real team effort and diverse skill set behind their favorite video game, app, or other software is what this is all about.

It’s important to emphasize that teamwork is integral to building software. By integrating teamwork and technology in this lesson, we are well-positioned for future work such as creating a resume, highlighting our skills, participating in a mock interview, and building a portfolio. The unit officially begins with an understanding of the value and necessity of collaboration, a theme that will recur throughout the school year.

What the lesson actually is

Students research four common software product team roles — Product Manager, UX/UI Designer, Full-Stack Engineer, and QA Engineer — and build out a profile card for each one: what the role actually does day to day, five sourced responsibilities (with a real named source next to each one, not just “I read it somewhere”), the hard and soft skills the role requires, and the tools people in that role actually use.

Then there’s a section I care about more than any other part of this worksheet: an AI Shift Analysis. For each role, students must name specific AI tools that are changing how that job is done and describe a concrete workflow change — not a vague “AI will change everything” statement. This isn’t a bonus add-on. I built it in because I’ve sat on the other side of hiring panels, and “does this candidate understand how their field is actually changing” is a real signal I looked for, not a hypothetical.

Why sourcing matters here

Every fact students record needs a named organization directly next to it. “Google” or “ChatGPT” alone isn’t a source — it gets zero credit for that line. This is deliberate. Students tend to grab answers from AI without thinking about where they came from. So I’m not just teaching them about tech roles; I’m teaching them to distinguish a real, checkable claim from a vibe. That’s a research skill that outlasts this specific worksheet.

What I look for when I grade it

I’m not looking for verbatim copying — a pile of text lifted straight from a source and pasted onto the page tells me nothing about whether a student understood it. I’m looking for synthesis: the student’s own language, condensed, showing they actually processed what they read. Specificity beats polish every time. A vague sentence about “AI helping with coding” earns less credit than one that names GitHub Copilot and describes exactly what changes when an engineer uses it.

Students teach each other

The jigsaw aspect of this project involves students learning in small groups and demonstrating their learning by teaching the entire class. Each group will present their software product team role to the rest of the class. When I’ve done this, I get the opportunity to observe the outgoing students and the quieter ones. Students can use Google Slides or PowerPoint to present. At the end of all the presentations, you can combine everyone’s slides in order to share with the entire class. Emphasize the importance of presenting and sharing with the class as a skill that will serve them in other classes and beyond the classroom as employees.