Your First 100 Days in a New IT Role: A Practical Playbook
The first 100 days in a new IT or ops role set the tone for everything that follows. Get them right and you're someone the team trusts with scope and decisions. Get them wrong and you spend the next year clawing back credibility you accidentally gave away in the first week.
This is the playbook I wish I'd had when I started each of my last three roles. Week-by-week. Concrete actions. What to do, what to document, and what — critically — to not touch.
Week 1: The Listening Tour
Your only real job in the first week is to listen well and write down what you hear. Resist every urge to fix, optimise, or suggest. You don't know enough yet to be right.
People to meet (in this order)
- Your direct manager — 1:1. Ask: what would success at 90 days look like? What are they most worried about? What did the last person in this seat get wrong?
- Your predecessor if they're still reachable — even a 20-minute call. Ask about the booby traps, the fragile systems, and the political landmines.
- The three people who complained loudest about IT before you arrived — often finance, ops, and customer-facing teams. Ask what "good IT" would look like from where they sit.
- The person who knows where everything is — every org has one. Often an office manager or long-tenured admin. They'll tell you more in an hour than official onboarding will in a week.
- Your team (if you have reports) — individual 1:1s, not a group meeting. Ask what they want to work on more, what they want to work on less, and what a great manager for them looks like.
Things to read
- The organisational chart. Screenshot it, add it to your notes, annotate it as you meet people.
- Every existing IT policy, runbook, and SOP — even the dusty ones
- Last quarter's incident reports, if they exist
- The last six months of the support ticket queue — read the themes, not every ticket
- Any recent security or compliance audits
What NOT to do in week 1
- Don't change passwords or access
- Don't criticise the previous system publicly
- Don't propose a re-architecture
- Don't try to impress anyone with how much you know
Your leverage in week 1 is curiosity, not expertise. The team will grant you the latter if you demonstrate the former convincingly.
Weeks 2–4: The Documentation Pass
By week two you've heard enough. Now you start producing something concrete: the documentation that should have existed and didn't.
Pick the three highest-leverage runbooks
For any IT/ops role, these three usually top the list:
- Password reset / account lockout procedure — the single most frequent ticket type in almost every org. A clean runbook saves the team hours per week.
- New-hire onboarding checklist — the checklist of every account, device, software licence, and access grant a new hire needs. Most orgs don't have this written down clearly.
- Offboarding procedure — the security-sensitive counterpart. What gets deprovisioned, when, by whom, and in what order.
Write each one, review it with someone who actually uses it, publish it to a shared location, and circulate the link.
Build your inventory
If the org doesn't have a current asset inventory — devices, software licences, SaaS subscriptions, domain names, certificates — start one. Even a spreadsheet is a massive upgrade over no inventory at all. You cannot secure, budget for, or scale what you can't count.
Map the integrations
Every mid-sized org has a tangle of SaaS tools that talk to each other in ways nobody fully remembers. Start a one-page diagram: what systems exchange data, via what mechanism (API, webhook, CSV, manual copy-paste), and who owns each side. You will use this diagram every week forever.
Month 2: The Quick Wins
By month two you've listened, documented, and started to see the shape of the org. Now you ship something small and visible. The goal is not to revolutionise — it's to demonstrate that things improve when you touch them.
Characteristics of a good quick win
- Scoped in under two weeks of your time
- Addresses a pain point multiple people named independently in week 1
- Reversible if it doesn't land
- Has a measurable outcome you can point at
- Doesn't require anyone else's roadmap time
Quick wins I've shipped in month 2 of various roles
- A self-service password-reset portal — cut password tickets ~70% in the first month
- A single shared Slack channel for IT announcements — replaced three inconsistent email threads
- An automated new-hire provisioning script — dropped onboarding time from 4 hours to 20 minutes
- A cleaner ticket-categorisation scheme — made reporting possible for the first time
- A dashboard surfacing the three most common issues of the week — gave the team leverage for root-cause work
One solid quick win at day 60 is worth more than ten half-built ambitious projects at day 90.
Month 3: The Strategic Investment
By month three, you've earned the right to propose something larger. This is where you lay the foundation for what year one looks like.
Write a 90-day review doc
At roughly day 90, write a short (3–5 page) document covering:
- What I've learned. The lay of the land, the strengths, the real pain points
- What I've shipped. The quick wins and documentation, with measurable outcomes
- What I recommend we tackle next. 3–5 prioritised initiatives with rough scoping and rationale
- What I need. Budget, access, headcount, or decisions from leadership to unblock the priorities
Share it with your manager first, then — with their blessing — with skip-level leadership. This single document does more to establish you as a strategic operator than any hundred good deeds in the ticket queue will.
Start one bigger project
Depending on the shape of your role, something in one of these categories is usually worth starting around day 90:
- Active Directory / identity hygiene and cleanup
- An internal automation platform (n8n or similar) for repetitive workflows
- A knowledge base / self-service portal
- A proper monitoring and alerting setup
- A security-hardening cycle (MFA rollout, endpoint protection, patch management)
Pick one. Scope it to 60–90 days of elapsed time (not full-time work). Ship it before you take on the next big thing.
What to NOT Touch in the First 100 Days
Some things look tempting, but the blast radius is wrong for someone still new:
- Anyone's permissions. Even if the access sprawl is objectively bad, restricting access without full context burns trust fast.
- Migrations of active systems. Don't migrate email, file shares, or identity providers before you fully understand the dependencies. Plan them in month three, execute in month six.
- Vendor relationships. Don't cancel contracts, renegotiate pricing, or fire vendors in your first quarter. You don't know what they're really doing yet.
- Organisational structure. If you're managing a team, resist reorganising it. Watch how the existing shape works, then decide.
- Anyone else's tools. If the sales team loves a CRM you think is bad, that's a month-six conversation, not a week-three one.
The One Document to Keep Updated
Beyond everything above, start and maintain a personal working log from day one. A single file — Notion page, Markdown doc, Google Doc — with daily or weekly notes on:
- What I worked on
- What I learned
- Who I met and what they said
- Open questions I owe someone an answer on
- Things I want to revisit in 30 days
This doc will do more for your career than any LinkedIn update. It compounds into pay-review ammunition, promotion narratives, and — when you eventually leave — the best reference material for the next person.
What Compounds from Here
The first 100 days are an investment, not a return. If you've used them well, what you get on day 101 is permission — to propose, to scope, to ship, to lead. If you've used them poorly, you'll spend months of day-101-onwards wishing you'd listened longer at the start.
The teams that trust you fastest are the ones you demonstrated humility with in the first month and competence with in the second. Get the order right and the rest of the tenure takes care of itself.
Starting Somewhere New Soon?
If you're 2 weeks into a new role and want to compare notes on your listening-tour findings, drop me a line. Happy to look at a sketch of what you're walking into and point out where the mines usually are.
Comments