How We Onboard External Engineering Leaders by Having Them Be Software Engineers

I regularly get asked what my biggest challenges are or what keeps me up at night. For me, it’s making sure we attract and retain the right engineering leadership (who believe in our shared philosophy) so that they can support our rapidly growing team. When you are growing as quickly as we are, it is extremely important that you have leaders in place who can sustain the culture of excellence as we scale. A bad leader has a very high blast radius.

One of the solutions here is internal promotions. And we certainly lean in here, looking to cultivate our next generation of leaders and giving up and comers larger and larger opportunities to have an impact. But, it’s also important that we bring in leaders from the outside in order to foster a culture that brings in differences of opinion, background, and experience. So, how do we set them up for success and help them assimilate without putting undue pressure on them to succeed on day one?

A few years ago, on one of our annual West Coast field trips, we asked several executives whether they hired external engineering leaders and, if so, how they onboarded them. They told us that they do hire external leaders… but… they do not put them in role on day one. Instead, they give them an extended period of time to get to know the organization, the culture, and the tech stack. While this makes sense initially, what’s the real ‘why’ behind it?

Say Kim comes in from another tech company and she immediately starts to manage and lead a team. Most likely, her leadership skills, and the software the team builds, will be in the style of her old company, not in HubSpot fashion. And not through any fault of her own, but because she was thrown into her role and not given the time and space to learn how we operate, how we build, and how we lead teams to success. Over time, you have enough Kims joining the leadership team building the way they know how to build, and HubSpot’s culture, core values, and foundation becomes misaligned and cracked. In addition, this doesn’t really set Kim up for success.  She’s not being given any opportunity to adjust her style and, therefore, its creating a really high barrier for her to get the trust and alignment with her teams.

So to avoid this potential pothole, every external engineering leader who joins the team goes through what we call an “Embedding Process” for the first several months at HubSpot. They are onboarded and treated just like any other engineer who joins the team taking the same training and going through the same onboarding project. Then, leaders start with a single “deep embed” where they focus on one single team for two to three months. This is a deep immersion where they are really learning the tech stack, the culture, the domain, etc. Then, they start to move toward more of a rotational model where they might spend one month or even just a few weeks moving from team to team learning the domain of that team. We’ve even started to do some rotations to other teams (ones they won’t be managing) if there are tight relationships between those teams.

For us, a successful embed looks like this: 

• The leader has built credibility amongst the team by getting their hands dirty, working side by side with the team, and solving real world problems
• They have a deep understanding of our development philosophy by living it first-hand 
• They build empathy and intuition for all members of the team they will ultimately lead 
• They understand the customer needs and product roadmap by working directly on projects engineers face on a daily basis 
• If there are key teams outside their group that they will be working with regularly, they have also developed a similar empathy with those teams to build trust.
• They learn how our tech stack truly works (by the way, this is intentionally last here as people often think this is #1)

To date, we’ve had a small but mighty group of leaders go through this process, and we’ve certainly learned a lot along the way. Here are a few lessons we’ve learned: 

1. Set the right expectations early: One of the biggest misconceptions people have is that we expect them to be a great engineer during this process. In fact, the expectation is that they will be roughly at the level of a new experienced software engineer, but not the “best” engineer on the team. This means that it’s really important to set expectations for the leader up front, but also for the teams they will be managing. 
2. Actively discourage imposter syndrome: Leaders often feel a combination of nirvana (“you are actually going to pay me to learn for 6 months?”) and apprehension (“am I going to be judged for my software programming skills?”). There are periods of elation and periods of tremendous imposter syndrome, but as long as the expectations are set and we’re clear on what we consider success, the doubts should fade.
3. Trust the process: One of the biggest questions we wrestled with was the timeframe we had leaders embed for. Initially we started with three months. But over time and several iterations, we landed at five to six months, because we found that, given more time, the process was more successful. It’s hard to have hired someone who has a lot of experience at managing tough situations and then we tell them and all of their future peers that they won’t be doing that role for 6 months, but we need to believe in the process and the outcome.
4. Lean into the power of saying no: One of the things we learned early on is that there are a myriad of pressures that are pulling the individual out of their embed. Their future leadership peers want to pick their brains and ask questions. They have years of experience solving difficult problems and, when they see them, they want to jump at them. In order to resist the temptation, you have to set expectations across the organization, but also give the new leader the power to say no.
5. Re-entry is critical: We’ve learned to make the transition into the leadership role post-embed much more of a focal point. The last month, the embeds shadow more leadership meetings, so that they listen and learn and understand context to help them be successful in their own role.

As people rise up through leadership, some strive to stay technical, stay close to the code and make a contribution. And one of the hardest things is to balance that passion that initially landed you a career in CS with the role of being a leader. Add on transitioning to a new company and having to learn a new tech stack without the time or space to do it, it becomes an impossible balancing act. Engineering leaders at HubSpot do both jobs: they are technical leaders and they are people leaders. This is thanks in part to this embed process. 

So if the idea of spending six months close to the team, doing something a bit scary, but embracing that as a growth opportunity sounds exciting, we want to hear from you.