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

Your biggest risk in the first 90 days isn't moving too slowly — it's moving on the wrong things because you haven't earned the context yet. The VP of Engineering seat is uniquely dangerous because you have enough technical credibility to form opinions fast, and enough positional authority that people won't push back when those opinions are premature.

Here's how I'd structure it:

Days 1–30: Listen Until It Hurts

Your only job is to build an accurate map of reality — the one nobody put in the interview deck.

With your manager (likely CTO or CEO): Get explicit on what success looks like at 90 days, 6 months, 12 months. Not vague ("improve velocity") — specific deliverables and metrics they'd point to. Misalignment here is the single highest-cost failure mode in the role [1].

With your directs and skip-levels: Run structured 1:1s with every engineering manager and as many ICs as you can. Three questions that consistently surface real signal:

• What's working that I should be careful not to break?
• What's the thing everyone knows is broken but nobody talks about?
• If you had my job for a day, what's the first thing you'd change?

With cross-functional peers (Product, Design, Sales, Support): Understand how engineering is experienced by the rest of the org. The gap between how eng sees itself and how others see it is usually where your biggest early wins live.

Don't do yet: Reorg, change processes, hire, fire, or introduce new tools. The temptation will be intense. Resist it.

At the end of 30 days, synthesize what you heard and reflect it back to the organization: "Here's what I'm seeing." This act alone — proving you listened before acting — builds more credibility than any early technical win [1].

Days 31–60: Align on the Real Problems

Now you have a map. Pressure-test it.

Pick the 2–3 problems that sit at the intersection of: what your manager cares about, what the team feels most acutely, and what cross-functional partners are experiencing. That intersection is where your early moves will get air cover and ground-level support.

Build alignment explicitly. Present your read of the problems to your manager and your direct reports. "Here's what I think the priority problems are. Here's why. Do we agree?" [1] This isn't consensus-seeking — it's making your reasoning legible so people can correct it or commit to it.

Set short-term goals that are specific enough to be falsifiable. Not "improve developer experience" — something like "reduce CI pipeline time from 45 minutes to under 15 by end of Q2" or "establish a clear on-call rotation that eliminates the current 3 AM hero culture." Align these with your manager's expectations for your first quarter [3].

Start making small, visible moves. Fix a broken meeting. Unblock a stuck project. Remove a process that everyone hates. These aren't transformational — they're proof that you convert listening into action [1].

Days 61–90: Execute on One Thing That Matters

You don't need a transformation. You need one credible proof point that the right person is in the seat.

Ship a change to how the team works — not a feature, a structural improvement. Maybe it's a new planning process, a reorg of a team that's been misaligned, a staffing decision you've now earned the context to make, or a technical investment the team has been begging for.

Start contributing your perspective in cross-functional settings. By now you should have enough context to represent engineering's interests credibly in product roadmap discussions, executive meetings, and resource allocation conversations [5].

Solicit explicit feedback from your manager and your directs. Not "how am I doing?" — ask specifically: "What should I do more of? What should I stop?" Be ready to hear things that sting. Your response to critical feedback in the first 90 days sets the tone for whether people will be honest with you for the next three years [5].

What I'd Stress-Test

This framework assumes you have reasonable organizational stability — that there isn't a crisis (major outage, mass attrition, failed launch) demanding immediate action. If there is, your "listening phase" compresses to about a week and you're in triage mode. The other assumption: your manager is aligned enough to give you 30 days before expecting visible output. If they're not, surface that tension in week one — because a boss who wants a reorg by day 15 and a team that needs you to listen for 30 days is a conflict only you can negotiate.

What's the situation you're walking into — greenfield team, turnaround, scaling, or something else? That changes which of these phases to compress or extend.