The First 90 Days as a Technical Leader

I've started new leadership roles several times. Head of Engineering. VP of Product. Technical Director. Each time, the temptation is the same:

"I see the problems. Let me fix them."

This is wrong. The first 90 days aren't for fixing. They're for understanding.

The Trap

New leaders often:

• Announce changes in week 2
• Reorganize teams by month 1
• Start big initiatives before understanding context
• Optimize for looking decisive

The result: changes that don't stick, trust that doesn't form, context you never acquire.

The team has been there longer than you. They know things you don't. Acting before understanding wastes that knowledge.

Month 1: Listen

Talk to Everyone

Schedule 1:1s with:

• Every direct report (obviously)
• Skip-levels (their direct reports)
• Key stakeholders outside your org
• Anyone the team suggests

(For making these 1:1s effective, see Running Effective One-on-Ones.)

Questions I ask:

• What's working well that I should protect?
• What's broken that I should know about?
• What would you do if you were in my role?
• What's one thing you wish leadership understood?
• What do you need from me to be successful?

Take notes. Look for patterns. Don't commit to anything yet.

Understand the Business

Before you can lead technically, you need to understand:

• How does the company make money?
• What are the strategic priorities?
• Who are the key customers and what do they need?
• What's the competitive landscape?
• What constraints exist (budget, headcount, timeline)?

Technical decisions without business context are just opinions.

Map the System

Both the technical system and the human system:

Technical:

• What's the architecture?
• Where are the pain points?
• What's the deployment process?
• Where are the risks?

Human:

• Who are the key people?
• Who has influence?
• Where are the tensions?
• What's the culture like?

Draw diagrams. Literally. It forces clarity.

Month 2: Diagnose

Find the Real Problems

By now you've heard a lot. Time to synthesize.

What I look for:

• Themes that came up multiple times
• Contradictions between what different people said
• Gaps between stated priorities and actual behavior
• Disconnects between teams

Often the presenting problem isn't the real problem. "We need to rewrite the backend" might actually be "teams can't collaborate" or "there's no shared understanding of requirements."

Quick Wins

Identify 2-3 things you can improve quickly with low risk:

• Remove an annoying process
• Fix an obvious pain point
• Unblock something that's been stuck

These build credibility. They show you're paying attention. They're not the main event, but they matter.

Start Forming Hypotheses

What changes would make the biggest impact?

Don't announce these. Test them in conversations. "I'm wondering if X might help with Y. What do you think?"

Listen to the reactions. Refine the hypotheses.

Month 3: Act (Carefully)

Prioritize

You can't fix everything. Pick 2-3 priorities for your first major push:

• High impact
• Achievable within your authority
• Won't break things if you're wrong

Write them down. Share them. Get buy-in before executing.

Build Alignment

Before making changes (see Stakeholder Management for Technical Leaders):

• Get your boss aligned
• Get your peers informed
• Get your team bought in

Decisions made in isolation fail. Even good decisions.

Execute Incrementally

Don't reorganize the whole department at once. Don't launch five initiatives simultaneously.

Start small. Prove the approach. Expand.

If you're wrong, small mistakes are recoverable. Big mistakes are career-limiting.

What I Actually Did

In my last role transition:

Week 1-2: Met with 15+ people. Took a lot of notes. Said very little.

Week 3-4: Reviewed architecture docs, deployment processes, incident history. Identified 3 recurring themes in conversations.

Week 5-6: Proposed one process change (how we prioritize work). Small scope, reversible. Got feedback, refined it, implemented.

Week 7-8: Started deeper diagnosis of architecture issues. Formed working group, didn't mandate solutions.

Week 9-12: Rolled out first significant change (team structure adjustment). Heavily socialized first. Adjusted based on feedback.

After 90 days: Had credibility, context, and a prioritized list of what to tackle next.

Common Mistakes

Moving too fast. Making changes before you understand why things are the way they are.

Moving too slow. Analysis paralysis. At some point, you need to act.

Ignoring politics. Every organization has them. Pretending otherwise doesn't make them go away.

Promising too much. You don't know what you can deliver yet. Underpromise.

Fixing symptoms. The obvious problem is rarely the root cause.

Bringing old playbook. What worked at your last company might not work here.

The Meta-Lesson

The first 90 days set the tone. If you come in swinging, you'll be seen as someone who doesn't listen. If you come in learning, you'll be seen as someone who's thoughtful.

That perception sticks.

---

Your job in the first 90 days isn't to prove you're smart. It's to understand the system well enough to make changes that actually work. Listen more than you talk. Observe before you judge. Act only when you're ready.