Your first day as a new engineering manager

Cover Image for Your first day as a new engineering manager
Alex Bachuk
Alex Bachuk

When you join a new team as a manager, it may seem like complete chaos to you. Everything and everyone is unfamiliar. The amount of information you need to absorb is immense. It feels overwhelming and confusing. You're trying to understand the product, meet the team, learn architecture, and, at the same time, make sure the execution continues.

Usually, you have to push back on requests and demands to protect the team from over-commitment on day one. It may feel uncomfortable or even stressful as a new person on the team, but necessary.

Your team will be relying on you to set the direction. So, you'll have to do a lot of preparation for successful onboarding. The key is to be able to learn quickly, stay flexible, and open-minded. As the saying goes: "What got you here won't take you there." Every team, project, company is unique. Be prepared to adjust to the new environment.

There are different scenarios when joining a new team. It can be a brand new project, and you'll have to form the team, or you're joining in the middle of an active project while trying to put out fires. I'm going to cover the latter since it's more challenging and happens more often than the former.

Before you start

Taking breaks is important. It's especially true when you're switching jobs. With busy schedules, everything becomes a blur. Meetings overlap, problems spillover. You have a lot of things to wrap up and handover on your way out.

When you're making a significant change, don't bring your mental baggage to the new team. Take a mental break, say goodbye to the old problems, unresolved conflicts, unfinished projects. New challenges will be different. It's a way to reset and shift your mindset to the new gig, creating a clear separation between yesterday and tomorrow.

Your experiences may not apply in the new role. Do some research on the company or product, the tech stack they're using, and the business model. It's your last chance to look at it from the outside.

Know your team

When you join a new team as an engineering manager, your top priority should be meeting with your team. Get to know them as a team and as individuals. It's a stressful time for them too. Learn their strengths, weaknesses, career aspirations. It will help you determine the right people to involve in some discussions as you're ramping up in the first few months. You'll rely on them to make decisions that can affect the next few years of tech strategy and commitments.

Start building trust and relationships with them on day one. Pay attention to the culture, dynamics, engagement, and excitement. Get a sense of how well they know the product, the roadmap, and current goals. Be curious about why things are the way they are and if they agree or have ideas for improvements or innovative projects.

Assess the situation

Before making any decisions or assumptions, make sure to evaluate the current situation objectively. It may be tempting to jump into reactive, problem-solving mode because you have answers. Most likely, your answers were helpful in a different context for different people. A new combination of circumstances makes this situation unique.

Get to know what you're dealing with now. Spend the first 2-3 weeks observing how everyone operates. Learn about the current architecture, stack and product, the roadmap and vision. It's critical to understand the future to be able to make the right decisions now. Chances are you already have few projects on your plate and need to provide answers. Always think long term, and that's why knowing the future is the key. If the team doesn't have a strategy, then it's your job to figure it out to the best of your ability. Involve your manager, the team, and potentially some existing customers.

Find allies

As a new manager on the team, you never work in isolation. Having partners who share the goal of success is important for you and the team's success. Usual suspects are product managers, design leads, marketing managers, TPMs, and other EMs. Identify key people involved in the product. Talk to them to understand their frustrations, pain points, plans, and strategy. Since you're starting with zero political capital, their support will be critical to align and resolve conflicts now and in the future.

Have your team and allies agree on the strategy and decisions internally. Then it's easier to negotiate or push back externally with leadership and stakeholders.

Your manager should be your closest ally and biggest supporter. They are invested in your success. Make sure you have a good relationship and trust established from day one.

Understand your role

The role of engineering manager may vary from company to company. Before you start running, take a moment to understand what others expect of you in the new organization, not only from the job description but, most importantly, from your team. Learn what they expect of you as their new manager. You may be surprised, and sometimes it may contradict your assumptions. Perhaps they need process improvement and more ways to communicate and less technical strategy from you.

When you meet your team, your peers and your manager ask them this question: "What do you expect of me as a new manager on the X team?".

All of this information should paint you a better picture of pain points, struggles, challenges, opportunities, and what success means for you. After doing your homework, work with your manager to develop a 30/60/90 plan, even if it's not required. Having your assumptions of where you should spend your first three months written is important to align with your manager. Know what success is and go backward.


Having good up to date documentation is like a treasure, valuable but rare. You'll be lucky if there is one readily available. The only time when someone cares about the documentation when someone leaves or a new person joins the team. Other times, the information is tribal knowledge. Everything is well understood and therefore doesn't have to be documented for "obvious" reasons. It takes time and effort to write things down. Writing is not easy. Sometimes, it can be more mentally exhausting than writing code, so engineers default back to regular work.

Your first few weeks are the perfect time to demand documentation. It's the only time to ask stupid questions. Ask all the questions you can think of before it's too late. After a few months, everyone will expect you to know these things. Simultaneously, suggest your team write the answers instead of repeating them or doing it yourself while learning. As an outsider, you have a different perspective, and it's a unique opportunity to see the gaps. You'll take extra effort to explain the logic carefully as though you don't know all the acronyms. In my experience, even veterans will appreciate that.

Writing things down also is a good reality check. It allows you to validate or disprove your assumptions. Others would correct you right away if you got it wrong. It's hard to do that with your thoughts. If you misunderstood something in the meeting and keep it to yourself, it's a recipe for disaster later unless decisions are documented.

From now on, don't forget to maintain the documentation. Write things down as much as possible. Keep documenting meetings, decisions, ADRs. Some content is only meant as internal notes, but most should be public knowledge. Everyone agrees that documentation is needed, but few invest in it. Lead by example and make an effort to write and maintain the documentation. Then encourage others to do the same.

Look for opportunities

When you're still relatively new, use this time to bring new ideas and perspectives as an outsider. It's the time to question the current ways of doing things, challenge the status quo. People who have been around for years may not notice inefficiencies and can miss the apparent gaps and opportunities. You can also introduce some fresh ideas coming from a different company or team. Be sure to leave them as suggestions, don't come to the new company with answers. There are usually good reasons things are the way they are. That's why assessing the situation and talking to people should come first. Treat your ideas as friendly suggestions. Apply the strategy to the situation. Every team is unique.

There's usually a lot more going on, like people quitting, interview pipeline, pending escalations, and conflicts. Depending on the organization, it can be overwhelming or too overwhelming. Try to stay open-minded, ask a lot of questions, and take a lot of notes.