You walked into your first IT job thinking the hard part was technical. Learn Active Directory, master the ticketing system, memorize the network topology. Nobody mentioned the other stuff. The stuff that actually determines whether you survive your first year or spend it confused about why things work the way they do.

Every IT department has a hidden operating system running underneath the official one. It’s not documented anywhere. It’s not in the employee handbook. And violating it will get you in trouble faster than breaking production.

Here’s what nobody tells you.

The Change Freeze Is Sacred (Even When It’s Not Official)

You’ll figure out pretty fast that there are “official” change freezes and then there are the real ones. The official freeze might be the two weeks around a major product launch or end-of-quarter. But the unwritten freeze? That’s any time a senior leader has a big presentation, any Friday afternoon, the day before anyone important goes on vacation, and basically all of December.

Push a change during one of these invisible windows and you’ll learn the hard way. Nothing in the runbook says you can’t deploy on a Thursday before the CEO’s board meeting. But do it, and when something breaks, you’ll discover exactly how fast “blameless culture” develops exceptions.

How to Navigate This

Ask your team lead a direct question during your first week: “When do we actually avoid making changes around here?” Most will give you a real answer if you ask directly. The ones who say “anytime is fine” are either new themselves or setting you up for a learning experience.

Watch what senior engineers do. If the person with 10 years at the company never deploys on Fridays, that’s your answer. It doesn’t matter what the process doc says.

The Person Who Owns the System Owns the Decision

Org charts show reporting lines. They don’t show power. In IT departments, the real authority often belongs to whoever built or maintains the critical system, regardless of title.

The senior sysadmin who set up the virtualization environment five years ago? She has more say over infrastructure decisions than the manager who joined last quarter. The network engineer who built the WAN architecture? Good luck pushing a change he disagrees with, even if your manager approved it.

This isn’t dysfunction. It’s how technical organizations actually work. The person closest to the system understands it best and carries the risk if it breaks. Their opinion carries weight because it should.

What This Means for You

When you want to change something, figure out who the real owner is before you start. Not the name on the CMDB record. The person who will get paged at 2 AM if your change goes sideways. Get their buy-in first. This is more important than getting your manager’s approval in many cases.

If you manage up effectively, you’ll learn to identify these informal power structures quickly. And if you’re trying to grow beyond your current role, understanding who actually makes decisions is half the battle.

Nobody Cares About Your Solution Until They Trust Your Diagnosis

New IT hires love jumping to fixes. You see a problem, you know the answer, you implement it. Done. Efficient. Right?

Wrong, according to everyone who’s been there longer than you.

In established IT teams, proposing a solution before thoroughly diagnosing the problem signals inexperience. It’s not that your fix is wrong (it might be perfect). It’s that you skipped the part where you demonstrate you understand the full picture. What else does this system touch? What broke last time someone made a similar change? What are the downstream effects?

The senior engineer who spends 30 minutes reading logs before touching anything isn’t slow. She’s demonstrating the troubleshooting methodology that comes from years of getting burned by “obvious” fixes that caused bigger problems.

The Real Rule

Show your work before showing your answer. Even in a P1 outage. Especially in a P1 outage. “I noticed the DNS cache is stale and I’m seeing timeout errors on these three services. I want to flush the cache on the primary resolver. Any concerns before I do?” That lands differently than “I fixed it” followed by silence, then “wait, something else broke.”

The Ticket Is the Truth (And Off-Ticket Work Doesn’t Exist)

You’ll help a lot of people outside the ticketing system. Quick hallway favors, Slack DMs, “hey can you just take a quick look at this.” And none of it counts.

When performance review time comes, when headcount justification happens, when leadership asks “what does the IT team actually do all day,” the ticket system is the only evidence that exists. All that helpful work you did without a ticket? It might as well not have happened.

This isn’t just about tracking your wins. It’s about protecting yourself and your team. If your department handles 200 tickets a month but actually resolves 400 issues (because half are off-ticket favors), leadership sees a team that handles 200 tickets. When budget cuts come, they’ll staff accordingly.

The Practical Reality

You don’t need to be annoying about it. You don’t need to refuse help until someone files a ticket. But you do need to log the work afterward. Even if it’s a 30-second ticket that says “Resolved password reset for J. Smith via Slack request.”

The best IT pros create tickets for themselves. Not because they love bureaucracy, but because they’ve seen what happens when there’s no paper trail. The documentation practices that feel tedious now are the same ones that save your job later.

Never Make Someone Look Bad in a Group Setting

This applies everywhere, but IT departments are particularly unforgiving about it. If a colleague proposes something technically wrong in a meeting, if your manager makes a factual error in front of leadership, if a developer writes something insecure in a code review with an audience, you handle it privately.

Yes, even if you’re right. Especially if you’re right.

The IT professional who corrects people publicly builds a reputation faster than almost any other workplace behavior. And it’s not the reputation they wanted. You’ll hear the label “brilliant but difficult,” which in practice means “passed over for anything requiring collaboration.”

When to Speak Up Publicly

There’s exactly one exception: if something is about to break production or create a security incident right now. If a colleague is about to drop a database table in prod or push credentials to a public repo, you say something immediately regardless of who’s watching. Nobody holds it against you for preventing a production disaster.

Everything else can wait for a private Slack message or a hallway conversation. “Hey, I had a thought about what you mentioned in the meeting. Want to chat?”

The “On-Call” Expectations Are Different From the Policy

The on-call rotation document says you’re expected to respond within 15 minutes and handle severity 1 and 2 incidents. That’s the official policy.

The unwritten expectation might be very different. In some teams, the on-call person is expected to monitor proactively, not just respond to alerts. In others, you’re expected to handle issues that are technically not your tier because escalating at 3 AM “takes too long.” In some places, there’s an invisible expectation that you’ll check your phone during off-hours even when you’re not technically on-call.

None of this is right or fair. But it’s real. And if you don’t figure it out quickly, you’ll either burn out or develop a reputation for “not being a team player” without understanding why.

Protecting Yourself

Learn the actual expectations by watching what happens when people do the minimum. If the person who only responds to pages (and nothing else) gets side-eyed, that tells you something. If the person who monitors proactively gets praised in team meetings, that tells you something else.

Then decide what you’re willing to give. You’re allowed to set boundaries. But set them with full knowledge of what the unwritten expectations are, so you’re making an informed choice about the tradeoffs. If the on-call culture is pushing you toward burnout, that might be a signal about the team’s health rather than your own performance.

Your Slack Presence Communicates More Than You Think

You might not realize it, but people notice when you’re online. They notice when you’re not. They notice your response time on non-urgent messages. And they form opinions about your work ethic based on a little green dot.

This is particularly acute in remote IT work. When nobody can see you at your desk, the green dot becomes a proxy for “this person is working.” It’s unfair and wrong as a metric. But it’s real.

Senior engineers often have enough political capital to go offline and nobody questions it. New hires don’t. The person who goes grey at 4:30 every day might get viewed differently than the person who’s active until 5:15, even if the first person accomplished twice as much.

Playing This Game Without Losing Yourself

You don’t need to be performatively online. But be aware of the signal you’re sending, especially in your first year. If you need deep focus time offline, communicate it. “Going heads-down on the migration for the next two hours” in your team channel tells people you’re working. A grey dot tells them nothing.

And honestly? If your team judges productivity by presence indicators, that’s worth filing away as data for your next career decision.

The Difference Between “Helpful” and “Territorial”

In IT, there’s a razor-thin line between being the person who jumps in to help and the person who’s stepping on someone else’s work. Cross it and you’ll make enemies without realizing what happened.

Picture this: a ticket comes in for a server issue. It’s assigned to your colleague. You happen to see it and know the fix. Do you:

A) Fix it yourself because you can do it faster B) Send your colleague a message with the solution C) Wait unless asked

The “right” answer depends entirely on your team’s culture. In some teams, A is normal and expected. In others, it’s borderline insulting. Most places land on B being safe, but even that can read as “I don’t think you can handle this” if the relationship isn’t established.

The same action that makes you the person who fixes everything can also make you the person nobody trusts to stay in their lane. The difference is context and consent.

Reading the Room

When you’re new, default to offering help rather than providing it unsolicited. “Need a hand with that server thing?” is always safe. Jumping into someone’s ticket without asking is almost never safe until you’ve been there long enough to know whose work you can touch.

Senior Engineers Get Away With Things You Can’t (Yet)

This one stings, but it’s real. The principal engineer who shows up late, leaves early, pushes code without tests, and ignores meetings? Nobody says anything. You try the same thing on month three and you’re getting a talking-to.

It’s not fair. It’s also not going to change. Senior engineers have built trust over years. They’ve earned the benefit of the doubt through hundreds of successful deployments, late-night incident responses, and critical saves. Their social capital lets them bend rules that you, with no track record, cannot.

The Implication

Don’t use senior engineers as role models for workplace behavior. Use them as role models for technical skill. Watch how they solve problems, how they communicate technical concepts, how they approach architecture decisions. Ignore how they handle meetings, dress codes, and working hours. You’ll earn those freedoms eventually. Claiming them early is a career mistake.

The “Test Environment” Lie

Almost every IT department claims to have a staging environment that mirrors production. In practice, staging is usually six months behind, missing half the integrations, and breaks in ways that production never does.

The unwritten rule: everyone knows the staging environment is inadequate, but nobody wants to be the one to admit that we sometimes test in production (carefully). The official answer to any auditor, any compliance team, any new manager is: “We test everything in staging first.” The reality might involve a lot of “soft deployments” and “limited rollouts” that are really just production testing with extra steps.

You’ll figure this out fast when your change works perfectly in staging and immediately breaks in prod. Don’t call it out in a big meeting. Don’t write it in an email. Have a quiet conversation with a senior team member about “what the real process looks like.”

Information Flows Through Back Channels

The official communication structure says: information goes from leadership to managers to individual contributors, through all-hands meetings and email updates.

The actual information structure: the senior engineer who golfs with the CTO knows about the reorg two weeks before anyone else. The help desk lead who’s friends with the HR coordinator knew about the layoff rumors before your director did. The architect who grabs lunch with the product team knows which projects are getting killed before the official announcement.

How to Tap In Without Being Gossipy

Building informal information channels isn’t about being political or manipulative. It’s about networking within your organization so you’re never blindsided. Have lunch with people outside your team. Chat with folks in other departments. Ask questions like “what’s keeping your team busy lately?” and actually listen.

The IT professionals who are always the last to know about changes that affect them are usually the ones who eat lunch at their desks and only interact with their immediate team. Broaden your radius. Not for gossip. For context.

How You Handle Being Wrong Defines Your Reputation

You will break something. You will push a change that causes an outage. Every engineer who’s worked long enough has a war story, and yours is coming whether you’re ready or not.

What separates the respected engineers from the ones nobody wants to work with is what happens next. The unwritten rule: own it immediately, completely, and without deflection. “I pushed that change. It broke this. Here’s what I’m doing to fix it.” Full stop.

The people who hedge (“well, it worked in staging”), deflect (“the documentation was wrong”), or minimize (“it only affected three users”) erode trust with every incident. The people who say “I messed up, here’s the fix, here’s what I’ll do differently” build credibility that lasts years.

This is closely related to why performance reviews go badly for people who can’t self-assess honestly. Leaders value self-awareness more than perfection.

The “Not My Job” Line Is Real (And Invisible)

Every IT role has a job description. And every IT role also has a set of tasks that are technically someone else’s job but somehow end up on your plate. Knowing which “not my job” tasks to accept and which to redirect is a skill that takes years to develop.

Safe to absorb: Quick wins that build goodwill, tasks that teach you something new, requests from people who’ll return the favor.

Redirect firmly: Tasks that set a permanent precedent, work that prevents you from doing your actual responsibilities, requests that should clearly be a different team’s problem.

The help desk tech who starts doing basic sysadmin work without pushback will be doing sysadmin work forever, without the sysadmin title or pay. The sysadmin who never helps with a quick desktop issue becomes “not a team player.” Finding the middle ground is art, not science.

If you’re spending more than 30% of your time on work that isn’t in your job description, it’s time to either negotiate a title change or start redirecting more firmly.

The Meta-Rule: Watch Before You Act

All of these unwritten rules share a common thread: observation is more valuable than action in your first few months. The person who watches, listens, and asks thoughtful questions builds a map of the invisible terrain before they need to navigate it at speed.

You’re probably skeptical that a bunch of social dynamics matter as much as technical skill. That’s fair. But ask any IT veteran and they’ll tell you: the technical stuff is learnable. The political stuff is what gets people fired, passed over, or stuck in roles they’ve outgrown.

The best approach during your first 90 days is aggressive observation and conservative action. Learn the rhythms. Identify the real power structures. Figure out what’s actually expected versus what’s written down. Then start operating with the full picture instead of just the official one.

You’ll make mistakes. Everyone does. The difference between a career-damaging mistake and a learning moment often comes down to whether you violated a written rule or an unwritten one. Written rules have clear consequences. Unwritten rules have social consequences that nobody warns you about and nobody explains after the fact.

Pay attention. Ask questions. Watch the senior people. And when in doubt, default to overcommunicating and underpromising. The rest you’ll figure out with time.

FAQ

How do I figure out the unwritten rules at a new IT job?

Watch more than you talk during your first 30 days. Pay attention to what gets praised in team meetings, who gets consulted before decisions, how people communicate (Slack vs. email vs. in-person), and what behaviors senior engineers exhibit. Ask direct questions to trusted teammates: “Is there anything about how things actually work here that I should know?” Most people will share if you ask sincerely.

What if the unwritten rules conflict with my values?

That’s valid and important data. If the unspoken expectation is working 60-hour weeks, responding to pages during vacation, or tolerating disrespectful communication, those aren’t just “cultural norms.” They’re potential dealbreakers. Give yourself 3-6 months to separate “things that are different from what I’m used to” from “things that are genuinely harmful.” Then make a decision about whether you can thrive there.

Can I change the unwritten rules at my company?

Yes, but only after you have credibility and social capital. Trying to change team culture on day one marks you as naive. Trying to change it after two years of consistent, trusted contributions marks you as a leader. Build the reputation first, then start pushing boundaries. Start with small, low-risk experiments. Propose one process improvement. Model the behavior you want to see. Cultural change in IT departments is slow but possible.

Do these rules apply at startups vs. large enterprises?

The specific rules differ, but the concept of unwritten expectations exists everywhere. Startups tend to have fewer formal rules but stronger unwritten ones (“everyone ships on weekends during launch”). Enterprises have more formal process but the informal power structures are deeper and harder to map. Either way, learning to observe before acting helps at any company size.

How do I avoid getting stuck as the “go-to person” without being unhelpful?

Help strategically rather than reflexively. Document solutions so people can self-serve next time. When someone asks for help, occasionally say “let me show you how to find that” instead of just giving the answer. Build a reputation for making others capable rather than making yourself indispensable. The person who teaches is valued differently than the person who just does.