HubSpot has been an Amazon Web Services (or AWS) customer for ten years now. Our footprint includes almost 2,500 EC2 instances, many petabytes of data on EBS and S3, and over a petabyte of web traffic flowing through over a hundred different ELBs each month. AWS’s offerings have been a huge driver of our growth because it has allowed us to easily scale up or down our infrastructure as our needs have changed. Furthermore, running our infrastructure in the cloud allows our engineers to focus on building HubSpot instead of building a data center.
Using documentation to cultivate co-ownership between design and development
This post is the second in a series about HubSpot Canvas, our new Design Language. Read the first here.
I came to HubSpot as a software engineering co-op just as a movement was growing. The design team had, over the previous months, created a gorgeous set of new typography, colors, and basic components that would become the cornerstone of a major redesign of our entire platform.
This post is the first in a series about HubSpot Canvas, our new Design Language.
In the skit, a man waits by his mailbox to confront the mailman about the lack of actual mail in his mailbox. Despite loving tacos, the resident says, “If I had to choose between the tacos and the mail, I’d have to choose the mail.”
Tacos are much more exciting than bills, but the man doesn’t need tacos. He needs his mail.
I regularly talk about the HubSpot Product Team's culture – both internally and externally – and I always start my discussions on our culture with the following idea:
We believe that if you give a team a compelling mission, the autonomy to attack the mission the way they see fit, and the support to accomplish this, magic happens.
This is, in essence, my management philosophy. The bulk of what we do on the leadership team here involves setting up situations where that magic can happen.