You got the promotion. You got the title. You probably got a raise. And now you’re sitting in your first week as an IT manager wondering why nobody warned you about any of this.

The job postings made it sound straightforward. “Lead a team of engineers.” “Drive technical strategy.” “Manage cross-functional projects.” What they didn’t mention is that you’d spend your first month feeling like you forgot how to do your job, that your former teammates would start acting different around you, and that your calendar would become a war zone overnight.

Here’s what’s actually waiting for you on the other side of that career progression, and what you can do about it.

Your Technical Skills Just Became Secondary

This is the first gut-punch, and it hits hard. You spent years building technical expertise. You troubleshot the impossible tickets. You built the systems everyone relied on. That’s why they promoted you.

Now? Most of that doesn’t matter day-to-day.

Your job is no longer to be the best engineer in the room. It’s to make everyone else in the room better. That means your troubleshooting methodology shifts from “fix it yourself” to “help them fix it.” Your deep technical knowledge becomes context for decisions, not hands-on work.

This transition messes with your identity. If you’ve always defined yourself as “the person who knows Active Directory inside and out” or “the one who can script anything,” you’re going to feel unmoored when your days are filled with meetings, one-on-ones, and spreadsheets instead of terminals.

What helps: Accept that your value is measured differently now. Your output isn’t resolved tickets or deployed infrastructure. It’s your team’s output. When they ship something great, that’s your win. It takes months to internalize this, and that’s normal.

Managing Former Peers Is Exactly as Awkward as It Sounds

Nobody talks about this enough. One day you’re complaining about management decisions over lunch with your teammates. The next day, you ARE management.

Some people will adjust naturally. Others will test you. A few might resent you for getting the role they wanted. And at least one person will try to use your friendship to get special treatment, extra time off, less on-call, better projects.

The dynamic shifts immediately, and pretending it doesn’t is the worst thing you can do. If you try to be “the cool manager” who’s still just one of the team, you’ll lose respect from above and below. If you swing too far into authority mode, you’ll alienate the people who used to trust you.

What works: Have direct conversations early. Not a formal meeting with an agenda, just a genuine conversation. Something like: “This is going to be different. I still respect you and value your opinion. But I have to make decisions now that you might disagree with, and I need you to trust that I’m considering the team’s best interest.” Most people respect honesty more than a performance.

The friendships won’t disappear, but they will change shape. You can still grab lunch, but you can’t vent about your boss anymore. You can’t share salary information. You can’t play favorites. The sooner you set those boundaries, the less painful the adjustment.

You’ll Feel Like You’re Accomplishing Nothing

This one sneaks up on you. As an individual contributor, you had tangible wins. A script that saved 40 hours a month. A migration that went perfectly. A fire you put out at 2 AM. You could point to something and say, “I did that.”

Management work is mostly invisible. You spent 90 minutes in a meeting making sure your team’s project doesn’t get derailed by another department’s priorities. You had a tough one-on-one that helped a struggling engineer get back on track. You spent an hour reviewing next quarter’s budget to make sure you can hire that additional headcount.

None of that feels productive. You’ll go home some days thinking, “What did I even do today?” Meanwhile, your former peers are shipping code and closing tickets and feeling like they moved the needle. You might start wondering if you made a mistake.

The reality: What you’re doing matters more than any single ticket. You’re creating the conditions for an entire team to succeed. But the feedback loop is weeks or months, not hours. The sysadmin who gets unblocked because you fought for better tooling in a budget meeting won’t know that meeting happened. The engineer who grows into a senior role because you gave her stretch assignments won’t connect that growth to your decisions for a long time.

This is probably the hardest mental shift in the entire transition. Keep a brag document of what you accomplish as a manager, not just what your team ships. It’ll save you during performance review season.

The Conversations Nobody Prepares You For

Technical skills are predictable. You learn a system, you troubleshoot it, you improve it. People are not predictable.

Within your first year as a manager, you’ll probably face at least one of these:

Telling someone their work isn’t good enough. Not in a code review where you can hide behind technical objectivity. A real conversation where you have to tell a human that they’re underperforming and it needs to change. Most new managers avoid this conversation for way too long, hoping the problem fixes itself. It doesn’t.

Navigating a conflict between two team members. Two engineers who can’t stand each other, or who disagree on a technical direction so fundamentally that it’s poisoning team dynamics. You can’t take sides, and you can’t ignore it.

Delivering bad news from above. Budget cuts. A project cancellation. A re-org. Return-to-office mandates. Your team will look at you like you made the decision, even when you didn’t. You have to represent a position you might personally disagree with, while also advocating for your team behind closed doors. This is what managing up actually looks like in practice.

Someone crying in a one-on-one. Personal issues, burnout, feeling stuck, frustration with the company. It happens more than you’d expect, and there’s no playbook for it. You’re not a therapist, but you also can’t just say “let’s get back to the sprint review.”

What helps: Read one management book. Seriously, just one. “The Manager’s Path” by Camille Fournier is written specifically for tech managers and covers these situations practically. Also, find a peer group of other managers. IT leadership can feel isolating, and having someone who understands the specific pressures of managing technical teams is invaluable.

Your Calendar Is Your New Battleground

As an individual contributor, maybe you had a few meetings a day. Now? Your calendar might be 70-80% meetings on a bad week.

Stand-ups. One-on-ones. Project syncs. Leadership meetings. Cross-department reviews. Incident reviews. Hiring panels. Vendor calls. Strategy sessions. And somewhere in between all of that, you need time to actually think.

New managers make two common mistakes here:

Mistake one: accepting every meeting. You feel like you need to be everywhere, know everything, and be visible. Within a month, you have zero time for strategic thinking, your one-on-ones start slipping, and you’re answering emails at 10 PM because there’s no other time.

Mistake two: declining too many meetings. You overcorrect, trying to protect your time, and suddenly you’re out of the loop on decisions that affect your team. Someone makes a choice in a meeting you skipped, and now your team is dealing with the fallout.

What works: Block out at least two hours per day as focus time. Treat it as non-negotiable. For meetings you must attend, know the difference between “I need to be there” and “I need to be informed.” For the latter, ask for notes or a five-minute summary. Protect your one-on-ones above all else, because those are where you actually manage.

Your one-on-ones are sacred. They’re not status updates (that’s what stand-ups and project tools are for). They’re your opportunity to understand what’s blocking your team, what they’re worried about, and where they want their career to go. Skip these consistently and you’ll lose the thread on your team faster than anything.

The Loneliness Nobody Mentions

This sounds dramatic, but it’s real. You’re no longer part of the team in the same way. You can’t participate in the organic conversations that happen when people trust everyone in the room is at the same level. Your presence changes the energy in a Slack channel or a lunch table, whether you want it to or not.

At the same time, you’re probably the most junior person in the management layer. Your peers are directors or VPs who’ve been doing this for years. You might feel like you don’t belong there either.

You’re in between. Not quite an engineer, not yet a seasoned leader. And the problems you’re dealing with, you often can’t talk about them with anyone. You can’t tell your team about the budget fight you’re losing. You can’t tell your boss that one of your reports is struggling with personal issues. You’re holding information for multiple people simultaneously, and the weight of that discretion is something nobody warns you about.

What helps: Find your peer group outside your direct team. Other new managers, either at your company or in the broader IT community. LinkedIn groups for IT managers, local meetups, or even Slack communities for engineering leaders. Having one person you can text “is this normal?” makes a massive difference.

Staying Technical Without Micromanaging

Every new IT manager wrestles with this. You know how to solve the problem faster than anyone on your team. You can see the mistake they’re about to make. Your fingers itch to just jump in and fix it.

Don’t.

The moment you start coding alongside your team, reviewing every pull request, or second-guessing their architecture decisions, you’ve become a bottleneck. Your team stops growing because they know you’ll catch everything. Worse, they stop trying to make hard decisions because you’ll just override them anyway.

But going fully non-technical isn’t the answer either, especially in IT. You need enough technical context to make good decisions, evaluate trade-offs, have credibility with your team, and translate technical reality to business stakeholders.

The balance looks like this:

  • Stay informed on the architecture and big technical decisions. Skip the implementation details.
  • Read documentation and design docs. Don’t review every commit.
  • Keep a small personal project or learning habit to stay sharp. Maybe run through some Shell Samurai exercises or maintain a small home lab. This keeps your skills from fully atrophying without pulling you back into IC work during business hours.
  • When your team asks for your technical opinion, give it as a suggestion, not a directive. “Have you considered X?” works better than “Do X.”
  • Let them fail on non-critical things. The lessons that stick are the ones they learn themselves.

If you came from a deeply technical background, this restraint is genuinely painful. But your team will grow faster when you step back, and the good engineers will respect you more for trusting them.

What They Don’t Tell You About Hiring

If you’re lucky, you’ll get to grow your team. If you’re unlucky, you’ll have to replace someone. Either way, hiring is now part of your job, and it’s harder than anyone admits.

Writing job descriptions forces you to figure out what you actually need, not what sounds impressive. A common trap is writing the job posting as a wish list of every technology your team touches. You’ve probably complained about job postings like that yourself. Now it’s your job not to write one. Focus on the three to five things that actually matter for the role. Remember that IT job posts are wish lists, and try not to create one yourself.

Interviewing is a skill, and you don’t have it yet. You’ll ask bad questions, misjudge candidates, and probably either hire too fast or take too long. The biggest mistake new managers make is hiring for technical skills alone and ignoring how someone works with a team. The second biggest mistake is hiring someone who reminds them of themselves instead of someone who fills a gap.

Firing is worse. Letting someone go, whether for performance or a layoff, is one of the hardest things you’ll do as a manager. No amount of preparation makes it feel okay. Do it respectfully, do it directly, and don’t drag it out with months of vague feedback that never clearly states the problem.

The Stuff That Actually Gets Easier

It’s not all bad. Some things genuinely improve when you move into management, and nobody talks about those either because complaining is more relatable.

You have more influence over direction. As an IC, you could suggest better tooling or argue for paying down tech debt. As a manager, you can actually prioritize it. You can make the case to leadership in their language, with budget implications and business impact. That infrastructure upgrade you’ve been wanting for two years? You can fight for it now with authority behind you.

You can protect your team. From unreasonable deadlines, from scope creep, from that one stakeholder who always shows up with “urgent” requests. You become the shield between your team and organizational chaos. When you inherit a messy environment, you now have the authority to prioritize fixing it instead of just surviving it.

You can shape careers. Watching someone you mentored grow from a junior admin into a confident engineer is one of the most rewarding experiences in tech. You can give someone the opportunity that nobody gave you. You can make sure the quiet person with great ideas gets heard in meetings. You can advocate for raises your team deserves.

You understand the bigger picture. Why did leadership make that baffling decision last quarter? Now you know, because you’re in the room. Not everything makes more sense from up here, but a lot of it does. The frustration of “management doesn’t get it” starts to shift into “management is dealing with constraints I didn’t know existed.”

The One-Year Check-In With Yourself

After about a year, you’ll know. Not whether you’re good at it yet (you probably won’t be), but whether you want to keep doing it.

Some people discover they love the strategic thinking, the people development, the organizational chess. They realize the path to IT director or VP is exactly where they want to go.

Others realize they miss the work. They miss solving technical problems directly, miss the satisfaction of building something with their own hands. That’s not failure. Some of the best engineers in the industry tried management, learned valuable things from it, and went back to individual contributor roles with a broader perspective. The technical lead vs. manager decision isn’t permanent.

If you’re considering the jump, read up on what the path to IT management actually looks like and what the compensation looks like. But know that no amount of reading replaces living it. The only way to know if management is for you is to try it.

And if you’re in month three, feeling overwhelmed and questioning everything? That’s not a sign you made the wrong choice. That’s a sign you’re paying attention.

FAQ

How long does it take to feel comfortable as a new IT manager?

Most new managers report feeling reasonably competent around the 6-12 month mark, but confidence in the role typically takes 18 months to two years. The first three months are almost universally rough. If your company offers management training or a mentorship program, take advantage of it immediately rather than trying to figure everything out alone.

Should I still do technical work as an IT manager?

It depends on team size. If you’re managing three to five people, you might retain some technical responsibilities. Above six direct reports, your time is almost entirely consumed by management work. Either way, avoid being in the critical path for any technical deliverable. Your team should be able to ship without you touching the code or infrastructure directly.

What’s the biggest mistake first-time IT managers make?

Avoiding difficult conversations. Underperformance, interpersonal conflict, unreasonable requests from leadership. New managers tend to hope these problems resolve themselves. They rarely do. The longer you wait to address an issue, the harder and messier the conversation becomes. Practice direct, respectful communication early and often.

How do I handle a team member who wanted my promotion?

Acknowledge it directly. Something like: “I know you were interested in this role, and I respect that. I want to understand what your career goals are and how I can help you get there.” Give them meaningful work and growth opportunities. If they continue to undermine you after a reasonable adjustment period, that becomes a performance conversation, not a personal one.

Is it possible to go back to an individual contributor role?

Absolutely, and it’s more common than people think. Many companies now have parallel career tracks where senior individual contributors earn as much as managers. If you try management and decide it’s not for you, the experience still makes you a better IC. You’ll understand organizational dynamics, communicate more effectively with leadership, and make decisions with broader context. It’s never wasted time.