Welcome to work. Here’s your laptop, and all your logins. Now, how are you going to transform the engineering organization, and as a result, the entire business surrounding 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. You know that tools and frameworks, such as DORA and SPACE, don’t sweep aside the systemic challenges that lie in wait. The problem at hand is sociotechnical, and you know the “socio” part comes first.
The first question is for you, however, not your reports: 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
Engineering leadership is all about navigating ambiguity, which is why we begin by providing directional clarity rather than offering absolute certainty. Before you identify concrete goals, think about the direction you’re working towards.
Plan to plan
You will soon meet some great engineers with some fascinating problems. Many will have great ideas and skills, and you’ll immediately see ways to help.
But you have to be careful with hands-on work. Now is not the time to make decisions about new tools, architecture, structures, or ways of working. This is important work, but little of it should happen in your first 90 days. Your prioritization truly has to be ruthless.
Your hands-on time is better spent getting in the trenches with engineers, listening to and learning about the challenges they face. You’re planning to plan, and all hands-on work must orient toward that.
Figure out what information you’re going to gather, how you’re going to gather it, and what you want to know. As you compile this information, determine early hypotheses and the directionality of your theories. With your goals established and your firsthand context in mind, determine your checkpoints and how you’ll react to different results along the way.
You’re setting up the blocks before taking off for your sprint. No one said it would be glamorous.
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
Credibility is cash, and in the first 90 days, you have to treat it like a scarce, precious resource. The leaders who hired you trust you to some degree, and your team likely respects your background. But this isn’t credibility – not yet.
The quality of your work and the way you treat people will build credibility. But this is long-term work, and until your credibility is solidified, there are more ways to ruin it than build it. Therefore, one of your goals is simple but, depending on the people, not always easy: Don’t piss any groups off in the first 90 days.
You'll never be everyone's favorite, but reserve judgment about which teams you need to impress and which teams are not in your corner. The loudest or most visible groups in the first few weeks may not actually be your most important stakeholders; similarly, the quiet and initially skeptical can end up being the most helpful.
Teach them to learn
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.
Figure out which things do change about this company and which things don’t. Every organization has sacred cows – whether they admit it (or even know it) or not. Determine which pieces on the board you can move and which you can’t (for now). Once you start making moves, the board will eventually change in your favor.
Your Top Five Priorities
Your first 90 days will fly by. These are the top projects you either need to start or complete by the time your 90 days are up. Without them, the rest of your tenure will feel like swimming upstream.
1. Run 360-degree interviews
Run 360-degree interviews up and down the organization, and across departments and teams. You want feedback and input to be holistic and to reach past your immediate peers.
This includes talking to engineering managers and on-the-ground junior engineers, as well as leaders in entirely different departments. Think finance, product, and your customers (i.e., internal IT).
Pay extra attention to your platform team, which will have special insight into the maturity of your organization. For example, other engineers might claim to have and use CI/CD; the platform team will best know how effective those systems really are.
But compare both sides because the opposite can happen, too: Many platform teams might unknowingly overemphasize the maturity of the CI/CD platform they built, and the actual users might have a completely different story.
The goal is to listen but also to triangulate: The truth always lies somewhere in the middle.
2. Audit the processes that came before you
You were hired for your experience executing and operating effective processes, but the processes you implement won’t be radically novel. The processes that underpin good software development are no longer a mystery. The goal is not to be wildly innovative – the goal is to get effective processes and practices adopted by your team and adapted to your context.
Figure out, then, why they haven’t implemented those processes yet. The best ideas aren’t groundbreaking. What’s stopped them in the past? Which priorities might compete with yours?
The best way to map this out is to determine how long it takes to get from an idea to a product in a customer’s hand. When you ask, don’t accept simple answers – get to the true number that lies behind the “We ship every day” claims.
Did a traumatic incident convince them they need manual releases, for example? Validate the rationality – an automated release led to the committing of faulty code – but keep digging. The problem, in an example like this, isn’t automated releases. The problem was the specific automation, which can be fixed, or a new, better one can be introduced. With that understanding, you can use the incident to inform the new process and reassure the skeptics at the same time.
3. Build in feedback mechanisms
Even in your first 90 days, you want to take as few steps as possible without feedback. Build a feedback mechanism early on so that every change generates feedback that informs the next changes.
At the same time, keep expectations around feedback clear. Feedback should always be filtered, but it’s especially important in the first 90 days. Because you’re new, people can sometimes feel entitled to immediate responses once they offer their feedback. You also don’t quite know who to listen to (or how closely), so use data to help you determine whose feedback will be instrumental and use your understanding of the organization’s strategic priorities to determine how that feedback fits in.
Transparency around this sort of feedback keeps people engaged and maintains confidence that changes are not being made by fiat. Ask questions like:
- How are we going to know a change is effective?
- When are we going to reevaluate a change?
- Who's going to look at a given change?
- What would it mean for the effects of this change to fall outside of the acceptable variation range? What would we do then?
Your feedback should include both qualitative and quantitative feedback, combining data from pulse surveys and platform metrics (for example).
Building feedback loops requires the right data
Uplevel combines engineering metrics with team sentiment to give you the full picture behind the numbers.
4. Look for leverage points
Leverage points, as Donella Meadows writes, are “places within a complex system where a small shift in one thing can produce big changes in everything.” A simple idea that requires nuance and balance to execute.
Quick wins show progress, but – because they’re quick wins – likely won’t incur long-term or lasting change. Leverage points align with preexisting strategic goals and take longer than quick wins but eventually demonstrate significant change.
You don’t need to come in and be different, and you don’t need to rip out and replace everything summarily. Determine where your interests and preexisting organizational interests already align, and drive toward progress in that direction.
It’s counterintuitive because most leaders want to make big waves, but disruption of that sort can’t happen too early. Instead, enable the organization to succeed at what it’s already struggled to achieve.
5. Create the conditions for debate and decision-making
Engineers want to be engaged. And because there is always a why behind even “bad” processes, it behooves you to learn the why and involve engineers in the discussion about what’s next.
You want to be perceived as someone who listens. Hear them out and learn why certain decisions made sense at the time. Hear out their concerns about new ideas and make your case. Remember, you want them to be comfortable giving you feedback long past the first 90 days.
Similarly, set up decision-making frameworks so that these conversations and the plans emerging from them flow from consensus. This could be the Amazon six-pager format, an impact/effort matrix, or an OKR framework. Don’t worry about the particulars; focus on encouraging conversation without drowning everyone in discourse or wasting their time.
What Not to Do
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.
1. Don’t fight the game
The role of an engineering leader is always political. As a new engineering leader, you’ll likely encounter situations that don’t make sense to you yet. Or, worse, they’ll make all too much sense to you, and you’ll immediately infer the baggage accumulated from decisions long ago.
Now is not the time to fight against the game. Learn the game, and play it as well as you can. Your priority, for now, is to show that you’re a team player. You have to show you’re not above the game before you can change the game.
2. Don’t rock the boat (yet)
Your first 90 days are not the time to disrupt everything. Instead of rocking the boat, figure out the changes and goals already in motion and ride the waves.
Even good changes, made rashly, will upset other leaders. That does more harm than good in the long run. Similarly, as you pick which changes to push and who to push with, don’t pick favorites. You might think you’re being nice, but imbalancing the scale will also upset the organization.
3. Don’t fight the detractors
Internal change follows the Innovation Adoption Curve. The innovators will be on board fast, so focus on the early adopters and the early majority. Those groups will carry the rest of the organization.
The loudest group, however, might be the laggards. You’ll be tempted to argue with them, but it’s best to ignore them and invest in groups more likely to see your vision. The laggards will absorb the most time for the least results.
4. Don’t fight the old metrics
Organizations often resist changes to their metrics even when they claim to want sweeping change. As a result, don’t try to rip out old metrics on day one. Instead, pick pre-existing metrics that align with your goals and focus on those.
You can ignore, or at least downplay, the truly bad metrics, but don’t discard them if you don’t want a fight. Working with old metrics is, counterintuitively, the best way to show their limitations. As you work with them and as they see through your eyes, you can ease them into the idea of new metrics.
5. Don’t take them at their word
“Trust but verify” applies to organizational change as much as it applies to information security. Throughout your interviews and conversations, listen but be skeptical. Ask them, for example, whether they have CI/CD, and check what they really mean if they say they do.
Use the power of your outside perspective. If they claim to have a mature platform, listen to them, but examine the platform: Is it really as mature as it can be? Their perspective will be deeper, but yours will be broader. What are their unknown unknowns?
Regroup and Try, Try Again
Organizational change is a systems-level problem, and you have to prepare for resistance.
Think of this work as similar to introducing new animals to one another. There are often incremental steps, such as acclimating them to new scents, before they can even begin to coexist. Move too fast, and the system will reject the change outright.
As such, be ready to regroup and try again. Often, your ideas will be fine, but your packaging won't be. Prepare to try the same ideas in new ways until something clicks.
Your first 90 days are the proving grounds for your next attempts. Every step in your first 90 days could fail, but if you fail well, your next five years will be a resounding success.