Welcome to work. Here’s your laptop and all your logins.
If only it were that easy.
When Scott Loftesness became an engineering manager at Twitter, he inherited a high-visibility project with a single mandate: ship it. He asked for more engineers and pushed forward. Then a new hire asked a few basic questions about the project's purpose — and the team realized they'd built the wrong product entirely. The project was cancelled.
Loftesness had the experience, the technical credibility, and the drive. What he didn't have was enough context — and he moved before he'd built it.
You were hired because you have that experience (or something close to it), but you know the work is more complex than copy-pasting what’s worked elsewhere. Tools and frameworks, such as DORA and SPACE, don’t sweep aside the systemic problems waiting for you. The challenge is sociotechnical, and you know the “socio” part comes first.
That was true before. It's especially true now. Engineering leaders stepping into new roles in 2026 are walking into a different kind of pressure: boards demanding AI ROI, headcounts thinned by layoffs, and an implicit question from leadership that never quite gets asked directly — can you prove your team's value before your first review?
The 90-day clock used to give you room to learn. Now, the expectation is that you're learning and delivering a narrative at the same time.
So before you identify concrete goals, ask yourself the first question — the one for you, not your team: What are you in it for? If you’re in it to hammer through new ideas for two years, build your resume, and bounce, then stop reading this article – go do that.
But if you want to build a legacy and make positive change that will last beyond your tenure, then you need to think about how your early work enables your future work. Your first 90 days are how you sow the seeds to success you’ll reap much later.
Clarify your direction
The most dangerous impulse in the first 90 days is momentum. You'll see problems immediately. Some of them will be obvious. The temptation to act on that clarity is strong — and it's almost always the wrong call. The biggest mistake a new leader can make is disrupting current systems of execution before having a working alternative.
Your first job is to build the conditions for good decision-making, not to make decisions yet. That means figuring out what information you need, how you'll gather it, and what you're actually trying to learn. As you compile it, form early hypotheses. Test them. Identify checkpoints and decide in advance how you'll react to different outcomes.
None of this is glamorous work. But it's the difference between making a move with a map and making one in the dark.
One more thing worth naming: surveys of engineering managers have found that only about one in fifteen received any formal management training before stepping into the role, and nearly 75% said their primary learning method was trial and error.
That context matters. The people around you — your peers, your reports, the leaders above you — are also largely self-taught. The organization's accumulated habits, including the bad ones, came from somewhere. Assume there's a reason before you assume there's a flaw.
Measure what matters in your first 90 days
See how Uplevel's WAVE framework helps new engineering leaders establish baselines across Ways of Working, Alignment, Velocity, and Environment Efficiency.
.png)
Build credibility like a scarce resource
Credibility is cash, and in the first 90 days you have almost none of it yet. The hiring committee trusted you enough to make an offer. Your team respects your background. That's not the same as credibility — that's credit. And credit runs out fast if you spend it wrong.
The quality of your work and the way you treat people will build real credibility, but that takes time. Until then, there are more ways to lose it than earn it. The loudest or most visible groups in your first few weeks may not be your most important stakeholders. The quiet, initially skeptical ones often turn out to be your most valuable allies.
In other words, don't piss anyone off in your first 90 days.
One common early trap is ignoring upward communication while you're focused on getting to know the team. Assuming leadership will just "get it" is a mistake — they usually don't. Managing up means proactively sharing your team's wins, challenges, and needs with your manager and stakeholders. Visibility upward isn't self-promotion. It's how you secure the support your team will eventually need.
Your Top Five Priorities
Your priorities in the first 90 days connect to and enable the priorities that will last throughout your tenure. Chief among these is building a learning organization: All of your work, in the first week, the next quarter, and three years from now, should ladder up to this goal.
Early on, however, that goal won’t always feel so lofty. Early on, the work is proving that change is possible at all.
Remember, the system is an organism, and the system has had a life apart from you for a long time. It’s learned lessons (not all of them good ones). Teach the organizational organism that it can evolve, and not just lurch from OKR to KPI to new OKR and back again. People – the cells that comprise the system – need to feel like their voices matter, that they can accumulate and eventually lead to change.
1. Run 360-degree interviews
Talk to people up and down the organization, and across departments — not just engineering. Finance, product, and internal IT will each have a different picture of what engineering does and doesn't deliver. Junior engineers will tell you things their managers won't. Leaders in other functions will tell you things engineering has stopped noticing.
Pay particular attention to your platform team. They'll have the clearest view of organizational maturity, though that view cuts both ways: engineers may claim to have CI/CD while the platform team knows how effective it actually is — and the platform team may overstate their system's maturity while the people using it have a completely different experience. Listen to both, and triangulate.
2. Audit the processes that came before you
The processes that underpin good software development aren't radically novel. Your goal isn't to invent new ones — it's to understand why the effective ones haven't taken hold here. Every organization that hasn't implemented a good process has a reason. Find it.
The most useful question is: how long does it take to get from an idea to a product in a customer's hand? Don't accept a quick answer. The gap between "we ship every day" and the actual number is often where the real story lives.
When you find resistance to a process change, dig into the history. A team that insists on manual releases may have good reasons rooted in a specific incident. Validate the concern, then keep digging — because the lesson they drew may have solved the wrong problem.
3. Build feedback mechanisms early
Every change you make should generate feedback that shapes the next change. Set this up from the start, even in a lightweight form.
Keep expectations around feedback clear. Because you're new, people can feel entitled to immediate responses once they've spoken up. Use data to help you calibrate whose feedback is most relevant, and be transparent about how you're filtering it. Questions like how will we know if this change is working? and when will we revisit it? signal that you're making decisions systematically, not by instinct or fiat.
Useful feedback combines the quantitative and qualitative — platform metrics alongside pulse surveys, for example. Neither alone gives you the full picture.
4. Look for leverage points
Donella Meadows defines leverage points as "places within a complex system where a small shift in one thing can produce big changes in everything." The first 90 days are for finding them, not pulling them.
Quick wins show progress, but they rarely move the system. Leverage points are different — they align with existing organizational priorities and, over time, generate real change. The counterintuitive move is to find where your goals and the organization's existing goals already overlap, and work there first. Enable the organization to succeed at what it's already been trying — and failing — to achieve.
5. Create the conditions for debate and decision-making
Engineers want to engage with the "why" behind decisions. There is almost always a reason the current processes exist, even the bad ones, and learning those reasons before you challenge them will save you more political capital than almost anything else.
Set up decision-making frameworks early — an impact/effort matrix, an OKR structure, a six-pager process. The specific format matters less than establishing a repeatable way to have structured conversations. You want people to be comfortable giving you feedback long after the first 90 days are over, and that habit starts now.
Building feedback loops requires the right data
Uplevel combines engineering metrics with team sentiment to give you the full picture behind the numbers.
What to Watch Out for
Your first 90 days are precious. As you pursue your top goals, there will be many temptations to distract you along the way. Don’t fall for them.
The political game is real — play it
Engineering leadership is always political. As a new leader, you'll encounter decisions that don't make sense yet, or ones that make all too much sense once you understand the baggage behind them. The instinct to push back on the dysfunction immediately is understandable. Resist it. Learn how the game works before you try to change it.
The loudest voices are rarely the most important
Internal change tends to follow the Innovation Adoption Curve. The innovators are already on board. Focus on the early adopters and the early majority — they'll carry the organization. The loudest skeptics will absorb the most time for the least return. Let the momentum you build with others do the work.
Old metrics are evidence, not enemies
Organizations resist changes to their measurement systems even when they say they want transformation. Work with existing metrics that align with your goals rather than trying to replace everything at once. Using the current metrics is, paradoxically, often the fastest path to exposing their limitations — and building the case for better ones.
Verify everything
Listen to everyone. Believe nothing without checking. Ask whether they have CI/CD. Then find out what they mean by that. Your outside perspective is an asset precisely because you'll see things they've stopped seeing. Use that lens carefully, but use it.
What are their unknown unknowns?
Regroup and Try, Try Again
Organizational change is a systemic problem, and you have to prepare for resistance. The system has been running without you for a long time and it has its own immune response to change. Move too fast and it will reject the change — even the right change.
When an idea doesn't land, the idea is usually fine. The packaging is often the problem. Be ready to try the same thing differently until it clicks.
Your first 90 days are the proving grounds for the next five years. Every step you take could fail. If you fail with attention and honesty, the failures teach you what the successes couldn't.
