Being a New Engineering Leader on a Team

Krijn van der Raadt

Sr Director of Engineering at AppFolio



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.

Actions taken

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.

Lessons learned

  • 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.

Be notified about next articles from Krijn van der Raadt

Krijn van der Raadt

Sr Director of Engineering at AppFolio

Engineering LeadershipLeadership DevelopmentCommunicationOrganizational StrategyDecision MakingCulture DevelopmentEngineering ManagementCareer GrowthCareer ProgressionIndividual Contributor Roles

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up