Scaling performance at Slack's scale
summary
Slack scales performance by building a cross-team performance channel where engineers post mini digestible fixes, use tracing, flame graphs and metrics to find hotspots, and ship many small changes that compound into large wins; a recognition system and SLO streaks motivate widespread participation rather than a single performance team. The concrete claim is that incremental, observable fixes by many engineers — not rewrites or a special team — measurably reduce latency at Slack’s scale.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:26Slacks scale
- 2:11Why am I here
- 2:42New hires dilemma
- 4:23Bugs
- 5:58Killing yourself
- 6:22The challenge
- 7:44The options
- 8:09Performance monitoring
- 8:48Dedicated performance team
- 9:44Rewriting
- 10:39What did we do
- 11:10How did we get here
- 12:36Sharing of ideas
- 13:39Knowledge sharing
- 14:44Recognition
- 15:37Streaks
- 16:52Continuous Performance Improvement
- 18:08Legacy Code
- 19:07Leadership
- 20:00Compounding
related talks
27mSeveral components are rendering
32mBetter Integration Tests for Performance Monitoring
37mUsing SLOs for Continuous Performance Optimizations of Your K8s Workloads
35mThe elements of scaling
01h 00mPerformance In Modern Times: An Evolutionary Journey
05mScale Fail
38mShift-Left Performance Engineering for RAG and LLM Platforms
39mIntro + Deep Dive: SIG Scalability