Performance Engineering

A 30-minute weekly meeting to keep the product fast and affordable at the load that's coming, and to leave with one owned fix.

Purpose

Keep the product fast enough and affordable at the load that's coming. Spot regressions early, tie them to a change, and leave with one owned fix. This meeting is about decisions. The analysis happens before it.

Who's in the Room

Performance engineering lead: owns the scorecard and presents it.
An SRE representative: brings capacity and incident links.
Pod representatives: only the pods with a regression or a launch coming, which changes week to week.
Once a month: product (upcoming launches) and platform or finance (cost).
You: facilitate, ask, decide, and unblock.

Before the Meeting

24 hours before: the performance lead updates the scorecard in the same format as every week. For each of the top 3 user journeys, it shows the slowest 5% of requests against its target, along with peak traffic, error rate under load, and cost per request.
Anyone with a regression brings one graph and one sentence about what changed.
You: read the scorecard and pick three questions from the Performance Engineering Meeting questions.

The Agenda

Time	Block	Ask
00–03	Last week's actionsDone, slipped, or dropped, and what each one changed.	"What did it change?" If something slipped: "What's in the way, and is it mine to unblock?"
03–10	ScorecardTop 3 user journeys against targets, plus peak traffic, errors under load, and cost per request. Only look at what's off target or trending the wrong way.	"Are we faster or slower than last week, against what target?"
10–17	RegressionsWhat got slower, what changed right before it, and whether it's our code, our capacity, or a dependency such as the model provider.	"What changed right before it?" Then: "Code, capacity, or dependency?"
17–24	Look aheadLaunches, campaigns, new customers, and model changes in the next 30 days, plus load test status for each.	"When did we last load test this, and at what multiple of peak?"
24–28	DecidePick the one fix that most improves what users feel for the least effort.	"If we only did one this month, which, who, and by when?"
28–30	RecapRead back the actions with owner, date, and what "done" means. Name who sends the notes.	"Who's sending the recap?"

Calendar invite text: Performance Engineering

Performance Engineering: weekly, 30 min
      Purpose: keep the product fast and affordable at the load that's coming. Leave with one owned fix.

      00-03  Last week's actions: done / slipped / dropped, and what each one changed
      03-10  Scorecard: top 3 user journeys vs target (slowest 5%), peak traffic, errors under load, cost per request
      10-17  Regressions: what got slower, what changed, code / capacity / dependency?
      17-24  Look ahead: launches and load changes in the next 30 days, load test status
      24-28  Decide: the one fix for this week (owner, date, done means)
      28-30  Recap: actions read back, who sends notes

      Prep: scorecard updated 24h before. Regressions bring one graph + one sentence on what changed.
      Rules: numbers vs target or it's not discussed. Deep dives go to the parking lot.

Questions to Ask

Bring three. Each has a follow-up for a weak answer, and coaching notes on what good sounds like.

Example in Practice

Scorecard block, minute 5. "Assistant answer time" is 4.8 seconds for the slowest 5% of requests. The target is 5, and last week it was 3.9.

You: "That jumped almost a second. What changed right before it?" The pod rep says a new prompt template went out Thursday. You: "Is it our code, our capacity, or the model provider?" The performance lead: "Provider time went up. The new template sends about 40% more tokens." In other words, the prompt got longer, so every answer takes longer and costs more.

Decide block: the pod tests a trimmed template, and the performance lead re-measures by Wednesday. Done means the slowest 5% is back under 4 seconds. That took six minutes, and nobody needed you to understand tokens in depth. They needed you to ask what changed.

What Actually Happens

The scorecard changes format every week, so nobody can spot trends.: Counter: fix the format once and protect it. "Same four numbers, same order, every week. Add a new one only if we drop an old one."
It turns into a 30-minute deep dive on one graph.: Counter: at minute 2 of any single topic, say "Let's park it. Who takes it after?" One deep dive per week, maximum, and only in the Regressions block.
Pods send someone who can't commit to anything.: Counter: the invite says who's needed by name when their service has a regression. If the person who came can't commit, the action becomes "get a date from [lead] by tomorrow," and it's yours to chase.
Launches surprise you anyway.: Counter: invite product once a month to the Look Ahead block, and ask them directly what's shipping in the next 30 days.
Nobody owns cost, so it grows quietly.: Counter: keep cost per request on the scorecard even if it's rough. Visible numbers get managed.

Rules for Every Recurring Meeting

Same format every time. People prepare for a format they can predict.
Hard stop at 30 minutes. End early if you're done. A meeting that respects time gets attended.
Anything over 2 minutes goes to the parking lot, with two named people to take it right after.
No action without an owner, a date, and what "done" means.
A three-line written recap within the hour. It reaches people who missed it, and it becomes the record.