← All roles

Brag document template for DevOps engineers

DevOps engineers are measured on outages that never happened and on how much faster everyone else ships. Both are invisible unless you write them down.

What this role is judged on

  • Service availability and incident reduction
  • Deployment frequency and lead time for changes
  • Recovery time when something does break
  • Infrastructure cost efficiency
  • Toil removed from other engineers' daily work

What this role is measured on

The defining problem of this discipline is that success looks like nothing happening. A quarter spent making a fragile system boring produces no launch, no demo, and no story, and it is frequently the most valuable quarter anyone on the team had. Every part of preparing for a review in this role is about converting absence into evidence.

Availability is the headline, but the interesting numbers are the derivative ones. How often you deploy, how long a change takes to reach production, how often a deployment causes a problem, and how quickly you recover when it does. Those four describe the health of a delivery system far better than an uptime percentage does.

Recovery time deserves its own attention because it is the number you can most reliably improve. Preventing every incident is impossible; making the next one twenty minutes instead of three hours is achievable and enormously valuable.

Cost is a first-class result. Infrastructure spend is one of the larger controllable line items in most software organizations, and reductions attributable to a specific change are unambiguous evidence.

Toil removal is the multiplier. Every manual step you automated is time returned to every engineer who used to perform it, forever.

Wins that read well for this role

  • "Took deployment lead time from to and raised deploy frequency to , without raising the change failure rate."
  • "Cut mean recovery time on from to by adding ."
  • "Prevented a recurrence class: after , shipped so that failure mode can no longer reach production."
  • "Reduced infrastructure spend by on with no change to capacity headroom."
  • "Automated , returning roughly per week across ."

Common undersell

The characteristic undersell here is prevention, and it is severe. Someone whose systems did not go down all year can end up writing a thinner self-review than someone who heroically fixed three outages they also caused. The counter is to name the counterfactual explicitly: this failure mode used to happen at this rate, here is what I built, here is the rate now.

The second undersell is on-call load. Reducing pager volume for a team is a direct improvement to the working lives of your colleagues and to the organization's retention, and it goes unmentioned because it is not a feature.

The third is the migration nobody noticed. Moving a critical system with zero customer impact is the definition of the job done well, and it reads as nothing unless you say what the alternative looked like.

Sources

Keep the record as you go

It takes about five minutes.

Build yours in the tool