Shut up and listen

Before joining the company, a friend, who’s also kind of a mentor, gave me invaluable advice: “Use the first three months to learn as much as you can about the organization and its culture, decision-making methodologies, processes, ownership, development cycle, and more. Observe, ask many questions, document, but keep feedback and suggestions for changes to yourself.”

If you knew me, you’d know that this isn’t my nature, yet I followed his advice. I resisted the urge of pointing out problems that seemed crucial because I knew I didn’t have the full picture. It’s a good thing I did, because many times, these problems turned out to be marginal when I became aware of the greater context. I kept reminding myself not to try to fix things that are not broken, simply because I’m used to doing them differently.

I also followed The Management Flywheel principle: don’t revolutionize. Start with small wins, help the team move faster, make their job easier, build momentum and confidence.

I chose to respect the architecture and design decisions that were made in the past and not belittle implementation that is now viewed as tech debt. After years in R&D, especially coming from a startup, I know that many choices and efforts were right at the time, and are there for a reason. They may very well need to be reconsidered, but that’s perfectly fine.

Fast forward to a few months later, I learned that this exact behavior was in fact something that I was valued for. I believe that it brought me to a place where I’m comfortable expressing my thoughts openly and they are welcomed with respect.

Align expectations

After spending a month in one team I was assigned to lead another. During the first couple of weeks, I was basically imitating the work I’ve seen the other squad’s lead do. I remember getting the feeling that things are not going as they should. It was only in the first one-on-one with my manager when I learned that the teams’ missions are extremely different, hence the expectations from me.

Knowing exactly what your manager and organization expect from you can help alleviate pressure and uncertainty. Clear expectations act as a north star that keeps you on track. And of course, meeting these expectations increases confidence and provides a sense of accomplishment.

Ideally, expectations should be discussed during the recruiting process.
Regardless, I advise asking your manager about her or his expectations of you right off the bat and to review them together. A good question to ask is: “What will success look like in this role?”.

If your organization has set management guidelines I advise reading them and reaching out to other team leads to discuss further.

Build relationships

I genuinely believe that building strong, trust-based relationships is the primary key to success as an Engineering Manager. This isn’t restricted to leadership roles, and you’ve probably heard it before. But sometimes, old is still gold.

Direct reports

When a new manager to the company joins an existing team, both sides are likely to be insecure. With this in mind, I used the first few one-on-one meetings with each team member to disperse the fog, add clarity, and gain confidence.

I achieved this by spending a significant amount of time meeting with each team member, one on one, to deeply get to know one another. In these meetings, I did a lot of listening and assured my team members that I wasn’t going to change anything about the reality they knew and loved within the near future. This immediately made them more receptive and positive towards me being their new manager.

Additionally, I shared my “management README” — general approach to leadership and priorities — and laid out the expectations s/he should have from me.

All the above becomes more relevant in a time of remote work.

Colleagues and peers

After reading The Most Important Partnership, I’ve decided to solidify my relationship with my product counterpart from the get-go.
It wasn’t an easy start, as we have different perspectives, but we managed to find the formula to work together smoothly and effectively.
We decided we would be transparent, honest, and constantly share our thoughts and feedback. We made sure to involve each other in decisions, strive to stay aligned, and practice mutual responsibility for the squad performance. From my standpoint, we formed a partnership that turned us into a force multiplier for the team.

During my first days, the supportive colleague in charge of my onboarding suggested that I should go on a “listening tour” — schedule informal time, coffee or a beer, with other Team Leads in R&D, learn from their experience in the organization, and ask questions that concerned me.

I was genuinely surprised and thankful by how my colleagues were responsive and willing to spend time with me and share knowledge. The interpersonal and professional gains from these meetings were immense and I highly recommend it to managers joining any organization.

Be present

As I see it, this naturally relates to the “build relationships” point. If possible, I strongly encourage new Engineering Managers to arrive at the office, meet face-to-face with teammates and co-workers. It also presents the opportunity to get to know other stakeholders and functions beyond Engineering, and form deeper relations.

Nevertheless, attending meetings in which your presence isn’t required, participating in production incidents triages, joining virtual coffee breaks or after-hours past times would strengthen your sense of belonging and connections to the people in the company. Even being online and available for your team, helping in their efforts, or just listening, can have a tremendous effect on your relations with them.

Final thoughts

You might have noticed that I didn’t mention anything about building technical foundations or acquiring hands-on experience, and it wasn’t by mistake. Don’t get me wrong, I’m not suggesting that getting to know the system architecture, design principles or technological stack isn’t important for a Team Lead. I just know that you can’t have it all from the start.

While in many cases there will be others to help with a Pull Request or a failed build, as a manager you’re the first point of contact for “peopleware” matters. In my view, this is a manager’s top priority. Oftentimes other affairs have more significance than your code contribution or other deliverables.

It’s challenging but possible to get to know the bottlenecks and day-to-day pains, like dev environment, other teams dependencies, lack of automation, and knowledge silos, even without “feeling” them yourself. You can accomplish this by listening to your team and encouraging them to share what’s holding them back. Another way is to set up metrics and measure the productivity of the team in several areas, such as the ones detailed in the enlightening book Accelerate.

I do believe that after the dust settles you’ll find the right time and platform to put effort into technical areas and bridge your engineering gaps.