Gabriel Márquez

Speaker view / 01

How software teams actually ship

Select a slide below to review what to present. Keep this tab beside the presentation window.

Title

How software teams actually ship

30 minutes · Developers and QA professionals

Opening notes

Welcome the viewer. Explain that this is one lesson in the eight-part Job-Ready Software Engineering series. Set up the outcome before beginning.

01

Build evidence, not just knowledge

The workflow behind the job title

Speaker notes

Welcome. This series is about becoming easier to hire because you can show how you work, not because you memorized more tools. Today we will make the software delivery process visible.

02

The real job is a chain of decisions

  • User problem
  • Requirement
  • Design
  • Code
  • Review
  • Test
  • Release
  • Feedback
Speaker notes

Software work is not only writing code or executing test cases. It is a chain of decisions: what problem are we solving, what is in scope, what could fail, and how do we know the change is safe?

03

A ticket is a conversation

  • Problem and user
  • Expected behavior
  • Constraints and non-goals
  • Acceptance criteria
  • Open questions
Speaker notes

A ticket is a starting point for clarifying behavior. Good acceptance criteria make the work testable. “Add applications” is vague; “a user can save a company, role, URL, status, and next action” is easier to design and test.

04

The delivery loop

  • Understand the change
  • Make the smallest useful implementation
  • Ask for review
  • Verify the behavior
  • Release and observe
Speaker notes

This is a loop, not a waterfall. We learn during implementation and testing. A pull request is a checkpoint, not the finish line.

05

Developers and QA share the outcome

  • Developers: implementation and unit tests
  • QA: exploration and risk analysis
  • Everyone: user outcome, evidence, and release confidence
Speaker notes

Strong teams do not treat QA as the final gate or developers as people who only produce code. Developers should think about risk and testability. QA should understand enough of the system to investigate behavior.

06

Demo: map one Launchpad feature

Ticket → API endpoint → database row → UI form → tests → CI

Speaker notes

Open the Launchpad repository. Show the ticket, API route, data model, form, tests, and CI configuration. Keep this a tour, not a deep dive.

07

Pause: map your feature

  • Request
  • Code change
  • Test evidence
  • Release step
  • Feedback signal
Speaker notes

Pause the video. Choose something small, such as password reset, adding a test case, or exporting a report.

08

Your artifact

  • Create a one-page delivery map
  • Name your target role
  • Choose one skill to practice next
Speaker notes

This is the first portfolio artifact. It needs to show that you can see software work end to end. Next time we will turn one step in this loop into a professional GitHub contribution.

End

Make the artifact.

Publish your work, then continue to the next lesson.

Closing notes

Repeat the artifact viewers should create. Invite them to subscribe and join the future live cohort waitlist.