lorax

...I intend to go on doing just what i do!
And, for your information, you Lorax, I’m figgering
on biggering   

and BIGGERING

        and BIGGERING

             and BIGGERING

- Dr. Seuss, The Lorax

In the technology world, we spend an awful lot of time thinking about and striving for growth. At the risk of turning poor old Theodore Seuss Geissel in his grave, I think this a good thing. Thinking about growth, the right kind of growth, can drive teams to create tremendous value. 

But there's a catch: not all growth is good growth. Operating under an assumption that in order to grow, all things must grow may result in the opposite happening.  We have a fundamental belief at HubSpot that small teams have the biggest impact; growing the size of our individual technical teams would be the bad kind of “biggering”. Twitter_logo_small So, for us, when it comes to structuring and cultivating teams, size matters. A lot. 

Finding the Magic Number

Every company will have their own variation of what ‘small’ means. Amazon uses the two pizza rule (if you need more than two pizzas to feed a team, then the team is too big.) For us, small looks like one and a half pizzas. Our prototypical team is five people: one Tech Lead, two Developers, one Designer, and one Product Manager. This team of five, led by the Tech Lead, owns a meaningful area of the product, such as our blogging platform or our marketing automation tools. And by own, I mean OWN. They answer to no one about the specifics of what they work on day-to-day or what their priorities are. While the teams are small, their challenges are anything but. In most cases, a team of five is responsible for building an area of our application that other companies might call on the skills of 10X (or more) the number of developers.

The rule of five-to-a-team is not absolute. We have some teams that are slightly bigger and others that are smaller. But we do aim for that magical five. We've fought very hard over the years to make this team size stick even while we have grown dramatically as a business, a company, and a product team overall. This is incredibly hard but fundamentally important to our culture.

The Big Benefits of Small

There's something really special about what a small team can accomplish if they're given the autonomy to own all aspects of their part of the product. Small teams can move quickly and be more nimble; changing direction based on customer learning is much easier when there are only five people to get up to speed. It's also much easier for everyone on the team to stay close to the customer and get that ever-important primary customer feedback.

Not surprisingly, members of a small team have a greater ability to make an impact on a daily basis. If you're one of the three Developers building the social media tools at HubSpot, you can be pretty sure that your individual contributions are going to matter a heck of a lot to our customers.

The broader benefits of small teams go beyond the team itself, like clear accountability. Knowing who’s responsible for success and slip-ups is easy because there’s such a strong sense of ownership. If you have an organization with high accountability but weak ownership, you have a recipe for low-risk tolerance and probably very little innovation. And if you have an organization with strong ownership but little accountability, you most likely have a poor ability to execute. On our Product Team, it's very clear who owns every aspect of the product and infrastructure, and the accountability for success rests squarely on the same shoulders. Our small teams are tremendous enablers of this.   

On the squishier side of things, small teams enhance a sense of bonding and belonging. When you're five people against the world trying to surmount big challenges, it's easier to pull together, support, and push each other. Strong, tightly knit teams with a good balance of skills enhance the performance, productivity, and happiness of the individuals on that team. Strong interdependence within a team is a tremendous motivator, while simultaneously providing a sense of importance and belonging. We all want to matter and work on things that matter. Twitter_logo_small

But All is Not Magical in the World of Small Teams

As with all organizational approaches, there are trade-offs. The biggest challenge inherent in small teams is in executing big sweeping changes across the entire product. We have around 20 teams working on our core product, depending on how you account for things. When we want to do something as simple as change the skin of our overall product, it's much harder than it would be if we were one big team with a more traditional, hierarchical structure. Don't even get me started on the challenge of something like introducing user-customizable access-level controls.

A small variation on this sweeping change challenge is simply keeping all of the teams aligned and focused on a consistent user experience. It's not uncommon for one team to be ahead of another team on a particular shared product element. This can lead to a disjointed user experience if it's not managed carefully. The fact that our Product Team is located in two offices, on two different continents, can exacerbate this challenge substantially.

We've tackled these challenges in a few different ways and are always learning what works and what doesn’t. Mostly, we invest heavily in communication on multiple levels to keep teams talking and we focus on ensuring that we have DRIs (directly responsible individuals) for everything. In particular, we lean on Designers and PMs from different teams to be connecting and staying aligned. If a team needs extra support, a manager will step in and help them get unstuck. We don't outline a particular solution -- we just identify the problem and push the teams to solve it. The bottom line is everyone needs to know what their counterparts are working on and where they are headed. This doesn't mean we have schedules full of status meetings. We just talk to each other... a lot.

While it's easier for small teams to come together with a shared mission, the condition of this benefit is that every member of the team needs to be a good culture fit. A single personality mismatch can spell disaster for a small team. Twitter_logo_small We spend an obscene amount of time at HubSpot thinking about what types of people complement each others' skills and who works well together. We also move very quickly to make changes when it's clearly needed. Deeply understanding the people on your teams -- their skills, their motivations, their drive -- is critical in this environment.

Finally, we are growing like crazy and are constantly hiring new developers. This means that we need to find ways to create new teams without disrupting all of the important cultural components. What we've arrived at is a method of requiring a sort of mitosis of our existing teams. We ensure that newbies are paired with old timers so that they can get infected with the HubSpot approach to product development. Just like organs in the body, we need each of our teams to be able to function with other teams even as they excel in their own focus area.

In the end, it all comes down to the people. That's why we put so much energy into building and cultivating our teams.  

Figgering on Biggering

There is no one-size-fits-all team or organization. The structure of your teams should be such that the most important outcome comes naturally to your organization, then you can put your energy into everything else. At HubSpot, we value speed of innovation and ownership above all. This means that we have to put serious energy into some things that don't come naturally to us. So be it. That's how we all grow.

The bottom line is that, for us, small teams are the path to successful and sustainable growth. And that's the kind of “biggering” even the Truffula trees might be happy about.  

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