Portal | Level: L0: Entry | Topics: Corporate IT Fluency, Career Engineering | Domain: DevOps & Tooling
Corporate IT Fluency for Engineers - Primer¶
Why This Matters¶
You are a solid engineer. You can debug a kernel panic, write Terraform modules, and troubleshoot a flapping BGP peer. Then you join a corporate IT shop and someone says: "We need to rightsize the CMDB before the next CAB review, and InfoSec wants a RACI for the SOC2 remediation items on the risk register."
You understood none of that. Not because you are bad at your job — because nobody taught you the language.
Corporate IT has its own dialect. It evolved from ITIL, project management, procurement, compliance, and decades of enterprise culture. If you do not speak it, you will misread emails, zone out in meetings, misinterpret priorities, and look junior even when your technical skills are senior-level.
This is not about becoming a manager or learning to love meetings. It is about removing a communication barrier so your technical work gets the visibility and context it deserves.
Name origin: ITIL stands for Information Technology Infrastructure Library. It was created by the UK government's Central Computer and Telecommunications Agency (CCTA) in the 1980s to standardize IT management across government departments. The original ITIL was a collection of 31 books. ITIL 4 (2019) condensed it to a single framework. Despite its bureaucratic origins, ITIL concepts (incident, problem, change, service catalog) have become the universal language of enterprise IT — even in organizations that do not formally follow ITIL.
ITSM: The Process Language¶
ITSM (IT Service Management) is the framework most large IT organizations use to manage work. ITIL is the most common flavor. You do not need a certification — you need to know what people mean when they use these words.
Incident vs Problem vs Change¶
These three words have precise meanings in ITSM. Using them interchangeably marks you as someone who has never worked in a structured IT org.
┌─────────────────────────────────────────────────────────────┐
│ ITSM CORE CONCEPTS │
│ │
│ INCIDENT │
│ ───────── │
│ "Something is broken RIGHT NOW." │
│ • Unplanned interruption to a service │
│ • Goal: restore service ASAP │
│ • Example: "The payment gateway is returning 500s" │
│ • Metric: MTTR (Mean Time To Restore) │
│ │
│ PROBLEM │
│ ─────── │
│ "WHY does it keep breaking?" │
│ • Root cause analysis of recurring incidents │
│ • Goal: eliminate the root cause │
│ • Example: "Payment failures spike every month-end due │
│ to connection pool exhaustion under load" │
│ • Output: Known Error record + permanent fix plan │
│ │
│ CHANGE │
│ ────── │
│ "We want to modify a production system." │
│ • Planned modification to the environment │
│ • Goal: minimize risk of new incidents │
│ • Example: "Increase connection pool from 50 to 200" │
│ • Requires: Change Request → CAB review → approval │
│ │
│ FLOW: Incident → Problem → Change → (hopefully) fixed │
└─────────────────────────────────────────────────────────────┘
The Change Advisory Board (CAB)¶
The CAB is a recurring meeting (usually weekly) where proposed changes to production systems are reviewed and approved. If you have never encountered one, here is what to expect:
- Who attends: Change manager (chair), representatives from each team with pending changes, sometimes security and compliance
- What you present: Your Change Request (CR) — what you are changing, why, rollback plan, risk assessment, affected systems, maintenance window
- What happens: The board approves, rejects, or defers your change
- Standard changes are pre-approved templates (e.g., "restart a service," "add a DNS record") that skip the CAB
- Emergency changes bypass normal process but require post-implementation review
Why this matters to you: If your team deploys via CI/CD and you join a company with CAB, your deploy velocity just dropped from "merge to main" to "submit CR on Tuesday, present at CAB on Thursday, deploy during Saturday maintenance window." Understanding this is not optional.
CMDB: The Configuration Management Database¶
The CMDB is the organization's inventory of everything in IT — servers, applications, network devices, cloud resources, dependencies between them. In theory, it is the single source of truth for "what do we have and how is it connected."
In practice:
- Good CMDBs are automated (discovery tools populate them) and actively maintained. They answer questions like "which services depend on this database?" and "who owns this server?"
- Bad CMDBs are manually maintained spreadsheets that were accurate two years ago. Nobody trusts them but everyone is required to reference them.
- Your job: Know that it exists, know how to look things up in it, and update your entries when you make changes. When someone says "check the CMDB," they mean "look up the configuration item and its relationships."
Service Levels: SLA vs OLA vs UC¶
| Term | Full Name | Between | Example |
|---|---|---|---|
| SLA | Service Level Agreement | IT and the customer/business | "99.9% uptime for the payment service" |
| OLA | Operational Level Agreement | Internal IT teams | "Network team responds to P1 tickets within 15 minutes" |
| UC | Underpinning Contract | IT and external vendor | "Cloud provider guarantees 99.99% availability" |
The SLA is the promise to the business. OLAs and UCs are the internal and external agreements that make the SLA achievable. When an SLA is breached, the postmortem traces back to which OLA or UC failed.
Governance and Compliance¶
The Acronym Wall¶
| Acronym | Full Name | What It Means For You |
|---|---|---|
| SOC2 | Service Organization Control 2 | Audit framework for cloud/SaaS companies. You will be asked to prove access controls, logging, and change management are in place. |
| ISO 27001 | Information Security Management | International security standard. Requires documented policies, risk assessments, and regular audits. |
| PCI-DSS | Payment Card Industry Data Security Standard | If you touch credit card data, you follow these rules or the company gets fined. |
| HIPAA | Health Insurance Portability and Accountability Act | Healthcare data protection. Strict access controls, encryption, audit logging. |
| GDPR | General Data Protection Regulation | EU data privacy law. Affects data retention, right to deletion, data residency. |
| FedRAMP | Federal Risk and Authorization Management Program | US government cloud security. If you sell to the government, you need this. |
You do not need to memorize frameworks. You need to know that when someone says "we have a SOC2 finding," they mean an auditor found a gap in controls that needs to be fixed, usually with a deadline and a paper trail.
Remember: The compliance acronym mnemonic: SHIP-GF — SOC2 (SaaS/cloud), HIPAA (healthcare), ISO 27001 (international), PCI-DSS (payments), GDPR (EU privacy), FedRAMP (US gov). Each is triggered by what data you handle or who your customers are, not by company size. A 10-person startup handling credit cards needs PCI-DSS just as much as a Fortune 500 bank.
RACI Matrix¶
RACI answers "who does what" for a given process or project:
| Letter | Role | Meaning |
|---|---|---|
| R | Responsible | Does the work |
| A | Accountable | Owns the outcome (only one person) |
| C | Consulted | Provides input before the work |
| I | Informed | Told about the outcome after |
Example: For a database migration:
| Task | DBA | Dev Lead | Security | VP Eng |
|---|---|---|---|---|
| Write migration script | R | C | I | I |
| Review and approve | C | A | C | I |
| Execute in production | R | I | I | I |
| Validate post-migration | R | R | C | I |
When someone says "let's build a RACI for this," they want clarity on ownership. It is a useful tool when multiple teams are involved and nobody knows who is supposed to do what.
Risk Register¶
A risk register is a living document that tracks known risks, their likelihood, impact, and mitigation plans. When InfoSec says "add this to the risk register," they mean:
- Document the risk (what could go wrong)
- Assess likelihood (low/medium/high) and impact (low/medium/high)
- Assign an owner
- Define a mitigation plan and timeline
- Track it until resolved or accepted
Risk acceptance is a real thing — sometimes the business decides a risk is acceptable given the cost of mitigation. This gets documented and signed off, usually by someone senior.
Budget and Procurement¶
CapEx vs OpEx¶
| CapEx (Capital Expenditure) | OpEx (Operational Expenditure) | |
|---|---|---|
| What | Buy an asset | Pay for ongoing use |
| Example | Buy 50 servers | Pay for AWS EC2 monthly |
| Accounting | Depreciated over years | Expensed in current period |
| Budget cycle | Requires capital approval (annual) | Comes from operating budget |
| Flexibility | Locked in once purchased | Scale up/down monthly |
Why you care: The cloud migration conversation is often a CapEx-to-OpEx shift. Finance people have strong opinions about this. When someone says "we need to capitalize this project," they mean they want to spread the cost over multiple years on the balance sheet rather than take the hit in one quarter.
Interview tip: If asked "why are companies moving to the cloud?" in an interview, the CapEx-to-OpEx shift is one of the strongest answers. Cloud converts large upfront hardware purchases (CapEx, requires capital budget approval, 3-5 year depreciation) into monthly utility bills (OpEx, comes from operating budget, pay-as-you-go). This changes the financial risk profile: you trade the risk of overprovisioning hardware for the flexibility of scaling spend with demand.
Procurement Vocabulary¶
| Term | What It Means |
|---|---|
| RFI (Request for Information) | "Tell us what you offer" — early-stage vendor research |
| RFP (Request for Proposal) | "Give us a formal proposal with pricing" — competitive bidding |
| RFQ (Request for Quote) | "We know what we want, how much?" — price comparison |
| SOW (Statement of Work) | The contract scope — what the vendor will deliver, by when, for how much |
| MSA (Master Service Agreement) | Umbrella legal agreement covering all work with a vendor |
| PO (Purchase Order) | The actual order document — finance needs this to pay |
| TCO (Total Cost of Ownership) | Full cost including purchase, licensing, support, labor, power, cooling, decommission |
| ROI (Return on Investment) | "If we spend X, we save/earn Y" — how you justify spend to leadership |
"Run vs Grow" Budgets¶
Many IT orgs split their budget into:
- Run the business: Keeping the lights on — maintenance, licensing renewals, support contracts, patching
- Grow the business: New capabilities — migrations, new platforms, automation projects
When budgets get cut, "grow" gets cut first. Understanding which bucket your project is in tells you how vulnerable it is.
Meeting and Process Culture¶
Meeting Types You Will Encounter¶
| Meeting | Purpose | Your Role |
|---|---|---|
| Standup | Quick status sync | "What I did, what I'm doing, blockers" |
| CAB | Change approval | Present your change requests |
| War room / Bridge call | Active incident response | Troubleshoot, provide updates |
| Steering committee | Project governance | Usually invited for status updates |
| Retrospective / Retro | Process improvement | Share what went well/badly |
| Blameless postmortem | Incident review | Focus on systems, not people |
| Skip-level | Manager's manager checks in | Be honest about blockers |
| Architecture review | Design validation | Present or review technical designs |
Process Jargon Decoder¶
| They Say | They Mean |
|---|---|
| "Let's take that offline" | "Stop talking about this now; we'll discuss privately or never" |
| "We need alignment" | "People disagree and nobody has decided" |
| "Let's circle back" | "I don't want to deal with this right now" |
| "What's the ask?" | "What specifically do you need me to do?" |
| "Let's parking-lot that" | "Noted but not discussing now — it goes on a list we may never revisit" |
| "Action item" | A task assigned to a specific person with a deadline |
| "Tiger team" | A small, focused group assembled to solve a specific problem fast |
| "Swim lane" | Your team's or function's area of responsibility |
| "RAID log" | Risks, Assumptions, Issues, Dependencies — a project tracking tool |
| "Blast radius" | How many things break if this goes wrong |
| "Single-threaded owner" | One person with full ownership and authority over a decision |
| "Hard stop" | "I must leave this meeting at exactly this time" |
| "Boil the ocean" | Trying to do too much at once — usually said to scope something down |
| "Net new" | Brand new, not an iteration on something existing |
| "North star" | The long-term vision or guiding metric |
| "Table stakes" | The minimum expected — not a differentiator |
Organizational Structure¶
Roles and Titles (What Companies Actually Mean)¶
The same job has different titles depending on the company. Here is a rough mapping:
| Title at Company A | Title at Company B | What They Actually Do |
|---|---|---|
| SysAdmin | Infrastructure Engineer | Manages servers, OS, patching |
| DevOps Engineer | Platform Engineer | Builds CI/CD, IaC, developer tools |
| SRE | Production Engineer | Reliability, SLOs, incident response |
| NOC Technician | Operations Analyst | Monitors dashboards, triages alerts |
| IT Manager | Engineering Manager | People management + technical direction |
| Director of IT | Head of Infrastructure | Strategy, budget, team building |
Leveling¶
Most companies use some form of level system:
| Level | Common Titles | Expectations |
|---|---|---|
| IC1-IC2 | Junior/Associate | Executes tasks with guidance |
| IC3 | Mid-level / Engineer | Works independently on well-defined problems |
| IC4 | Senior | Designs solutions, mentors others, handles ambiguity |
| IC5 | Staff / Principal | Cross-team technical leadership, architectural decisions |
| IC6+ | Distinguished / Fellow | Company-wide technical direction (rare) |
IC = Individual Contributor (not a people manager). When someone says "I'm a senior IC," they mean they are technically senior but do not manage people.
Dotted line vs solid line reporting: Solid line = your actual manager. Dotted line = someone you also report to functionally but who does not do your performance reviews.
Putting It Together: A Day in Corporate IT¶
Here is what a typical interaction looks like when you speak this language:
Before: "Hey, the database keeps crashing. I fixed it three times this week. Can someone figure out why?"
After: "We've had three P2 incidents on the payment database this week (INC-4421, 4428, 4435). I'm opening a Problem record to investigate root cause. Initial theory is connection pool exhaustion under month-end load. If confirmed, I'll submit a Standard Change to increase the pool size, or a Normal Change if we need to resize the instance. I'll update the CMDB and notify the service owner."
Same engineer. Same technical skill. The second version gets taken seriously in a corporate environment because it shows you understand the process, the terminology, and the relationships between systems.
Key Takeaways¶
- Incident, Problem, and Change are not synonyms. Use them correctly.
- The CAB exists to manage risk, not to annoy you. Learn to work with it.
- Compliance acronyms (SOC2, PCI, etc.) are constraints, not bureaucracy. They have legal and financial teeth.
- Budget conversations (CapEx/OpEx, TCO, ROI) determine what gets funded. If you can speak this language, your projects are more likely to get approved.
- Meeting jargon is a social protocol. Decoding it prevents you from wasting time or missing signals.
- Titles are unreliable. Focus on what the role actually does, not what it is called.
Wiki Navigation¶
Related Content¶
- Career Engineering for Ops People (Topic Pack, L0) — Career Engineering
- Corporate It Fluency Flashcards (CLI) (flashcard_deck, L1) — Corporate IT Fluency
- Grokdevops Training Flashcards (CLI) (flashcard_deck, L1) — Career Engineering