Ship Better Code, Faster

Appearance

Workshop 1: Slide Content ​

Deck: slides.pptx (25 slides, ~60 min) Theme: Software Delivery Lifecycle & Baseline Measurement

Each section below = one slide. The OAF template layout for each slide is noted in brackets. If you edit a slide, update both the .pptx and this file so they stay in sync.

Slide 1: Title [lavender title slide] ​

Wordmark (top): The Build Fellowship Title: Measuring software delivery. Eyebrow: Session 1 · May 2026

Slide 2: Welcome [white, headline + body] ​

Title: You made it. Welcome to the Fellowship. Subtitle: Welcome: what these eight weeks are Body: For the next eight weeks we will step into the shoes of a platform engineer at a real software company. We will measure things. We will break things. We will ship better. By the end you will have a portfolio-ready project that proves you can move an engineering team forward.

Slide 3: Agenda [dark blue, agenda layout] ​

Title: Agenda Bullets (5):

  • 15 min: Introductions & my path into platform engineering
  • 5 min: How the workshops work + expectations
  • 15 min: The software delivery lifecycle and why companies hire for it
  • 10 min: Clone the OrbitTasks repo onto your machine
  • 15 min: Measure the current pipeline, your first deliverable

Slide 4: About me [white, 2-column] ​

Title: Hi, I'm Riain. / Your fellow for the next 8 weeks. Left subhead: What I do Left body: Software engineer at PermitFlow. Background: [my degree / school / earlier work]. I've worked across backend, platform tooling, and AI-assisted engineering. Spent the last few years caring about how teams ship, not just what they ship. Right subhead: Where to ask me anything Right body: You should ask me about: war stories from production incidents, what the difference between "dev" and "platform" really feels like, or how to talk about your work in an interview. No question is too basic.

Slide 5: Quick check-in [dark, title + body + bullets] ​

Title: Your turn, who are you? / Round-robin, 60 seconds each. Body: Pick any two of the prompts below and share with the group. We'll go in the order Zoom shows you. Bullets (4):

  • Your name, school, and what you're studying
  • Why you applied to this project specifically
  • A piece of software you wish was less frustrating
  • One thing you want to walk out of these 8 weeks with

Slide 6: Section divider [dark blue] ​

Big text: How these / eight weeks work

Slide 7: The 8-week arc [white, title + body + bullets] ​

Title: From measuring the problem / to proposing the fix. Body: Every week you deliver one piece of a single, growing engineering proposal. By week 8 you've made the case end-to-end. Each week builds on the last. Here's the shape of the arc. Bullets (4):

  • Weeks 1–2: Measure the current pipeline and find the bottlenecks.
  • Weeks 3–4: Build a real CI/CD pipeline and improve developer experience.
  • Weeks 5–6: Use AI coding tools well, then prove the improvements with metrics.
  • Weeks 7–8: Set engineering standards and present the whole thing to stakeholders.

Slide 8: Working norms [lavender, 2-col] ​

Title: How we work / together for 8 weeks. Left subhead: Cameras on, ask anything Left body: These workshops are interactive. I want to see your faces and I want you to see each other. Use chat or unmute. If you're stuck on setup, you're probably not alone, so speak up early. Right subhead: We do the work together in session Right body: The core work happens live, together, in the hour. You don't take it home. Outside of session, expect up to 2 hours a week of optional polish or reading, never required to keep up. Workshop time is where the work gets done; everything else is bonus.

Slide 9: Section divider [dark blue] ​

Big text: The software / delivery lifecycle

Slide 10: What is the SDLC [white, headline + body] ​

Title: What is the Software Delivery Lifecycle? Subtitle: One sentence definition Body: The full path a single line of code takes from the moment an engineer writes it on their laptop to the moment a customer feels the result. A bottleneck anywhere along this path slows down the whole team, not just the engineer who wrote the code.

Slide 11: The 6 stages [white, title + body + bullets] ​

Title: Code → Customer / The stages of the lifecycle. Body: Every stage can become a bottleneck, and today we measure all of them. Bullets (4):

  • Code + Review: an engineer writes a change and a peer signs off on it.
  • Build: the codebase compiles into runnable artifacts.
  • Test: automated checks run against the build.
  • Deploy + Monitor: ship to customers and watch how it behaves in production.

Slide 12: Where time goes [white, headline + body] ​

Title: Where engineering time goes Subtitle: What the data shows Body: Across studies from DORA, SPACE, and Stripe's "Developer Coefficient" report, the pattern is consistent: engineers spend roughly half of every working hour fighting their own tools. Waiting on CI, setting up environments, investigating flaky tests, and reviewing PRs eat into the time available for actually writing code. For every hour writing code, engineers spend about an hour on toil. That's the problem this fellowship is about.

Slide 13: Careers [dark, title + body + bullets] ​

Title: Who gets paid / to do this work? Body: The skills you'll build over these eight weeks map directly to three well-paid engineering roles. Different companies use different titles, but the work overlaps heavily. Bullets (4):

  • DevOps Engineer ($120k–$180k): owns pipelines, deployment infra, monitoring.
  • Platform Engineer ($140k–$220k): builds the internal product other engineers use to ship.
  • Site Reliability Engineer ($150k–$230k): keeps the system up, defines SLOs, runs incident response.
  • All three start with the same question: where is engineering time being lost?

Slide 14: Industry examples [dark, title + body + bullets] ​

Title: A look behind / the curtain. Body: Four real engineering organizations, ordered from extreme to typical. Most companies you'll interview at look like the last one, not the first. Bullets (4):

  • Netflix: 4,000+ deploys per day. Every engineer can ship to prod safely.
  • Stripe: ~10 minutes from commit to production. Internal tools are a first-class product.
  • Shopify: their internal "Spin" platform boots a full dev env in under a minute.
  • A typical 50-person startup: a slow (~13-minute) CI, 2–3 deploys per week. This is OrbitTasks.

Slide 15: Section divider [dark blue] ​

Big text: Meet / OrbitTasks

Slide 16: OrbitTasks situation [dark, title + body + bullets] ​

Title: OrbitTasks: / the situation. Body: 28-person Series A startup. Project management SaaS. The pipeline is buckling. Bullets (4):

  • ~13 minutes: CI pipeline duration on every PR, and ~95% of it is one stage. Slow enough that you feel every run.
  • ~30%: share of test runs that fail for non-deterministic reasons.
  • 2 days: how long onboarding a new engineer takes today.
  • You: the platform engineer they just hired to fix all of this.

Slide 17: Clone the repo [white, 2-col] ​

Title: Step 1: clone / OrbitTasks locally. Left subhead: Run these commands Left body: git clone https://github.com/<TBA>/orbittasks.git, then cd orbittasks. Confirm node --version shows v20 or newer, then npm install. The exact repo URL goes in the chat. Take five minutes; I'll wait. Right subhead: If something breaks Right body: Drop the error message in chat. We will troubleshoot live; this is part of the work, not an interruption. If your machine is too constrained, pair with a neighbor and we'll get you set up afterward.

Slide 18: Verify your env [white, title + body + bullets] ​

Title: You should see / all of these. Body: If any of the four commands below produce errors or unexpected output, say so now, don't wait. Fixing setup in front of the group is part of the work. Bullets (4):

  • node --version: v20.x.x or newer.
  • npm --version: v10.x.x or newer.
  • git --version: any 2.x release is fine.
  • ls: should show apps/, scripts/, package.json at the project root.

Slide 19: Section divider [dark blue] ​

Big text: Establish / the baseline

Slide 20: Measurement plan [white, title + body + bullets] ​

Title: Three numbers / that matter today. Body: Numbers without observations are noise. Observations without numbers are opinions. We want both. Capture all three categories below as you run the pipeline. Bullets (4):

  • Wall-clock time per stage: how long from "I push" to "this stage finishes."
  • Pass / fail outcome: did the stage complete cleanly? What was the visible error?
  • Observations: anything that felt slow, redundant, or confusing. Gut reactions count.
  • We record all of this in your course logbook as we go. We reuse this data in Session 2.

Slide 21: Pipeline stages [white, headline + body] ​

Title: Eight stages, one row each Subtitle: Or: run npm run ci to do all eight in one go Body: We record each stage's duration in your logbook as we go. install: npm install (~7–90s). lint: npm run lint (~2s). typecheck: npm run typecheck (~2–3s). test:api: npm run test --workspace=apps/api (~12 min). test:web: npm run test --workspace=apps/web (~2–10s). build:api: npm run build --workspace=apps/api (~1s). build:web: npm run build --workspace=apps/web (~1s). deploy: npm run deploy (~18s). The wrapper script npm run ci writes a timing log to baseline.log automatically.

Slide 22: Hands-on [white, title + body + bullets] ​

Title: Run it. Watch it. / Write it down. Body: We run npm run ci at the repo root together. It will take ~13 minutes (almost all of it test:api), and that's expected. We capture observations in your logbook as it runs. Bullets (4, numbered as steps):

    1. Open your terminal at the project root.
    1. Run npm run ci. It writes to baseline.log.
    1. As it runs, we fill the W1 logbook section together. Note what surprises you.
    1. If a test fails, that's data, not a problem. Write down what failed and how.

Slide 23: Capture observations [dark, 2-col] ​

Title: What goes in / your logbook. Left subhead: Numbers Left body: Duration of each stage. Total wall-clock time end to end. Pass or fail per stage. How long npm install spent fetching versus actually installing. Right subhead: Observations Right body: Which stage felt slowest? Did any test fail, and was it repeatable? Anything that confused you or looked redundant? Gut reactions go here.

Slide 24: Session 2 preview [white, title + body + bullets] ​

Title: Session 2: Profiling / and Root Cause Diagnosis. Body: We'll pick up the data you just logged and tear it apart together. Three things we'll cover next time: Bullets (4):

  • Profiling techniques: finding the actual hot path in a pipeline, not just the obvious one.
  • 5 Whys and fishbone diagrams: industry frameworks for getting past symptoms to root cause.
  • Prioritization: which bottlenecks are worth fixing first, by impact and effort.
  • Keep your logbook; we reuse today's baseline numbers next week.

Slide 25: Questions [dark blue, Big Stat layout] ​

Big text: Questions?