The New Engineering Leader's 90-Day Roadmap
Your first 90 days are less about writing code and more about building trust, identifying bottlenecks, and preventing what some call "organ rejection" of your leadership. Move too fast and the team pushes back. Move too slow and stakeholders lose confidence. Here's a phased playbook that balances both.
Phase 1: Days 1–30 — The Listening Tour
Don't change anything yet. Your goal is to map the hidden architecture of the team — the informal power structures, the unwritten rules, the pain that doesn't show up in dashboards.
Run 1:1s with everyone. Ask three questions: what's working, what's frustrating, and if they were in your shoes, what would they fix first. The patterns that emerge across multiple conversations are more valuable than any metric.
Audit the developer experience. How long does it take to go from a fresh laptop to a running development environment? If the answer is more than half a day, you've found your first quick win. Developer onboarding friction is one of the most reliable indicators of broader practice health.
Identify the glue people. Find the engineers doing the unrewarded work — mentoring juniors, writing documentation, triaging bugs, maintaining shared tooling. These people hold the team together and they're usually the most underrecognised. They're also your most important allies.
Review the on-call rotation. Frequent midnight pages are a leading indicator of both technical debt and morale problems. If the same three people absorb all the incidents, you're looking at burnout risk that will surface as attrition within six months.
Phase 2: Days 31–60 — The Diagnostic
Start correlating what you heard with what the data shows. Qualitative insight plus quantitative evidence is how you build a credible case for change.
Analyse cycle time. Where do tickets stall? Stuck in code review for three days? Waiting on QA for a week? Blocked on a single approver? Cycle time bottlenecks reveal process problems that people have learned to live with.
Assess technical debt. Ask the team for their wall of shame — the legacy systems everyone is afraid to touch. Rank these by risk and business impact, not just engineering preference. The debt that threatens a compliance deadline or a revenue milestone gets priority over the debt that just annoys developers.
Test mission alignment. Ask three random engineers what the team's top priority is this quarter. If you get three different answers, you have a communication gap that no amount of process improvement will fix until it's closed.
Ship something small. Put your name on a pull request or a minor release. It demonstrates that you understand the team's workflow from the inside, not just from a dashboard. Engineering teams respect leaders who can still get their hands dirty.
Phase 3: Days 61–90 — The Strategic Shift
By now you have context, credibility, and political capital. Time to spend it wisely.
Execute a quick win. Fix a nagging pain point identified in Phase 1. Upgrade the slow CI/CD pipeline. Kill the useless recurring meeting everyone complains about. The specific action matters less than the signal: you listened, and you acted.
Define what done means. Formalise what quality looks like for your team. Does "done" mean code that passed tests, or code running in production with monitoring? The gap between these definitions is where quality escapes hide.
Set the AI baseline. Determine how the team is using AI coding assistants today. Standardise tooling, establish review expectations for AI-generated code, and ensure security practices haven't been quietly bypassed in the name of velocity.
Present your roadmap. Share your six-month vision with both the team and stakeholders. Be explicit about what you're stopping as much as what you're starting. Teams trust leaders who can say no to things.
Red Flags to Avoid
The "back in my day" trap. Comparing everything to your previous company breeds resentment. Every team has its own context. Use your experience to ask better questions, not to impose old answers.
The hero complex. Don't personally fix the biggest technical problem. Your job is to enable the team to fix it. Taking the heroic PR yourself sends the message that you don't trust them.
Changing tools too fast. Swapping Jira for Linear in week two — or vice versa — is a recipe for chaos. Tooling changes are disruptive even when they're improvements. Earn trust first.
Measuring Your Starting Point
The listening tour and diagnostic phases work best when you have an objective baseline to anchor them. Practice-level data — covering testing, release, security, documentation, and review practices across the team — gives you the evidence to separate real problems from squeaky wheels, and to track whether your changes are actually moving the needle.