The Hard Part About Creating New Teams Within an Engineering Organization

Part of continuous innovation means we’re constantly spinning up new teams with new missions within our product organization. One of the key challenges here is ensuring that team has the core HubSpot DNA that will allow it to be fully successful on its mission. Growing that DNA in isolation is possible, but slow. Finding a way to quickly infuse our core values and culture into those teams can really accelerate their ramp. As our team and product grows, we’ve been investing more energy into finding that solution, and we think we might be onto something.

We’ve considered a number of different options for structuring new teams and almost made what could have been a few big mistakes. Not because the people we were looking to put on certain teams aren’t talented -- to the contrary, we considered putting some absolutely amazing rising stars on new teams. But because we would have been ignoring one key lesson we’ve learned the hard way: put new people on established projects and established people on new projects. 

Here’s the basic premise. If someone is new to the organization, they need to focus their energy on becoming a great HubSpot engineer -- learning our stack, culture, and everything else that goes along with that. The best way to help them succeed is to put them in a world that is reasonably well-defined and surround them with team members who can help them grow.

In contrast, if we have a greenfield opportunity, like a new team or product function, where there is a high level of uncertainty around the path it might take, the best thing we can do is put an established HubSpot veteran on that project. They don’t have to think twice about culture or stack, but instead can focus on solving the problem at hand, move quickly, and share that DNA with the rest of the team.

When you put those two things together, it leads to the simple conclusion that we should be putting new people on established projects and established people on new projects. Sounds easy, right?

In practice it actually isn’t because it involves change and, change is hard. The easiest thing to do (from an organizational perspective) is to just hire new people and throw them on this new project. They don’t have an existing team so you aren’t creating any friction; just drop them in and set them loose. That way there’s no need for lots of meetings, transition plans, worries about hurting feelings, etc.

This might work in the short term. But ultimately, it does a disservice to the team. They’ll have a harder time doing things in a HubSpotty way and won't get to benefit from all of the playbooks that we know work. That’s why the right decision is to find an established person (meaning they are already on a team and presumably have a good thing going there) and give them the opportunity to move to this new project. What this should look like then is a constant cycle where the new people we are hiring today become the foundation for existing teams tomorrow, freeing up the existing members of the team to jump to the “next big thing” at HubSpot in the future.

This doesn’t mean that we can never put a new hire on a new team. But the key is making sure new people have the right anchors in place to make them successful. For example, if we have an established HubSpot tech lead paired with an established HubSpot senior software engineer, they could probably take on a new hire and keep running on a greenfield mission. We tend to be very reluctant to hire people in as tech leads for exactly this reason and only do so in very exceptional situations. Instead, we regularly hire people who have been tech leads at other companies but bring them in as individual contributors first. It lets them ramp up on the culture and tech stack without expecting them to do that while leading a team. We've found that this maximizes their long term success by giving them a safe environment to learn in.

This "put established people on new projects" rule of thumb saves us a lot of time (and headaches) in the long run, but it takes a village to do a team migration well. We know we have succeeded when all interested parties were a part of the decision and are on board with the change and it doesn't feel forced or rushed. Often times, that’s the case, but we need to keep getting better at this. Here are a few things we’re thinking about as we scale new teams and work on improving our migration process:

• We need to find the right balance between stability and change. My goal here has been to ensure that within a team there is a sense of stability so a new team can feel established over reasonable time periods (let's say 12-18 months.) But, in aggregate, across all of engineering, there is a fairly constant set of changes happening. Say, for example, we had 40 teams within product. If we made one migration per team every 18 months, that would mean nearly two migrations per month across the organization. That's a lot of change, even if it is a small amount of friction for any specific team. We need to make sure we are not being chaotic but are also not being stagnant as the team grows.
• We need to keep rewarding both exciting and existing work. There are some people who want to jump on the next greenfield opportunity and create the next Sidekick or Leadin. And there are others who are more interested in optimizing, scaling, and solidifying our existing systems. We need to make sure we are providing exciting challenges for and rewarding both types of people as they each play extremely important roles in our success. It can be easy to focus on the shiny, sexy work of new projects and miss the importance of the plumbing work. But it is that plumbing work that drives our performance, our ability to scale the company, our reliability, etc.
• We should always be looking to optimize for the individual and EV (Enterprise Value) over the team. This is a tricky one (and why things can get hard), but our migration decisions should be driven by what is good for the individual and for the company, and less by the team itself. Optimizing for the individual allows us to keep growing and giving people new opportunities to stretch and grow. Optimizing for EV ensures that we are continually driving the business forward. Optimizing for the team can lead to calcification and can actually hurt both EV and individuals.

We believe that putting new people on established projects and established people on new projects will help us scale that HubSpot DNA as we continue to grow. But only if we do it the right way. Keeping these three learnings (and others we discover as we grow) top of mind is critical in making migrations a success.