Building better standups

Dog Days of DevOps 2025

Ian Littman / @ian@phpc.social / @ian.im / @iansltx

Slides at ian.im/dd25

Setting the stage: I work at Fleet

• Full remote (though a bunch of us are in Austin)
• Open-core (and a lot of our processes are public)
• Sprints every 3 weeks
• Minor releases every ~3 weeks, patches as needed
• 3 engineering teams, each with
  • 4-5 backend devs (varying degrees of full-stack) <- I am here
  • 1 each of primarily-FE dev, EM, product designer, QA
• I'm on the software team, which includes vuln management
  • Some of our workload gets delivered outside release cycles
  • Rituals are a little different team-to-team

Credit: Discussion at DevOpsDays Austin 2025

Standup Guiding principles

• Async what you can
• Unblock who you can
• Meetings should have agendas before and records after
  • Calls are generally recorded, including standups, which helps async-ness
• Focus on finishing (start at the right side of the board)
• Focus on the work rather than the people, except when unblocking people
• Don't let ritual work pile up
• Work in descending order of how many people need to be on the call

Implementation details

• Async standup init'd via Geekbot
  • Pings folks when they come online in the AM
  • Traditional questions
    • What did you do since last update
    • What will you do between now and next update
    • Blockers?
  • Dumped into team Slack; only blockers are discussed in the meeting
• Daily synchronous standup agenda (GDocs tabs FTW)
  • "Agenda" because folks can add items ahead of time
  • Meetings tend to run 30m...feels long but the ritual carries a lot of weight
• For the rest of this presentation, let's look at the doc