What my first year in enterprise IT taught me

When you graduate from college (or finish a course), you feel like you know everything. You know the OSI model, you can write an SQL query, and you know what a router is. But then you join a real company, get access to the production environment, and suddenly you realize you actually know nothing.

Here are the biggest reality checks enterprise IT gave me in my first year.

1. Technical perfection loses to business reality

From an IT guy’s perspective, it’s always best to deploy the newest system, rewrite old code into a new framework, or implement the most reliable security feature. But in reality:

Business matters more than IT.

If repairing a “legacy” (outdated) system costs a million and saves 10 minutes of time a month, the company will rather keep the old and bad system. Enterprise IT is the art of compromise between What should be and What makes sense to pay for.

2. Process knowledge > Technology knowledge

You might be a god in PowerShell, but if you don’t have an approved Change Management Request for your script and you take down the accounting system for 10 minutes in the middle of closing the books, you are in huge trouble.

graph LR
    A[I have a great idea] --> B{Is it documented?}
    B -- No --> C[Write documentation]
    C --> B
    B -- Yes --> D{Is it approved by CAB?}
    D -- No --> E[Raise a Change Request]
    E --> D
    D -- Yes --> F[You may deploy to production during CAB window]

The reason large companies function and don’t collapse into chaos isn’t that they have the best technology. It’s because they have (relatively) bulletproof maintenance and change processes – e.g., ITIL.

3. People don’t lie, they just confuse terms

“My internet isn’t working!” is the second most common sentence on the Service Desk.

• Reality 1: The user is not connected to the VPN.
• Reality 2: Only one specific internal portal isn’t working due to an expired certificate.
• Reality 3: The user doesn’t have the network cable plugged into the docking station.

I learned that you must not believe the user’s diagnosis (“the internet isn’t working”), but you must believe the symptoms (“when I click on this icon, a wheel spins and then it crashes”). That is the huge difference. Troubleshooting starts where the layman’s description ends.