I'm a first-time VP of Engineering. What does the first 90 days actually look like?

The first 90 days as a VP of Engineering is less about shipping code and more about building the credibility to lead people who probably know the codebase better than you do. The trap most technical leaders fall into: defaulting to what made them successful as an IC or engineering manager — diving into architecture decisions, jumping into PRs, fixing the thing they can immediately see is broken. That's the wrong game at the VP level.

Here's how to structure the three phases:

Days 1–30: Listen before you conclude

Your primary job is intelligence gathering. Talk to every engineer, PM, designer, and cross-functional stakeholder you can reach. Not to impress them — to understand the actual system: what's slowing people down, where the technical debt really lives, what's broken in the org that no one's said out loud yet, and what your manager actually expects from you in the first six months [1].

A discipline that pays off: after your listening tour, synthesize what you heard and reflect it back to the organization — "Here's what I heard, here's what I think it means." [1] This signals that you were actually listening, not just checking a box, and it starts to build the trust you'll need to make changes later.

Set short-term, specific goals with your manager early — not the 12-month vision, but the 30-day version. What does success look like by Day 30? Align on that explicitly [3].

Days 30–60: Align on what matters

Once you have a picture of the landscape, bring a point of view. What are the two or three problems worth solving? What's the vision for the team six months from now? Get your manager and key stakeholders to pressure-test it — you're not announcing a strategy, you're getting alignment on the right problems before you commit to solutions [1].

This is also when you start going deeper on your direct reports: not just their technical judgment, but their ambitions, their frustrations, what they think the team needs. You'll start seeing where the gaps are.

Days 60–90: Start executing — selectively

Now you can act with credibility. Pick your first moves carefully. Broad organizational restructuring in month three is usually premature — you haven't seen the team under pressure yet. Better: a visible win that removes a real obstacle, a changed process that engineers immediately feel, or a hard conversation you didn't punt. The goal is to demonstrate that you're here to make the team better, not to make your mark [5].

This is also when you raise your hand for the things that matter — the roadmap conversation, the staffing ask, the technical direction debate. You've earned the standing to weigh in now [5].

The thing most new VPs underweight: your first 90 days sets the pattern for how people will bring you problems. If you make decisions too fast, they'll learn to bring you solutions, not problems. If you listen too long without acting, they'll stop believing you'll move. The cadence of "listen → align → move" repeated at the right pace is the actual job.

Michael Watkins' The First 90 Days is worth reading cover to cover before or during this window — his framework on diagnosing your situation (start-up vs. turnaround vs. sustaining vs. realignment) directly shapes which of the above you need to weight more heavily [6].

What's your starting context — are you inheriting a healthy team, a struggling one, or something in between? That changes the sequencing significantly.