Short answer
Performance engineering assesses measurement-led work on speed, capacity, and resource use against explicit needs.
About Performance engineering
The ability to measure and improve system speed, capacity, and resource use against defined workloads and performance needs.
Use this competency for
- Roles that diagnose or change latency, throughput, capacity, or resource consumption.
- Functions where performance limits affect user outcomes or operating cost.
Do not use this competency for
- Work with no responsibility for measuring or changing technical performance.
Important distinctions
Reliability engineering
Performance engineering targets speed, capacity, and resource use. Reliability engineering targets availability, degradation, and recovery.
Code quality
Code quality assesses maintainability. Performance engineering may accept added complexity only when measured benefit and constraints justify it.
Expectations by level
IC1
Individual contributor 1
Measures a bounded performance issue with guidance, uses an established method, and verifies that a change improves the defined signal.
Observable behaviors
- Records a baseline under a repeatable workload.
- Uses a profiler or metric to locate expensive work.
- Compares the same signal before and after the change.
Examples
- Measured a slow endpoint with the team load fixture before changing a query.
- Removed repeated computation and recorded the latency change under the same input.
IC2
Individual contributor 2
Independently improves performance in a team-owned area, defining representative workloads and balancing speed, capacity, cost, and complexity.
Observable behaviors
- Defines a target and workload before optimizing.
- Separates bottlenecks by component and resource.
- Checks for regressions in correctness and resource use.
Examples
- Compared cache options using hit rate, memory use, and response time under expected traffic.
- Changed batch sizing after measuring throughput and worker memory across several loads.
IC3
Individual contributor 3
Sets performance direction across systems, frames unclear capacity constraints, and enables teams to prevent and diagnose regressions.
Observable behaviors
- Defines shared performance budgets tied to system needs.
- Plans capacity using measured demand and limiting resources.
- Introduces repeatable benchmarks for cross-team changes.
Examples
- Established latency budgets at service boundaries for a workflow spanning three teams.
- Created a capacity test that exposed a shared queue limit before a planned traffic increase.