_private/qwestly-private-docs/HR/Team-Meetings/2026-08-18-team-process-meeting-agenda.md

Team Process Meeting — Agenda

Date: 2026-08-18 Prepared by: Dominick Audience: Full team

From the notes — operational threads (fixable as process, not people):

  • Vella tried to hand off the LinkedIn writer update for testing before running her own evals. Adam had to push her to build eval cases (rich/medium/empty profiles) first — she then found her own bugs. → no standard "done means tested" bar exists.
  • Work getting "cammed" and discovered late/incomplete near deadlines in general.
  • Adam explicitly named: "architectural decisions are still weak without Dominick's review layer present" → no lightweight design-review checkpoint when you're not in the loop.

Individual/behavioral (Adam's notes, save for 1:1s, not this meeting):

  • David acting on things he was explicitly told not to do, distracted in meetings.
  • David cramming work right before standups (improved once called out directly).

Purpose

Address operational gaps surfaced this week (task estimation, testing before handoff, priority communication) as a team-wide process conversation. Individual conduct issues are handled separately in 1:1s and are intentionally out of scope for this meeting.

Opening (say this or close to it)

"I want to talk about how we work as a team — not about anyone's performance specifically. If something's an individual conduct issue, I'll handle that 1:1. What I want to figure out here is whether our process is setting people up to succeed."

Context to share (patterns, not incidents — no names, no specific tasks)

Don't say "Vela tried to hand off untested code." Say: "I've noticed a pattern: something gets marked done, then bugs show up right after, and we're not always sure whether it was tested before handoff." Same for timing: "I've noticed some tasks land right at the deadline with no buffer — I want to understand why, because it might be how work gets planned, not how it gets executed."

  • Work sometimes gets marked "done" and then bugs surface right after — unclear whether testing happened before handoff.
  • Some tasks land right at the deadline with no buffer, and we don't always find out something's incomplete until late.
  • Architectural/design decisions sometimes go sideways without an extra pair of eyes catching it earlier.

Diagnostic questions (ask in this order — root cause before solutions)

  1. When you call something "done," what do you personally check before saying that?
  2. Do we have a shared definition of done, or does it vary person to person?
  3. How do you find out what the top priority is on a given day? Does that ever shift on you mid-task or stay unclear?
  4. When you're estimating a task, what usually throws the estimate off — surprises in scope, competing priorities, something else?
  5. What would have caught the last bug/rework earlier — a test, a second pair of eyes, a checkpoint?

Let the team answer before you propose fixes — if they name the same gaps you already suspect (testing harness, priority clarity), the fix has buy-in instead of being handed down.

Target outcomes — converge on 2-3 concrete mechanisms

  • Definition of Done checklist — tests/evals run, not just "code written," before something is marked ready for review.
  • Lightweight design-review checkpoint — for architectural decisions, so review doesn't only happen when Dominick personally catches it.
  • Visible priority source of truth — a pinned doc or daily line so "priorities weren't communicated" stops being a valid gap.

Closing

"These are process changes we're making as a team. If I need to talk to someone individually about how they're working, that's separate and I'll do it separately."

This protects the team meeting's usefulness for future occurrences too — people learn this forum is safe for systems talk.

Follow-ups (not for this meeting)

  • David: cramming near deadlines, distraction in meetings, acting on things explicitly told not to do — address 1:1.
  • Vella: slow turnaround on LinkedIn writer update, attempted handoff before running own evals — address 1:1, reinforce the "own evals before handoff" expectation that already produced good results this week.