Change failure rate
The percentage of deployments that cause a failure in production, including rollbacks, hotfixes, or outages. This is one of the four DORA metrics. Typically, top performers sit below 15%.
Cognitive load
The mental effort an engineer spends just to do their job, understanding systems, tools, processes, and context. High cognitive load slows everyone down. Reducing it is the core job of platform engineering.
Deployment frequency
How often a team ships to production. One of the four DORA metrics. Typically, elite performers deploy multiple times per day.
Developer experience (DevEx)
The sum of how engineers feel building software at a company, including tooling, friction, feedback loops, ownership clarity, and more. Good DevEx makes engineers faster and happier whereas bad DevEx burns them out.
Developer productivity
The output engineers produce relative to the effort they put in. Measured through frameworks like DORA and SPACE, not lines of code.
Developer self-service
Giving engineers the ability to provision, deploy, configure, and operate without filing a ticket. Essentially, the opposite of having a centralized ops gatekeeper.
DORA metrics
Four metrics for software delivery performance: deployment frequency, lead time for changes, change failure rate, and mean time to recovery focused on helping teams improve. These metrics are the de facto standard for measuring engineering throughput and stability.
Engineering intelligence
The data and dashboards leaders use to understand what's happening across engineering, including productivity, reliability, adoption, spend, and more. The EngOps equivalent of a CFO's financial reporting.
Engineering operations (EngOps)
The discipline of running engineering organizations efficiently, measuring maturity, reducing friction, standardizing practices, and making developers productive. This sits alongside RevOps and FinOps as a top-level operational function.
Golden path
The recommended way to do something at your company, whether spinning up a service, shipping to production, or adding a feature flag. Golden paths ensure standardization, reduce decision fatigue, and make the right way the easy way for engineers.
Incident management
The process of detecting, responding to, communicating about, and learning from production incidents. Strong incident management is a leading indicator of strong operational maturity.
Internal developer portal (IDP)
The unified set of tools, services, and abstractions engineers use to build, run, and govern software at your company. Sometimes built in-house, increasingly bought.
Lead time for changes
The time between a code commit and that code running in production. One of the four DORA metrics. Typically, shorter lead times correlate with better outcomes across the board.
Migration and modernization
The work of moving systems off old infrastructure, frameworks, or services onto new ones. The most universally hated and universally necessary work in engineering.
MTTR (mean time to recovery)
The average time to restore service after a production incident. One of the four DORA metrics. Typically lower MTTR translates to less customer impact.
On-call
The rotation of engineers responsible for responding to alerts and incidents outside business hours. The quality of the on-call experience is a strong proxy for operational health.
Operational maturity
How rigorously and consistently an engineering organization runs its software, including ownership, reliability, security, observability, and on-call. This is the throughline that connects every EngOps practice.
Ownership
The clear assignment of services, systems, and outcomes to specific people or teams. The single most important principle in strong engineering operations.
Platform engineering
The practice of building internal tools and platforms that make application engineers faster. This has emerged as the dominant organizational structure for solving EngOps problems.
Postmortem
The written analysis of an incident, including what happened, why, what to do about it. Blameless postmortems are the standard; they prioritize learning over blame.
Production readiness
The standards a service must meet before it can serve real traffic (e.g. observability wired up, on-call assigned, runbooks written, dependencies documented, security reviewed). Production readiness reviews catch problems before customers do.
Reliability
The degree to which systems behave as expected under real conditions. Measured through SLOs, error budgets, and incident metrics.
Runbook
A step-by-step guide for handling a known operational scenario, including common alerts, failure modes, recovery procedures. Good runbooks turn 3am pages into ten-minute fixes and reduce MTTR.
Scorecards
A way to define standards (security, reliability, production readiness, AI readiness) and measure how every service stacks up. The mechanism that turns "we should do X" into "is everyone doing X?"
Service catalog
A single source of truth for every service, system, and asset in your engineering org that includes what it is, who owns it, what it depends on, where it lives.
SLI, SLO, SLA
Service level indicator, objective, agreement. SLIs are what you measure (request latency). SLOs are the targets you set (99.9% under 200ms). SLAs are the contractual commitments to customers tied to those targets.
SPACE framework
A model for measuring developer productivity across five dimensions: satisfaction, performance, activity, communication, and efficiency. Created as a more holistic alternative to single-metric productivity measurement.
Tech debt
Shortcuts in code or architecture taken for speed, that accrue interest over time. Paid back in slowness, fragility, and engineer frustration.
Toil
Repetitive, manual, automatable work that scales with the size of the system rather than the value it produces. The SRE rule: if you can automate it, you should.
Workflows
Automated, self-service processes that handle common engineering tasks, including scaffolding a new service, requesting access, running a migration. The things engineers used to file tickets for, turned into one-click actions.
