Your First 90 Days as a Technical Manager: What Actually Matters (And What Doesn't)
Day One: Everything You Thought You Knew Is Wrong
The promotion email arrives. You're now the Network Engineering Manager. You've been a senior engineer for years. You know the technology deeply. You know the team. You know the environment.
You think you're ready.
Day one as a manager, you discover:
The job is nothing like you expected. The skills that made you a great engineer don't translate the way you thought they would. The problems you need to solve aren't the ones you prepared for.
What you expected to spend time on:
Technical architecture decisions
Solving complex technical problems
Mentoring engineers on technical topics
Strategic technical planning
What you actually spend time on:
Navigating organizational politics
Managing people's emotions and conflicts
Explaining to leadership why your team isn't the problem
Budget planning for things that won't happen for 18 months
Convincing team members to change approaches they've used for years
The realization that hits around week two:
The technical challenges are actually the easy part. You can solve technical problems. You've been doing that for years.
The hard part - the part nobody prepared you for - is the people.
Coming up on a year in management, here's what actually mattered in the first 90 days, what I wish I'd known, and what I'd do differently if I could start over.
The Hardest Truth: People Problems Are Harder Than Technical Problems
This was the biggest surprise.
Technical Problems Have Solutions
Technical problem pattern:
Network outage: troubleshoot systematically, find the root cause, and fix it
Performance issue: gather data, identify bottleneck, optimize
Design challenge: evaluate options, select approach, implement
There's a path. There's methodology. There's a solution.
You might not know the solution immediately, but you know how to find it. You can learn. You can research. You can test.
Technical problems are bounded and solvable.
People Problems Don't Work That Way
People problem pattern:
Two team members are in conflict. They're both excellent engineers. They both contribute significantly. But they can't work together effectively.
What you try:
Talk to each separately → They both think the other is the problem
Bring them together → Awkward, surface-level agreement, nothing actually changes
Set clear expectations → They comply minimally, but tension remains
Try different project assignments → Works temporarily, but the underlying issue persists
There's no clear solution. There's no troubleshooting methodology. There's no "fix."
Just navigation, management, and accepting that some problems don't get solved - they get managed.
This is uncomfortable for technical people.
We're trained to solve problems. "Managing but not solving" feels like failure.
The People Challenges That Blindsided Me
Scenario 1: The Conflict You Inherited
Two engineers who've worked together for years have a long-standing tension. You didn't create it. It predates you. But now it's your problem.
You can't fix history. You can only manage forward.
Scenario 2: The Performance Issue That's Actually a Personal Issue
An engineer's performance has declined. Through careful conversation, you learn they're going through a divorce, dealing with a sick parent, or struggling with mental health.
You're not a therapist. But you're responsible for their performance and their well-being.
The line between compassion and accountability is fuzzy, and you're navigating it for the first time.
Scenario 3: The Team Member Resistant to Any Change
"We've always done it this way. Why change now?"
You can't force someone to embrace change. You can mandate compliance, but you can't mandate enthusiasm.
Technical problems respond to logic and data. People don't always work that way.
Scenario 4: The Feedback That Goes Badly
You give constructive feedback that seems straightforward to you. The engineer takes it as severe criticism, becomes defensive, or, worse, disengages entirely.
You thought you were helping. You damaged the relationship instead.
What I've learned:
People problems require different skills from technical problems:
Emotional intelligence over technical intelligence
Patience over decisiveness
Ambiguity tolerance over need for clear answers
Long-term relationship building over quick fixes
These skills take time to develop. Give yourself grace as you learn them.
"The people side of management connects to When Good Engineers Become Managers - the skills that made you successful as an engineer often don't transfer to managing people.
What Nobody Tells You: You're Now the Team's Shield (And the Organizational Punching Bag)
The Blame That Flows Downhill (And Stops at You)
Week three, you're in a leadership meeting:
"The network upgrade project is behind schedule. What's going on with the network team?"
The reality:
The security team delayed firewall policy changes by 3 weeks
Facilities didn't run the fiber on the promised timeline
The vendor delivered the equipment late
Your team did their part. They're ready. They're waiting on everyone else.
What you want to say:
"My team isn't the problem. Security, facilities, and the vendor are all delayed. We're blocked waiting on dependencies we don't control."
What happens if you say that:
You look like you're making excuses and blaming other teams. Leadership hears "network team can't manage dependencies."
What you learn to say:
"We're blocked on several dependencies. I'm working with security and facilities to expedite, and I'm escalating the vendor delay. Current ETA is [date] assuming we get unblocked by [specific milestones]."
What you're actually doing:
Taking responsibility for outcomes you don't fully control. Protecting your team from blame while navigating organizational complexity.
This happens constantly.
The Attribution Problem
When things go well:
Leadership rarely asks which specific team made it happen. Success is broadly attributed to the organization.
When things go wrong:
Leadership wants to know specifically who's responsible. Blame gets attributed to specific teams.
The asymmetry:
Your team shares credit for success but carries specific blame for failures - even when failures aren't their fault.
Your job:
Absorb the blame. Shield your team. Advocate for them while navigating organizational politics.
The Invisible Work of Advocacy
What advocacy actually looks like:
In budget meetings: "My team needs [resource]. Here's the business impact of not having it: [specific consequences]. This is high priority because [business justification]."
When someone questions the request, you defend it, often repeatedly, across multiple meetings.
In organizational discussions:
Your team isn't in the room. Other managers are pushing their priorities. You're ensuring your team's needs are heard and considered.
In incident reviews:
Preventing the narrative from becoming "network team caused this" when systemic issues allowed an individual mistake to have large impact.
In performance calibrations:
Fighting for your team members to be rated fairly when other managers are fighting for their teams.
What this costs:
Political capital, energy, and sometimes being seen as "difficult" for pushing back on narratives that unfairly blame your team.
What you learn:
Your team will never fully see how often you advocate for them. The best advocacy is invisible - problems that never reach them because you handled them upstream.
But they'll definitely notice if you don't advocate for them.
The Emotional Labor Nobody Mentions
You're managing everyone's emotions:
Team members stressed about project deadlines
Engineers frustrated with organizational decisions
Individuals dealing with performance concerns
Leadership is anxious about the project status
While suppressing your own:
You can't vent to your team about leadership decisions. You can't vent to leadership about team frustrations. You're processing everyone's stress while finding other outlets for your own.
This is exhausting in ways technical work never was.
The emotional labor and isolation of management were explored in Both Sides of the Desk: Burnout (Manager's Perspective), which starts in the first 90 days.
The Budget Surprises: Planning for Things You Can't See Yet
The Timeline Problem
Month one: You're focused on learning your team, understanding current projects, and building relationships.
Month two: Someone mentions, "Budget season is coming up."
Month three: "We need your budget requests for next fiscal year by the end of the month."
Panic: Next fiscal year? That starts in 4 months. I barely understand the current fiscal year.
The expectation:
You're supposed to forecast what equipment, tools, headcount, and projects you'll need 12-18 months from now.
The problem:
You've been in this role for 90 days. You don't fully understand the current state, let alone what you'll need 18 months from now.
What Nobody Teaches You About Budgeting
Budget planning requires thinking about:
Equipment lifecycle: "This switch is 6 years old now. It'll be 7-8 years old next fiscal year. We should probably budget for replacement even though it's working fine today."
How do you know this? You have to inventory what you have, research lifecycle expectations, and forecast failures you can't predict.
Project pipeline:
"We'll probably want to do SD-WAN migration in 18 months. That requires budget for equipment, licensing, and potentially consulting."
How do you know this? You have to understand organizational strategy, technology trends, and what makes sense for your environment - all while still learning your current environment.
Headcount planning:
"If we grow 20% next year, we'll need another network engineer by Q3."
How do you forecast growth impact on your team? You barely understand the current team capacity.
Vendor renewals:
"These licenses renew in Q3 next year. They'll probably increase 5-10%. We need to budget for that."
How do you know what renews when? You have to find all the contracts, understand renewal terms, and predict price increases.
What I Wish Someone Had Told Me
Week one priority:
Inventory everything that will require a budget:
Equipment and age (replacement cycles)
Software licenses and renewal dates
Vendor contracts and terms
Current team capacity and growth projections
This feels premature when you're just trying to understand your team.
But budget season comes fast. And you'll be scrambling if you don't start early.
The other thing I learned:
Ask your boss or finance for last year's budget and actuals. This is your baseline. You're not starting from zero - you're adjusting from last year.
And the political reality:
Your first budget request will probably get cut. Plan for that. Request more than you absolutely need so you have room to negotiate.
The budget planning challenge connects directly to Your First IT Budget: A Survival Guide - this is what you're preparing for in your first 90 days, even if budget season hasn't started yet.
Changing Team Dynamics When People Are "Stuck in Their Ways"
The Situation You Inherit
You become the manager of a team that's been working the same way for years. Some things work well. Some things need to change.
The team members who've been here for 10+ years:
They know the environment intimately. They're experts in your infrastructure. They're also deeply set in their patterns.
What you want to change:
Documentation approach (currently inconsistent or minimal)
Change management process (currently loose or ad-hoc)
Knowledge sharing (currently siloed in individuals)
Automation adoption (currently resistant to)
Response to incidents (currently reactive, needs to be more proactive)
What you encounter:
"We've always done it this way." "That won't work here because [reason from 5 years ago that may no longer apply]." "We tried that before and it failed." "If it's not broken, why fix it?"
Your authority says, "We're doing it this way now."
Your effectiveness says: "I need buy-in, not just compliance."
What Doesn't Work
Approach 1: Mandate change immediately
"Starting Monday, everyone will document all changes in the new format.
Result: Minimal compliance, resentment, passive resistance, change dies within weeks.
Approach 2: Wait for people to come around naturally
"I'll lead by example and hope they follow eventually."
Result: Months pass, nothing changes, you look ineffective.
Approach 3: Explain exhaustively why change is needed
"Let me give you a 30-minute presentation on why this new approach is better."
Result: The current approach doesn't overcome habit and comfort.
What Actually Works (Slowly)
Strategy 1: Start with "why" but keep it short
Don't just mandate. Explain the business reason concisely:
"We're getting audited next quarter, and we need documented change management. This isn't optional, but I want your input on how we make it work."
Then actually listen to their input. They know things you don't about why previous attempts failed.
Strategy 2: Identify your champions
Not everyone resists change equally. Some people are more open to new approaches.
Find those people. Empower them. Make them visible.
When they adopt the new approach, and it works, their peers notice.
Peer influence is more powerful than manager mandate.
Strategy 3: Make the new way easier than the old way
Example:
Old way: Manual configuration backups to shared drive (familiar, low friction)
New way: Automated backups to repository (unfamiliar, high friction)
Why people resist: A new way is harder, at least initially.
What works: Reduce friction for the new way, increase friction for the old way.
Create templates that make a new way fast
Automate parts of the new process
Make the old way require extra steps (approval, documentation, justification)
When a new way is easier, people adopt it.
Strategy 4: Small wins before big changes
Don't try to change everything at once. Pick one thing. Make it work. Build credibility.
Then tackle the next thing.
Change fatigue is real. Pace your changes based on the team's capacity to absorb them.
Strategy 5: Acknowledge and address the real resistance
Often, resistance isn't about the change itself. It's about:
Fear of looking incompetent with new tools
Worry that change means current skills become less valuable
Anxiety about the additional workload
Loss of autonomy and control
Address these underlying concerns directly:
"I know this new process feels like extra work. I'm not asking you to work harder - I'm asking you to work differently. If this genuinely creates more work without value, tell me, and we'll adjust."
What I learned:
You can't force culture change in 90 days. You can start the process. You can make early progress. But real change takes 6-12 months.
Be patient while being persistent.
Changing team culture and overcoming resistance was explored in depth in Changing Culture as a New Manager - this is what you start in the first 90 days but takes much longer to complete.
What Actually Matters in the First 90 Days (Priority Order)
Looking back, here's what actually mattered vs. what I thought would matter:
Priority 1: Build Relationships (More Important Than I Thought)
With your team:
One-on-ones with each person within the first two weeks. Not just "getting to know you" - understanding:
What they're working on
What frustrates them
What they want to learn
How they prefer to be managed
What concerns they have about the transition
With peer managers:
You need these relationships. You'll constantly depend on other teams. Start building collaborative relationships before you need to ask for favors.
With your boss:
Understand their expectations, communication preferences, and how they'll evaluate your success.
With key stakeholders:
Who are the critical people outside your chain who affect your team's success? Meet them early.
Why this matters more than I expected:
Everything else you need to do requires relationships. Technical skills matter, but relationship capital enables everything.
Priority 2: Understand Current State (Before Changing Anything)
What I wanted to do:
Fix obvious problems immediately. Show I could add value fast.
What I should have done:
Observe for 30-60 days before making significant changes.
Why:
Things that look broken often have context. "Why do we do it this weird way?" often has an answer that's not obvious until you understand the history.
Change without understanding creates more problems than it solves.
Priority 3: Establish Your Management Operating Rhythm
What this means:
How often are 1-on-1s? (Weekly? Biweekly?)
How do you track work and priorities?
What's your team meeting cadence and format?
How do people escalate issues to you?
How do you communicate decisions and changes?
Why it matters:
This structure is your management foundation. Get it right early.
What I learned:
Changing this later is harder than establishing it correctly from the start.
Priority 4: Understand the Budget and Resource Situation
Even if budget season isn't imminent:
What's your current budget?
What's already committed vs. discretionary?
What renewals are coming?
What equipment is aging and needs replacement?
What's your hiring headcount?
Why it matters:
You can't make informed decisions without understanding resource constraints.
Priority 5: Identify Quick Wins (But Don't Force Them)
What worked:
Finding small, low-risk improvements that deliver visible value.
Example from my experience:
Set up Cisco ThousandEyes to monitor a few business-critical public-facing websites. They’ve even caught a Microsoft 365 outage or two
What didn't work:
Trying to force a "quick win" that turned out to be more complex than I realized. (See: every blog post I've written about failed initiatives.)
The balance:
Look for quick wins, but don't manufacture them. Better to have no quick wins than a quick failure.
Priority 6: Learn the Political Landscape
What I mean:
Who has influence beyond their org chart position?
What are the organizational sacred cows (things you can't change)?
What initiatives have leadership support vs. just existing?
Where are the landmines (topics or decisions that ended badly for others)?
This isn't taught. You learn it by observing, listening, and occasionally stepping on landmines.
Why it matters:
Technical excellence doesn't overcome political tone-deafness. You need both.
What Can Actually Wait (Don't Try to Do Everything)
These things felt urgent but could wait:
Big Process Changes
What I wanted to do: Overhaul documentation, network architecture, and automation practices in the first month.
What I should have done: Observed current state, understood why it exists, built relationships, THEN proposed changes with team input.
Lesson: Process changes require buy-in. Buy-in requires trust. Trust takes time.
Organizational Influence
What I wanted: Credibility and immediate influence in leadership meetings.
Reality: You earn influence through demonstrated competence over time, not through title.
What worked: Delivering on commitments, being reliable with information, adding value when appropriate, and staying quiet when I didn't have expertise.
Solving Every Problem
What I wanted: Fix everything my team complained about.
Reality: Some problems are organizational and outside your control. Some are low priority. Some aren't actually problems, just preferences.
What worked: Prioritizing what actually matters and being honest about what I can't change.
Technical Deep Dives
What I wanted: Maintain deep technical expertise across the board.
Reality: Your role is broader now. You can't be the technical expert in every area anymore.
What worked: Staying technically credible while accepting that team members will know more than me in specialized areas.
The Mindset Shifts That Take Longer Than 90 Days
These are still works in progress for me:
From "What Can I Do?" to "What Should I Enable Others to Do?"
Old mindset: "I can solve that problem faster/better myself."
New mindset: "How do I develop someone else to solve this so they grow and I'm not a bottleneck?"
This is hard. Watching someone struggle with something you could fix in 5 minutes is uncomfortable.
From "Being Right" to "Getting to the Right Answer"
Old mindset: "Here's the right technical approach based on my expertise."
New mindset: "Here's what I'm thinking. What am I missing? What are the trade-offs?"
Being right matters less than getting your team to the right answer together.
From Execution to Enablement
Old mindset: Success = what I personally delivered.
New mindset: Success = what my team delivered.
Your output is now your team's output. This is a fundamental identity shift.
From Certainty to Ambiguity Tolerance
Old mindset: Technical problems have right answers. Find them.
New mindset: People and organizational problems often don't have "right" answers. Navigate them.
Accepting ambiguity is uncomfortable for technical people. We like definitive solutions.
What I'd Do Differently (Knowing What I Know Now)
I'd Ask More Questions
What I did: Tried to prove I knew the answers.
What I'd do: Ask more questions of my team, peers, and boss. "Help me understand..." is powerful.
Why: I learned more from questions than from showing expertise.
I'd Wait Longer Before Making Big Changes
What I did: Proposed changes in week 3.
What I'd do: Observe for 60 days, understand context, THEN propose changes with team input.
Why: Some of my "obviously broken" things had context I didn't understand.
I'd Build More Peer Relationships Earlier
What I did: Focused primarily on my team and my boss.
What I'd do: Invest more time in relationships with peer managers from day one.
Why: So much of success depends on these relationships. I undervalued them.
I'd Be More Honest About Not Knowing
What I did: Tried to have answers to everything.
What I'd do: "I don't know, let me find out" or "I'm still learning that area."
Why: Pretending to know more than I did damaged my credibility when I was wrong. Honesty builds trust.
I'd Protect Time for Strategic Thinking
What I did: Let the calendar fill with meetings and reactive work.
What I'd do: Block time weekly for strategic thinking, planning, and reflection.
Why: The urgent always crowds out the important unless you protect time for it.
I'd Find a Peer Support Network Faster
What I did: Tried to figure everything out myself.
What I'd do: Connect with other new managers earlier for peer support.
Why: Talking to others going through the same transition normalized the struggle and provided practical advice.
The Bottom Line: The First 90 Days Are About Learning, Not Proving
Here's what becomes clear after nearly a year in the role:
The first 90 days aren't about proving you deserve the role. They're about learning a completely different job while everyone watches.
The technical skills that got you promoted matter less than you think. People skills, political navigation, and organizational understanding matter more than you think.
You will be uncomfortable. You're a beginner again in many ways. That's normal, not failure.
Relationships matter more than you realize. Build them intentionally, early, and across the organization.
People problems are harder than technical problems. There's no troubleshooting methodology for personality conflicts or resistance to change.
You're now the shield for your team. You'll absorb blame, advocate in invisible ways, and protect them from organizational chaos.
Budget planning requires thinking further ahead than feels possible. Start early, even when it feels premature.
Change takes longer than 90 days. Start the process, but don't expect transformation in three months.
What actually matters:
Build relationships (team, peers, boss, stakeholders)
Understand the current state before changing it
Establish your management operating rhythm
Learn the budget and resource landscape
Find quick wins without forcing them
Map the political landscape
What can wait:
Big process overhauls
Organizational influence (this gets earned)
Solving every problem
Deep technical expertise in everything
The mindset shifts are ongoing:
From doing to enabling
From being right to getting the right answers
From execution to enablement
From certainty to ambiguity tolerance
What I wish I'd known:
This is supposed to be hard. You're learning a new job. The discomfort means you're growing, not failing.
Give yourself grace. Ask for help. Learn from mistakes.
The first 90 days are just the beginning. You're not supposed to have it all figured out yet
You're doing better than you think.
📧 Starting your first management role or in your first year? Subscribe to my monthly newsletter for practical perspectives on the management transition, learning from early mistakes, and navigating the first year of technical leadership. First Tuesday of every month. Sign up here
What surprised you most in your first 90 days as a manager? What do you wish someone had told you? Share your experiences in the comments or connect with me on LinkedIn - we're all learning this transition together.
Disclaimer: The views and experiences shared in this blog are based on common patterns observed in the transition to technical management and do not represent any specific company, team, or individual.