Tech Acronyms Cheatsheet

Every field in tech has its own alphabet soup. Sit in a planning meeting, an incident review and an AI roadmap session in the same week and you will hear DORA, SLO, MTTR, SBOM, RAG, MCP and LLM-as-a-judge, often without anyone stopping to define them.

Acronyms are not just jargon. Most of them are compressed ideas: a metric, a practice or a trade-off that someone found important enough to name. Knowing what they stand for is the easy part. Knowing why they exist is what makes them useful.

This post is a practical glossary. Each entry is short: what it means, which keywords or components it bundles, and why you should care. It is grouped by area, but the areas overlap on purpose - modern teams build, ship, run, secure and support the same systems.

Items marked with a ⚠️ have more than one common meaning. Context decides (see "Same letters, different meaning" near the end).

1. Delivery performance and developer productivity

How fast and how safely a team turns ideas into running software.

DORA in practice

The DORA metrics are intentionally simple to compute. With a log of deployments you already have most of what you need:

from datetime import datetime, timedelta
from statistics import median

deploys = [
    # (commit_time, deploy_time, caused_failure, recovered_at)
    (datetime(2026, 10, 1, 9), datetime(2026, 10, 1, 15), False, None),
    (datetime(2026, 10, 2, 10), datetime(2026, 10, 3, 11), True, datetime(2026, 10, 3, 12)),
    (datetime(2026, 10, 6, 8), datetime(2026, 10, 6, 9), False, None),
    (datetime(2026, 10, 7, 13), datetime(2026, 10, 8, 10), False, None),
]

days = 30
deployment_frequency = len(deploys) / days
lead_time = median(d - c for c, d, _, _ in deploys)
failures = [(d, r) for _, d, failed, r in deploys if failed]
change_failure_rate = len(failures) / len(deploys)
recovery_time = median(r - d for d, r in failures) if failures else timedelta(0)

print(f"Deploys/day:          {deployment_frequency:.2f}")
print(f"Median lead time:     {lead_time}")
print(f"Change failure rate:  {change_failure_rate:.0%}")
print(f"Median recovery time: {recovery_time}")

The insight is in the combination: high deployment frequency with a low change failure rate shows that speed and stability are not a trade-off. DORA now counts five metrics: the original four keys (with Failed Deployment Recovery Time replacing Mean Time To Restore) plus rework rate, which sits with change failure rate in the instability group. The example above omits rework rate because it needs to know why each deployment happened (planned work or reaction to an incident), which a plain deploy log does not carry.

2. Software engineering practices and design

The principles and habits behind code that is easy to change.

3. APIs, architecture and the web

4. Operations, reliability and SRE

How you know a system is healthy, and what happens when it is not.

Error budgets: why SLOs are useful

An SLO is not just a target; it gives you a budget for failure. Spend it on shipping features and experiments; when it runs out, prioritize reliability. A related alert style is the burn rate: how fast you are consuming the budget compared with an even spend over the window.

def error_budget_minutes(slo: float, days: int = 30) -> float:
    """Allowed downtime (in minutes) for an availability SLO over a window."""
    return (1 - slo) * days * 24 * 60


for slo in (0.99, 0.999, 0.9999):
    print(f"{slo:.2%} over 30 days -> {error_budget_minutes(slo):6.1f} minutes of downtime")

# 99.00% over 30 days ->  432.0 minutes of downtime
# 99.90% over 30 days ->   43.2 minutes of downtime
# 99.99% over 30 days ->    4.3 minutes of downtime

Each extra "nine" cuts the budget by 10x, and usually costs much more than 10x to achieve. That is the real insight: choose the reliability your users need, not the maximum possible.

5. DevOps, platforms and cloud cost

6. Security, privacy and supply chain

7. MLOps and data

Getting models from notebooks to production, and keeping them good.

8. AI and LLM systems

The newest and fastest-growing part of the alphabet.

LLM-as-a-judge in practice

Traditional metrics (exact match, BLEU, ROUGE) struggle with open-ended answers. LLM-as-a-judge uses a strong model with a clear rubric to score outputs:

JUDGE_PROMPT = """You are grading an answer to a customer support question.

Question: {question}
Reference answer: {reference}
Candidate answer: {candidate}

Score the candidate from 1 to 5 for factual correctness against the reference.
Reply with JSON only: {{"score": <1-5>, "reason": "<one sentence>"}}"""


def judge(call_llm, question: str, reference: str, candidate: str) -> dict:
    """call_llm(prompt) -> str is any client for your model provider."""
    import json

    raw = call_llm(JUDGE_PROMPT.format(question=question, reference=reference, candidate=candidate))
    return json.loads(raw)

Why it matters, and what to watch for:

• Scale: you can evaluate thousands of outputs on every prompt or model change, like a test suite for AI behavior.
• Calibrate it: compare the judge's scores with human labels on a sample before trusting it.
• Known biases: judges can prefer longer answers (verbosity bias), the first option shown (position bias), or text written by their own model family (self-preference).
• Keep rubrics narrow: one criterion per judgment ("correct?", "follows policy?") is far more reliable than "is this good?".
• Expect messy output: real model replies sometimes wrap the JSON in extra text, so validate and retry rather than calling json.loads blindly.

9. Support and IT service management

Where the customer meets the system.

Support metrics close the loop with engineering: ticket spikes are often the earliest signal of an incident (low MTTD), and recurring ticket categories point to the bugs and UX problems worth fixing first.

Same letters, different meaning

Some acronyms collide. When you hear one of these, check the context:

If you work in fintech in Europe, you will likely deal with both DORAs: one measures how well you ship, the other regulates how well you survive when things go wrong. They point in the same direction.

Why this matters

Acronyms are shortcuts, and shortcuts are only useful if everyone takes the same road. A few practical takeaways:

• Define them once, in writing. A glossary in your team docs or onboarding saves hours of quiet confusion.
• Prefer the concept over the label. "We recover from bad deploys in under an hour" is clearer than "our MTTR is good".
• Metrics come in pairs. Speed with stability (DF with CFR), cost with quality (AHT with FCR), automation with oversight (LLM-as-a-judge with human calibration). Optimizing one alone usually breaks the other.
• The alphabet keeps growing. MCP, A2A and LLMOps did not exist a few years ago. The useful habit is not memorizing every acronym, but asking: what problem does this name solve, and do we have that problem?

Final Thoughts

Behind almost every acronym in this list there is a lesson someone learned the hard way: deployments that failed, outages that lasted too long, vulnerabilities nobody could trace, models that silently drifted, customers who never came back.

Learning the letters gets you into the conversation. Understanding the lessons behind them is what lets you build, run and support software well.