There is this unspoken disrespect baked into a lot of IT jobs.

You get hired as “help desk” or “support analyst,” and what you really end up doing all day is resetting passwords, reissuing laptops, fixing VPN, and moving tickets from “New” to “In Progress” to “Resolved.” If you listen to the way some people talk about IT, you are basically a ticket monkey with better chair height settings.

And if you stay in that mindset, it will absolutely cap you. You start to think in terms of “click here, then here,” not “what problem are we actually solving and how does this system fit into the bigger picture.”

Here is the thing nobody tells you when you are buried in the queue:

Every “dumb little” ticket is part of a big, expensive system that someone got paid a lot of money to design.

If you treat tickets like chores, you stay stuck. If you treat them like case studies, you turn into an architect without waiting for a fancy job title first.

This post is about how I forced my brain to make that switch.

I went from “why are people so bad at passwords” to “this is a broken identity pattern.”
From “VPN is being weird again” to “this remote access design is brittle.”
From “can you add me to this thing” to “this permission model is unmaintainable.”

Same tickets, different brain.

Step 1: Stop Seeing “Tasks,” Start Seeing Systems

Take a random day in IT. Your board probably looks something like:

• “VPN not connecting”
• “Teams calls dropping”
• “Need access to XYZ”
• “My laptop says it is not compliant”
• “Shared mailbox sending from wrong address”
• “New hire needs accounts set up”

On paper those look like unrelated annoyances. But almost all of them sit on top of the same handful of systems:

• Identity
• Network
• Device management
• Data and storage
• Apps and automation

Once I started forcing myself to tag tickets mentally like that, the job shifted from whack a mole to pattern recognition.

VPN not connecting
→ Network and identity. What is handling auth, what is enforcing access, what is the actual path from their laptop to the internal thing.

Shared mailbox sending from wrong address
→ Identity and mail flow design. Who owns what, how are permissions modeled, what does “send as” vs “send on behalf” really mean for audit and compliance.

Laptop says it is not compliant
→ Device management and policy design. What is the baseline, what is the enforcement mechanism, how do profiles and tokens actually work.

Same volume of chaos, but now every ticket is a front door into the architecture instead of a random fire.

Very simple habit that helped:
At the end of the day, I would look back at my tickets and ask “under which system does this live?” and write one line:

• “VPN issue – really a VNet and split tunnel design problem”
• “Company Portal error – old token and profile design problem”
• “Shared mailbox sent items – Exchange behavior and audit trail problem”

After a month or two of that, you start to see the same system names over and over. That is your real job description, not whatever HR put in the offer letter.

Step 2: Translate The User Ask Into The Real “Why”

Most tickets are badly worded symptoms of a real underlying need.

“VPN is trash again, I cannot connect”
Might actually mean
“I am on hotel Wi-Fi behind a strict firewall and your current VPN solution cannot handle that scenario.”

“My shared mailbox is broken”
Might actually mean
“For compliance reasons, we need a clean record of who said what from a finance mailbox.”

“Please create this new group and add these people”
Might actually mean
“We are trying to define a team boundary and you are the only one with a map of who belongs where.”

You only get to the real problem if you ask at least one follow up that is not technical.

• “What are you trying to get done right now that you cannot do?”
• “Who else needs to see or use this?”
• “What would ‘fixed’ look like for you?”

For example, that shared mailbox story from the other blog:

Original ask sounded like:
“Make it so emails come from receivables@ and not from my personal email.”

Real need turned out to be:
“Separate my personal identity from the company’s financial communications and keep a clean audit trail inside the shared mailbox.”

That is not a “click the right box in Outlook” problem. That is a design decision about how the organization communicates externally and how records are kept.

Once you frame it like that, running a PowerShell command to change sent items behavior suddenly looks a lot more like architecture work and a lot less like “IT guy did some magic again.”

Step 3: Map Each Ticket To A Bigger Concept

The fastest way I found to level up was to force every ticket to teach me something at the concept level.

VPN issue?
Ok, which concept is this?

• Split tunnel vs full tunnel
• DNS resolution paths
• RADIUS or SAML auth flows
• Zero trust vs “castle and moat” mentalities

Intune compliance error?
Is this really about:

• Device configuration profiles
• App protection policies
• Conditional Access rules
• Token and certificate lifetimes

ServiceNow or Jira confusion?
Probably touching:

• Change management
• Incident vs request vs problem
• How you model work so that history is not stuck in email
• How sprints and backlogs actually flow

You do not need to write a whitepaper. You just want to walk away from each ticket being able to answer one level higher than “the fix is to click here.”

Example of what I mean:

Before:
“To fix the Company Portal error, delete and reinstall the app, remove the management profile, reboot, then re-enroll.”

After:
“This error happens because the device is holding on to an old token and management profile that no longer match what Intune expects. Re-enrollment forces a new trust relationship and a fresh compliance check against current policies.”

Both are true. One of those sounds like a future architect talking.

Step 4: Document Like An Architect, Not Like A Script Robot

How you write things down changes how you think.

Most internal notes and KB articles look like this:

1. Open Settings
2. Click XYZ
3. Toggle ABC
4. Close it

That is fine for “I just need to do the thing.” It is terrible for “I want future me or someone else to understand why we do it this way.”

A better pattern I started using for docs and ticket notes:

• Description – what the user thought was wrong, in plain language
• Impact – who it affected, how bad, how often
• Root cause – what system and what behavior were actually at fault
• Resolution – the fix you applied
• Prevention or improvement – what you would change so this is easier next time

For example:

Description
Controller reported that emails sent from receivables@ and payables@ were showing as sent from his personal address, and sent copies were only landing in his personal mailbox.

Impact
Finance communications looked like personal emails, and there was no clear sent history inside the shared mailboxes for audit or handoff.

Root cause
Shared mailboxes were configured without “send as” behavior and default Exchange settings were only storing sent items in the sender’s mailbox.

Resolution
Granted proper Send As permissions, enabled MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled on the shared mailboxes via PowerShell, verified that new messages now appear in both the user’s Sent Items and the shared mailbox Sent folder.

Prevention or improvement
Update shared mailbox creation checklist to include PowerShell commands for sent item behavior, and add a short KB article showing users where to find Sent mail and how it should look.

Now the next time you or someone else touches shared mailboxes, they are not just copying commands, they understand the pattern.

Step 5: Use AI As Your Senior Architect On Call

This is where you can cheat a little and accelerate the learning curve.

After you solve a ticket, throw the story at ChatGPT and ask it to explain the bigger pattern.

Example prompt:

I just fixed this ticket in our environment:

• User: could not connect to VPN on hotel Wi-Fi, remote.example.com just timed out
• Environment: OpenVPN behind a firewall, uses SAML auth
• What fixed it: switching them to a different profile and having them connect over a different port

Explain to me:

• What likely caused this at the network and firewall level
• What design patterns could make remote access more resilient in this kind of situation
• What questions an architect would ask if this happened often

You are basically taking the single tree you just touched and asking AI to show you the whole forest.

You can do the same thing for identity, mail flow, device management, ServiceNow flows, whatever:

• “Explain this ticket like you are an Azure architect.”
• “What AWS pattern is similar to this setup?”
• “How would a CISO look at this issue?”

Is it perfect? No. But it forces your thinking up a level and gives you words and patterns you can adopt.

Step 6: Build A Simple “Architect Training Log” From Your Day Job

You do not need a fancy course to start thinking like an architect. Your ticket queue is the course.

Make a simple log somewhere that is not your ticketing tool. Notion, Obsidian, OneNote, a markdown file, whatever. For each interesting ticket, capture:

• System: identity, network, device, data, app, process
• Short title: “VPN hotel issue,” “shared mailbox sent items,” “Intune cursed token”
• Root cause in one sentence
• One thing you learned about the design

Example:

System: Identity
Title: Shared mailbox sent items not visible
Root cause: default Exchange behavior stores sent mail in sender’s mailbox only unless MessageCopyForSentAsEnabled is turned on.
Lesson: shared mailboxes need explicit design for audit trail, not just access and “from” address.

System: Device management
Title: iPhone not compliant until re-enrollment
Root cause: old management profile and token out of sync with current Intune policies.
Lesson: profiles and tokens have their own lifecycle, and “remove profile and re-enroll” is basically “reset the trust relationship.”

Do that for a few months, and now when you go to interview for something with “engineer” or “architect” in the title, you are not reaching for buzzwords, you are literally pulling real stories about systems you have lived in.

Closing This Out

None of this changes what shows up in your queue tomorrow. You will still be dealing with people who forgot their password, laptops that refuse to cooperate, and apps that throw incomprehensible errors at the worst time.

What changes is what you are secretly working on while you do all that.

You can be the person who closes tickets. Or you can be the person who uses every ticket as a case study in how your company’s systems really work, and how they could be better.

One of those paths tops out at “senior support.” The other one quietly builds you into the person people go to when the question is not “how do I click this” but “how should we design this.”

Same chair, same keyboard, same queue.

Different brain.

‍