Before joining HubSpot, I had been at my previous job for 11 years. I had worked my way up from software engineer to senior director of product engineering. During that time, I benefited from all of the technical expertise and context that growing in the same company for over a decade affords you. I had truly helped build the products there from the ground up.

When I was approached about the position at HubSpot, I was excited about the idea of doing things differently and learning something new. At the same time, I was concerned about starting in a leadership role at a different company where I didn’t have the strong technical domain experience that I’d leaned on before. It wasn’t until I was further along in the application process, though, that I got truly hooked on the idea of working for HubSpot.

That was when I learned about HubSpot’s engineering onboarding process. Every external engineering leader hired at HubSpot goes through an “Embedding Process” for their first several months. During that period, they are treated exactly the same as any software engineer joining the team. No privileged access to information, no managerial responsibilities, no expectations beyond being a software engineer. They take the same training courses and go through the same onboarding process as everyone else. After that, they’re “embedded,” working as a software engineer switching between different teams and disciplines for time periods ranging from a couple of months to a couple of weeks. The whole process takes five to six months.

When I was hired, I was excited to go through this experience, though not without a healthy dose of nerves. I’d heard of other companies like Google and Facebook approaching leadership hiring in this way, but I’d never been through a process even remotely similar.

Now, I’m on the other side. I’m finished with my embedding and am transitioning into my role as an engineering director. Through the process, I had the chance to work with eight teams over a six month period, both in my home office in Dublin and in HubSpot’s headquarters in Cambridge. I met amazing engineers across the company and learned a lot about who I wanted to be as a leader at HubSpot.

Here are some of my takeaways.

Be curious

In the beginning of the process, the hired engineering lead only has access to the same information as their software engineer peers on the team. No leadership documents or slack channels, no email exchanges between directors. At first, this was difficult to get used to. From my old job, I was used to looking at things from a leadership level and trying to solve for the team. The engineering SVP running the embedding program told me, “You’re going to itch to take on leadership responsibilities, but don’t do it. The team needs you to be where you are right now.”

That made an impression on me. There was a lot to be learned, it turned out, from being cut off from the leadership information flow in the beginning. It made it clear to me where engineers’ blindspots were. It also meant that I was truly starting at square one. On a scale of zero to ten, my curiosity meter is at a 15 at all times, so I needed to get my information elsewhere, and that meant my teammates. Every person on the teams I worked with mentored me and answered my questions. I found that they grew more comfortable with me as soon as they saw that every question I asked came from a place of genuine curiosity and a desire to get better.

My curiosity often took me on the hunt for information. It didn’t stop with my teams or projects, either. I had a wonderful journey learning from people in various functions — from shadowing customer support calls, to learning about UX design and product management best practices. I would come to every meeting with a list of questions and often leave with a list of names for people I could contact to learn more about each topic.

This endless curiosity proved essential to my embedding process and I continued to carry it with me after settling into my leadership role.

Resist imposter syndrome

One of the hard truths of embedding is that, even though you’re a strong engineering leader and that’s why you’ve been hired, you’re not necessarily going to be a great engineer.

For most of us going through this process, it’s been a long time since we started our careers as software engineers. My specialty is backend distributed systems, and here I was embedding with frontend teams just as often as backend ones. Everything has changed so much in the frontend space over the past 10 years that what little experience I do have there was irrelevant.

That was a huge struggle for me. I was ok with making some mistakes, but I wanted to show that I was pulling my weight for my team and getting everything done. There were times when I felt like I didn’t know anything. When those hard times hit, my team was always there for me. They’d say, “Nadia, we’ve all gone through the same troubles before. It took us a long time to get around problems like this, too.”

It’s not all about the tech stack

Maybe the biggest misconception about an experience like this is that companies do it because they want external engineering hires to spend time in the trenches learning the tech stack.

While this is one of the reasons behind the embedding process, it’s far from the most important. Yes, my embedding experience was a great way for me to learn the intricacies of HubSpot’s tech stack, and the time spent learning our product details and guiding principles was incredibly helpful. But the most invaluable part of the experience was the relationships I built with my fellow engineers.

By the end of each embedding, the engineers on my team weren’t intimidated by me. I was one of them. They corrected my mistakes, they taught me things I didn’t know. I made close friendships where people could be honest with me, joke with me, mess around. Most importantly, I have an empathy for them that I’m going to carry into my leadership role. If I’d been thrown into my role right away, we wouldn’t have had the time to build that trust.

Go out of your comfort zone

As I mentioned earlier, my experience before HubSpot was on backend distributed systems. So naturally I was most comfortable when embedding on backend teams. However, I resisted the temptation to stay in my comfort zone. That meant going out of my way to ensure that I was embedding on an equal number of frontend teams where possible and taking on a variety of tasks to ensure as much exposure to new challenges as possible.

In some cases, I bit off more than I could chew, and on one occasion I had to give up the task that was assigned to me. However, that didn’t stop me from pushing over and over again to challenge myself in new areas with varied projects. It was important to me to experience as much as I could during that period, including the use of our various development tools and experiencing any challenges or difficulties first hand.

All in all, I could not be more grateful to have gone through this process for my first six months at HubSpot. As a leader here, you’re responsible for a large span of projects, and specific domain expertise is not necessarily relevant to the problem at hand. It’s important to have a handle on the whole tech ecosystem at the company so you’re able to innovate from within the pre-existing infrastructure, and it’s also priceless to spend the time on the ground as a member of the team in order to build trust with the people you’re eventually going to be managing.

The fact that HubSpot is making such an investment in onboarding engineering leaders is a testimony to how it strives to create an excellent employee experience at all levels. New managers go through a more thoughtful, in-depth training experience coming in, and employees get a more empathetic and adaptive leader as a result.

You may be coming in as an expert, but there’s so much more to learn.

This article was originally published on Medium.

Recommended Articles

Join our subscribers

Sign up here and we'll keep you updated on the latest in product, UX, and engineering from HubSpot.

Subscribe to the newsletter