IT Manager’s First 90 Days: Priorities, Stakeholders, and Quick Wins

Congratulations—you’ve landed the IT manager role. Maybe it’s your first time in the seat, or maybe you’ve managed teams before but just walked into a new organization with its own legacy systems, political dynamics, and a backlog that could fill a warehouse. Either way, the clock is already ticking. Leadership wants to see impact. Your team wants direction. And somewhere in your inbox, there are three “urgent” tickets, a vendor renewal due next week, and a vague request from the CFO about “cloud costs.”

Here’s the uncomfortable truth most career guides won’t tell you: new IT managers get pulled into urgent work and lose strategic momentum before the end of week two. The firefighting feels productive—you’re solving problems, proving your technical chops, earning some goodwill—but three months later you look up and realize you still don’t have a roadmap, your stakeholders aren’t aligned, and your team is running on the same reactive patterns you inherited. I’ve seen it happen over and over. That’s the trap this guide is designed to help you avoid.

What follows is a practical, phase-by-phase playbook for your first 90 days in IT management. We’re not going to give you generic advice like “build relationships” or “learn the business.” Instead, we’ll walk through three focused phases—Stability, Visibility, and Roadmap—with explicit priorities, deliberate tradeoffs (including what to delay), and realistic quick wins that build credibility without burning out your team. By the end, you’ll have a weekly and monthly plan template you can adapt to your organization starting tomorrow.

Why the First 90 Days Matter More Than You Think

Research on leadership transitions consistently shows that the impressions formed in the first three months are remarkably sticky. For an IT manager, this window is even more compressed because technology touches every department. Your finance team cares about budgeting and license costs. Your operations team cares about uptime. Your executives care about risk and whether IT is a cost center or a strategic enabler. Everyone has an opinion, and—trust me on this—everyone is watching.

So what are these first 90 days actually about? They’re not about proving you’re the smartest technologist in the room. They’re about demonstrating three things: that you can stabilize operations so nothing breaks worse than it already is, that you can communicate clearly so stakeholders feel informed rather than anxious, and that you have a credible plan for where IT is headed. Get those three things right, and you’ll earn the trust and runway to make real changes in months four through twelve.

The Three-Phase Framework at a Glance

Phase 1: Stability (Days 1–30) — Understand the current state, stop the bleeding, and establish basic operating rhythms.
Phase 2: Visibility (Days 31–60) — Build stakeholder relationships, create reporting cadences, and formalize how work enters your team.
Phase 3: Roadmap (Days 61–90) — Synthesize what you’ve learned into a prioritized plan, secure executive alignment, and set KPIs that matter.

Each phase has a primary objective, a set of deliverables, and—critically—a list of things you should deliberately defer. That last part is what separates this framework from the dozens of “first 90 days” articles that try to boil the ocean.

Phase 1: Stability (Days 1–30)

Your first month is about one thing: getting control of day-to-day IT operations management without breaking anything new. I know it’s tempting to redesign processes, renegotiate vendor contracts, or pitch a cloud migration in your first week. Resist that urge. You don’t have enough context yet, and premature changes will erode trust with your team—the people who’ve been keeping the lights on before you showed up.

Week 1: Listen, Observe, Document

Spend your first week almost entirely in listening mode. This might feel unproductive, but it’s arguably the most valuable thing you can do. Schedule 30-minute one-on-ones with every member of your IT team. Ask the same three questions: What’s working well? What’s broken? What do you wish leadership understood? Take detailed notes. You’re not solving problems yet—you’re building a map of the terrain.

Simultaneously, get access to the essentials:

Ticketing system: Review the last 90 days of incidents. Look for patterns—repeat issues, escalation bottlenecks, tickets that sat unresolved for weeks. Understanding your IT support tiers and escalation paths is critical before you can improve them.
Network and infrastructure documentation: Even if it’s outdated (and let’s be honest, it probably is), find whatever exists. Note the gaps.
Vendor contracts and renewal dates: You need to know what’s coming due in the next 90 days so nothing auto-renews without your review.
Budget and spend reports: Get a basic picture of where money is going. Don’t try to optimize yet—just understand.
Backup and disaster recovery status: Verify that backups are running and have been tested recently. If they haven’t, flag this immediately. Seriously—this one can’t wait.

Weeks 2–3: Establish Operating Rhythms

The single most impactful thing you can do in your first month is establish a basic operating cadence. This doesn’t require new tools or a process overhaul—it just requires consistency. Here’s what to put in place:

Daily standup (15 minutes): A quick sync with your team on what’s in progress, what’s blocked, and what’s coming in. Keep it tight. This replaces the “hallway ambush” culture that plagues most reactive IT teams.
Weekly team meeting (45 minutes): Review open tickets, upcoming changes, and any incidents from the past week. Start building a habit of structured incident management review. Even if it feels a bit formal at first, your team will appreciate the predictability.
Weekly personal review (30 minutes, solo): Block time on your calendar to step back and assess what you’re learning. Update your running document of observations, risks, and opportunities. Think of this as your personal compass check.

These rhythms serve a dual purpose: they give your team structure and predictability, and they give you a consistent flow of information so you’re not relying on random Slack messages to understand what’s happening.

Week 4: Identify Your First Quick Win

By the end of month one, you should have enough data to identify one or two quick wins—small, high-impact improvements that reduce pain for your team or your users. What makes a great quick win? The best ones share three characteristics:

They address a repeat incident that everyone is tired of dealing with.
They can be completed in one to two weeks without significant budget or approval.
They have visible impact to people outside the IT team.

Examples: fixing a recurring printer issue that generates 10 tickets a month, documenting and publishing a self-service password reset process, or clarifying ownership of a shared mailbox that three departments fight over. These aren’t glamorous. Nobody’s writing a case study about your printer fix. But they demonstrate competence and build goodwill—and that goodwill is currency you’ll need later.

What to Deliberately Delay in Phase 1

Tool migrations or replacements: You don’t know enough yet to choose wisely.
Org structure changes: Don’t reorganize the team until you understand the current dynamics.
New project commitments: Politely defer any new project requests with “I’m assessing our current capacity and will have a clearer picture by the end of month two.”
Vendor renegotiations: Unless something is expiring imminently, wait until you have leverage and context.

Phase 2: Visibility (Days 31–60)

With basic stability established and operating rhythms in place, your second month shifts focus outward. Phase 2 is about stakeholder communication, formalizing how work enters your team, and making IT’s contributions visible to the rest of the organization. This is where many technically skilled IT managers stumble—not because they can’t do the work, but because they don’t invest enough in making the work legible to non-technical leaders. It’s a different muscle, and it takes practice.

Mapping and Meeting Your Stakeholders

If you haven’t already, create a simple stakeholder map. It doesn’t need to be fancy—a spreadsheet or even a whiteboard sketch works fine. For most organizations, an IT manager’s key stakeholders include:

Your direct manager (CTO, VP of IT, COO, or CEO in smaller orgs)
Finance / CFO: Cares about IT budgeting, cost optimization, and ROI
Department heads: Care about whether IT enables or blocks their teams
Security / compliance: Cares about risk, IT governance, and audit readiness
Key vendors: Your MSP, cloud providers, critical SaaS partners

Schedule a 30-minute introductory meeting with each stakeholder group. Come prepared with two things: a brief summary of what you’ve observed in your first month (keep it factual, not critical of predecessors), and two or three questions about their priorities and pain points related to IT. This isn’t a presentation—it’s a conversation. Your goal is to understand what “good IT” looks like from their perspective. You might be surprised how much it varies from person to person.

How Do IT Managers Communicate with Executives?

This is one of the most common questions new IT managers ask, and honestly, the answer is simpler than most people make it: communicate in business outcomes, not technical details. Your CEO doesn’t need to know you migrated from RAID 5 to RAID 6. They need to know that the risk of data loss during a drive failure dropped from “likely” to “very unlikely,” and that it cost $X to achieve. See the difference? Same work, completely different framing.

Establish a monthly IT status report for your direct manager and, if appropriate, the executive team. Keep it to one page—yes, one page. Include:

Operational health: Uptime percentage, ticket volume trends, major incidents (if any)
Projects in progress: Status, timeline, and any blockers that need executive help
Budget status: Spend vs. forecast, upcoming renewals or capital requests
Risks and recommendations: One or two items that need awareness or decision

This report becomes your most powerful tool for IT leadership credibility. It shows you’re in control, you’re thinking ahead, and you’re not going to surprise anyone. Here’s something worth remembering: executives hate surprises more than they hate bad news.

Formalizing Work Intake: The Ticket and Project Funnel

One of the most common failure modes in IT operations management is the absence of a clear intake process. When anyone can walk up to any technician and request anything, you get invisible work, conflicting priorities, and burned-out staff. Sound familiar? During Phase 2, implement a simple but firm intake process:

All requests go through the ticketing system. No exceptions. If someone emails you directly, reply with a link to the ticket portal. Be polite but consistent—this is a hill worth dying on. Understanding what is an IT service helps your team and your users distinguish between break-fix support and new service requests.
Categorize incoming work into three buckets: incidents (something is broken), service requests (someone needs something), and projects (something new or large). Each bucket has a different workflow and different expectations for turnaround time.
Create a visible project intake queue: When a department head asks for a new system or integration, it goes into a prioritized list that you review weekly. This is how you start managing team prioritization transparently—and it’s a game-changer for managing expectations.

Vendor Touchpoints

By month two, you should have a clear picture of your critical vendor relationships. Schedule introductory calls with your top three to five vendors. The purpose is threefold: understand your current contract terms, assess the quality of service delivery you’re receiving, and signal that there’s new leadership paying attention. That last point matters more than you’d think—vendors tend to step up their game when they know someone’s actively watching.

You don’t need to renegotiate anything yet—just establish the relationship and let them know you’ll be reviewing performance and contracts over the coming quarter.

If your organization relies on an external provider for day-to-day support, this is also a good time to evaluate whether that arrangement is actually serving you well. For many growing companies, partnering with managed IT services for growing teams can provide the scalability and expertise that an internal team alone may struggle to maintain.

What to Deliberately Delay in Phase 2

Major policy changes: You can draft them, but don’t roll out new IT policies until you’ve validated them with stakeholders in Phase 3.
Performance reviews or team restructuring: You’re still building trust with your team. Premature personnel changes will backfire—almost guaranteed.
Large capital expenditure requests: Wait until you have a roadmap to justify them.

Phase 3: Roadmap (Days 61–90)

You’ve stabilized operations. You’ve built relationships and created visibility. Now it’s time to pull everything together into a forward-looking IT roadmap that earns executive buy-in and gives your team a clear direction. This is the phase where you transition from “the new person getting up to speed” to “the leader with a plan.” It’s a meaningful shift, and people will notice.

Building Your IT Roadmap

Your roadmap doesn’t need to be a 50-slide PowerPoint deck. (Please don’t make it a 50-slide deck.) In fact, the simpler it is, the more likely it is to survive contact with reality. Structure it around three time horizons:

Next 90 days (Q2): Two to three specific initiatives with clear owners, timelines, and success criteria. These should be direct extensions of the quick wins and pain points you’ve already identified.
6-month horizon: Three to five strategic priorities that require more planning, budget, or cross-functional collaboration. Examples: implementing a formal change management process, consolidating redundant SaaS tools, or upgrading core infrastructure.
12-month vision: A high-level narrative about where IT needs to be in a year to support the business. This is where you connect IT initiatives to business goals—revenue growth, compliance requirements, geographic expansion, and so on.

Present this roadmap to your direct manager first for feedback, then to the broader executive team. Frame it as a proposal, not a mandate. Use language like “Based on what I’ve learned in my first 90 days, here’s what I recommend we prioritize and why.” This invites collaboration rather than resistance—and it shows intellectual humility, which goes a long way with senior leaders.

What KPIs Should an IT Manager Track?

Metrics matter, but here’s the thing—tracking too many IT KPIs is almost as bad as tracking none. You end up drowning in dashboards and losing sight of what actually matters. In your first 90 days, commit to a small set of meaningful indicators that you can actually measure with your current tools:

Mean time to resolve (MTTR): How quickly are incidents being resolved? Track this by priority level.
Ticket volume trends: Is volume increasing, decreasing, or stable? Are repeat issues declining after your quick wins?
First-contact resolution rate: What percentage of tickets are resolved at the first tier without escalation? This tells you a lot about your team’s capability and your documentation quality.
System uptime / availability: For your critical systems, what’s the actual uptime? Even a rough number is better than “I think it’s fine.”
User satisfaction (informal): You don’t need a formal CSAT survey yet. But pay attention to the tone of feedback from department heads and end users. Are complaints decreasing? Are people less frustrated? That’s data too.
Budget adherence: Are you tracking to your forecast? Any unexpected variances?

These metrics feed directly into your monthly status report and give you the data to justify roadmap priorities. Over time, you can layer in more sophisticated IT service management metrics, but start with what you can actually measure and act on. Perfect is the enemy of good here.

How Do IT Managers Prioritize Incidents vs. Projects?

This is the tension that defines IT management at every level: the urgent vs. the important. If you’ve ever felt like your team spends all day putting out fires with zero time left for anything strategic, you know exactly what I’m talking about. Here’s a practical framework that works for most teams:

Incidents always take priority over projects when they affect business operations. A P1 incident (system down, multiple users affected) stops all project work until resolved. This is non-negotiable.
Protect project time on the calendar. Block specific hours or days for project work and treat them as commitments, not suggestions. If your team spends 100% of their time on reactive work, projects will never move forward. Period.
Use the intake queue to make tradeoffs visible. When a new request comes in, don’t just add it to the list—show stakeholders what it displaces. “We can start this project next month, but it means the network upgrade moves to Q3. Is that acceptable?” This forces honest prioritization conversations instead of everyone pretending everything is top priority.
Reduce incident volume systematically. Every repeat incident you eliminate frees up capacity for project work. This is why quick wins in Phase 1 are so important—they’re not just about optics; they’re about creating breathing room for your team to actually build things.

What to Deliberately Delay (Even Beyond 90 Days)

Full IT governance framework: You should start laying the groundwork, but a mature governance model takes six to twelve months to implement properly. Don’t rush it.
Enterprise architecture redesign: Unless there’s an urgent security or compliance driver, major architecture changes belong in the six-to-twelve-month horizon.
Chasing “best practice” perfection: ITIL, COBIT, and other frameworks are valuable, but adopting them wholesale in your first quarter is a recipe for process fatigue. Take what’s useful, adapt it to your reality, and iterate.

What Does an IT Manager Do Day to Day?

If you’re reading this before stepping into the role—maybe you’re preparing for an interview or weighing a career move—you might be wondering about IT manager daily tasks in practical terms. The honest answer? No two days look the same. But a well-run day typically includes a mix of:

Operational oversight: Reviewing the ticket queue, checking on critical systems, and addressing escalations. This is the “keep the lights on” work that never fully goes away, no matter how senior you get.
People management: One-on-ones with team members, coaching, removing blockers, and managing workload distribution. This is where a lot of your real impact happens.
Stakeholder interaction: Responding to requests from other departments, attending cross-functional meetings, and providing updates to leadership.
Planning and prioritization: Reviewing the project intake queue, updating the roadmap, and making resource allocation decisions.
Vendor and budget management: Reviewing invoices, managing renewals, and evaluating new solutions.
Strategic thinking: Carving out time (even just 30 minutes) to think about where IT needs to go, not just where it is today. This one’s easy to skip. Don’t.

The balance shifts over time. In your first 90 days, you’ll spend more time on operational oversight and stakeholder conversations. As you grow into the role, you should be spending more time on strategy and less on day-to-day firefighting. If that shift isn’t happening by month six, it’s a signal that you need to invest more in team development, process improvement, or both.

What’s the Difference Between IT Manager and IT Project Manager?

This question comes up all the time, and the distinction matters—especially for career planning. An IT manager is responsible for the ongoing operations, team leadership, and strategic direction of an organization’s IT function. You own the service, the people, and the budget. An IT project manager, by contrast, is responsible for delivering specific initiatives on time and within scope. They typically don’t manage staff permanently or own operational services.

In smaller organizations, these roles often blur together—the IT manager ends up being the de facto project manager for every IT initiative. (If that sounds exhausting, it’s because it is.) In larger organizations, they’re distinct roles with different reporting lines. Understanding this distinction helps you set boundaries and, when possible, advocate for dedicated project management support so you can focus on IT leadership rather than getting buried in Gantt charts.

Your 90-Day Plan Template

Here’s a condensed, adaptable template you can customize for your organization. Print it, pin it to your wall, or drop it into your project management tool—whatever keeps it visible.

Phase 1: Stability (Days 1–30)

Week 1: Team 1:1s, system access, documentation review, ticket history analysis
Week 2: Establish daily standup and weekly team meeting; verify backup and DR status
Week 3: Map vendor contracts and renewal dates; review current budget and spend
Week 4: Identify and execute first quick win; document observations and risks
Deliverables: Running observation document, operating cadence in place, one quick win in progress
Defer: Tool changes, org restructuring, new project commitments

Phase 2: Visibility (Days 31–60)

Week 5: Stakeholder mapping and introductory meetings
Week 6: Formalize ticket intake process; categorize work into incidents, requests, and projects
Week 7: Launch monthly IT status report; conduct vendor introductory calls
Week 8: Create visible project intake queue; deliver second quick win
Deliverables: Stakeholder map, first monthly report, formal intake process, vendor relationship baseline
Defer: Major policy rollouts, performance reviews, large capital requests

Phase 3: Roadmap (Days 61–90)

Week 9: Draft IT roadmap (90-day, 6-month, 12-month horizons)
Week 10: Define initial KPIs and baseline measurements
Week 11: Review roadmap with direct manager; incorporate feedback
Week 12: Present roadmap to executive stakeholders; finalize Q2 priorities
Deliverables: IT roadmap document, KPI dashboard (even if it’s just a spreadsheet—no shame in that), executive alignment on priorities
Defer: Full governance framework, enterprise architecture redesign, framework adoption at scale

Common Pitfalls to Avoid

Even with a solid plan, new IT managers fall into predictable traps. I’ve watched it happen enough times to know these are worth calling out explicitly:

Trying to fix everything at once: You’ll identify dozens of problems in your first month. Resist the hero complex. Pick the highest-impact items and sequence the rest. Your roadmap is a prioritization tool, not a to-do list.
Going dark on communication: When you’re heads-down solving problems, it’s easy to forget that stakeholders are waiting for updates. Silence breeds anxiety—always. Even a brief “here’s where things stand” email goes a long way.
Criticizing your predecessor: Whatever state IT was in before you arrived, publicly criticizing the previous manager or team erodes trust. It might feel satisfying in the moment, but it always backfires. Focus on the future, not the blame.
Ignoring your team’s expertise: Your team has institutional knowledge you don’t have and won’t have for months. The fastest way to lose them is to dismiss their input or override their judgment without understanding the context behind their decisions.
Over-promising to executives: It’s tempting to say yes to everything in your first 90 days to build goodwill. But every “yes” without a corresponding tradeoff conversation sets you up for failure down the road. Practice saying, “Yes, and here’s what that would require” or “Yes, but it would mean delaying X.” It feels uncomfortable at first. Do it anyway.

Setting Yourself Up for Long-Term Success

The first 90 days are a foundation, not a finish line. As you move into months four through twelve, the habits and structures you’ve built should compound. Your operating cadence keeps the team aligned. Your monthly report keeps stakeholders informed. Your intake process keeps work visible and prioritized. And your roadmap gives you a framework for saying “not yet” to good ideas that don’t fit the current quarter’s priorities.

The IT manager career path rewards people who can balance operational excellence with strategic thinking—who can keep the systems running while also articulating where technology should take the business next. Your first 90 days are your chance to prove you can do both. Not by being the smartest person in the room, but by being the most organized, the most communicative, and the most deliberate about where you focus your energy.

Conclusion: Your 90-Day Playbook Starts Now

Stepping into an IT manager role is equal parts exhilarating and overwhelming. The sheer volume of things that need attention can paralyze even experienced leaders. But by structuring your first 90 days into three focused phases—Stability, Visibility, and Roadmap—you give yourself permission to be strategic about what you tackle and, just as importantly, what you deliberately delay. You don’t need to have all the answers on day one. You need a framework for finding the right answers in the right order.

Take the template above, adapt it to your organization’s size and complexity, and start executing. Block the time on your calendar. Have the stakeholder conversations. Ship the quick wins. Build the report. And when you present your roadmap at the end of month three, you won’t just be the new IT manager—you’ll be the leader with a plan, a track record of early wins, and the credibility to drive real change. That’s how you turn 90 days of momentum into years of impact.

IT Manager’s First 90 Days: Priorities, Stakeholders, and Quick Wins