Being a New Engineering Leader on a Team
25 August, 2021
When a company is flourishing, engineering teams tend to groom new leaders, and most engineering teams would prefer to promote from within. Almost always, there is someone on the team who could fill the seat that has emptied up. It is somewhat rare to bring an engineering leader from the outside when the company is doing well. Bringing in a new engineering leader may look to some managers or directors as taking a spot that was meant to be theirs. Upsetting them and making them want to leave is something no one wants to happen.
I was in this situation twice and learned immensely from both instances. I ran into a variety of problems once I was wedged into an organization as a leader. One of my main fears was being rejected by my own team. Engineers want a leader who understands the domain and whose technical, organizational, and project leadership is embodied in a single person. That is a rather vast area to cover, especially if one changes the company too. As a newcomer, I was unfamiliar with both the product and tech stack itself. I was profoundly concerned about how not to immediately lose the team that I had just become the leader of.
Though I was unfamiliar with the product, stack, or the details of what the team was working on day-to-day, I approached the situation with an open and humble mind. I didn’t allow myself to pretend to know something that I didn’t. It’s easy to walk in and put it on, but if -- or more precisely, when -- one gets busted, they would lose their team respect in a nanosecond. Fake it till you make it simply doesn’t work in those situations.
I was glad to go through standard engineering onboarding in my current company. For the first four to six months, I was there to learn the ropes and gradually start contributing -- build features and get code into production. That helped enormously. Though I am not coding in my current role, I could grasp what the team was working on and how.
Then, for the first couple of months, I was merely observing. I didn’t drive in any direction; I didn’t make any decision. I just asked a lot of questions. Absorbing the context and asking probing questions was a good way to learn, as well as to build trust with people. They could tell that I was curious about what they were doing, what technology they were using, etc. Engineers will always respect people when they are genuinely interested in their work.
Observing also meant putting in brackets any reference to my past companies. One of the epic ways to mess up coming into a role as an external hire would be to say, “At company A or in my previous role, we did this; why don’t you do it the same way?” While it is quite a natural question to ask, it tends to put people off. When phrased this way, it comes off as “I know better than you.” When a leader, one should understand that questions are never perceived as questions, and people always read something into them. So, I was careful about asking questions or making statements that could land as pretentious.
The catch with hiring people from the outside is that they are expected to bring in new ideas. One of the downsides of promoting from within is that it strengthens groupthink. When I ask people why they do things a certain way, I expect an answer different from “Because we always did it like that.” That type of answer would tickle my spidey sense, enough to bluntly tell that people should know why we are doing things one way or the other. However, I wouldn’t walk in and immediately challenge the old ways. Instead, I let things simmer for a while until trust solidifies.
From week one, I would try to do what needs to be done. At all times, there would be things that engineers don’t know how to do, don’t want to do, or don’t have time to do -- and I would do it for them. That would show the team that I am not someone who would sit aside and tell other people what to do. Taking things off their plate would demonstrate my willingness to work for people. That is something a servant leader should do. It’s always good to be perceived as a part of the solution and not a problem.
However, since I am a manager of managers, while I want to have a good relationship with ICs, my primary responsibility lies towards the managers directly under me. Listening and helping them out is critical to gaining trust and legitimacy. Some of them probably wanted the role I assumed, which made the first few weeks a bit awkward. I would make sure that they understood that I would not be a ceiling to their growth. That is somewhat perplexing since, by definition, I joined their team as their leader. Everyone knows how scarce engineering talent is, and no one wants people to leave, which means that I should try to make opportunities for everyone. I came into this role thinking of myself as an agent of the organization; I am there to help the organization do better. I am not there for me, but for everyone else. I was rather intentional about taking that approach, which I believe helped me become accepted.
- Be humble, roll up your sleeves, and do whatever needs to be done. By whatever, I mean whatever. At one of the companies I was working in, shifts were introduced to keep the kitchen clean. I saw this as an opportunity to show all ICs who were doing their shifts that I was not above cleaning a sink and doing dishes. If I couldn’t partake because I had a meeting, I would give them a heads-up.
- Don’t mention previous companies you worked at unless being asked about. Don’t ever moralize, ”At my previous company, we did this or that.” No one likes that. People want to hear your outsider’s perspective but have people ask for it; don’t volunteer your opinion. Make sure to build some trust with people before you start sharing ideas and how they can do things better.
- Don’t be your team’s ceiling. Instead, enable your team to flourish. If that means losing some parts of your team because one of your direct reports becomes a peer, go for it.
- Be aware that there will be somebody or multiple somebodies on that team who wanted that role and didn’t get it. As their new boss, you will not want to put off people who you will need most. Be explicit about your intention and how you can help them grow.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Vadim Antonov, Engineering Manager at Meta, details his journey to improve his personal hiring process and team pitch.
Engineering Manager at Facebook
Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.
Director of Product at Startup
Neelima Annam, Sr Director Information Technology at Outmatch, shares her insight into her growth path of evolving her management style to build trust.
Sr. Director Information Technology at Outmatch HCM
Albert Lie, former Founding Engineer and Tech Lead at Xendit, didn’t know what it takes to become an early engineering hire and not a lot of people around him experienced this unknown and arcane path. He had to learn it the hard way from the pitfalls he encountered along the way and he has been creating numerous frameworks to measure his growth and keep burgeoning in this role since then. He codifies and expresses the systems he put in place surrounding the balance of customer inquiry to product building and growing the engineering team.
Former Tech Lead at Xendit
Deepesh Makkar, Sr Director of Engineering at SunPower Corporation, shares his experience transitioning his organization from contractors to a 50/50 split of full-time employees and international vendors.
Sr Director of Engineering at SunPower Corporation
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.