How We Solve Big Problems By Thinking Small

Over the past few years, HubSpot has grown our team, product, and business to a global level. We have over 13,500 customers in over 90 countries, serve millions of requests, and deploy 300 times a day. As you grow to that scale, one of the biggest challenges of building software is how you maintain the nimbleness you have as a younger company. When I talk to people about how product development works here at HubSpot, a common theme emerges: we keep things small.

Our software is complex and has many moving pieces - the only way to stay fast is to give our teams autonomy and make it easy for them to tackle problems. That’s why we think big when it comes to our vision for the product, but small day-to-day. Here's a look at some of the things we focus on keeping small: 

• Teams: Most of our engineering teams have one Tech Lead and one or two engineers. Keeping teams small makes it easier to execute and communicate, and gives engineers the autonomy to really own a part of the product and drive it forward.
• Communication:  Email often becomes a high-latency, long-form communication method that wastes a lot of energy both when writing of reading. For quick questions and 1:1 conversations we use HipChat as our go-to communication tool.
• Meetings: Large meetings usually end up being a big waste of time; you spend more time catching up and talking around a problem than actually diving into actionable outcomes. We prefer frequent and casual “pick-up” meetings as needed. 
• Code Repositories:  Our 1,400+ GitHub repos (about 100 of them are public) are the canonical homes for each component (frontend, backend, or library) and are where all the code, tools and relevant documentation live.
• Commits: Our convention is to make each code commit atomic, contained and logically meaningful on its own.
• Pull Requests: Concise pull requests are more digestible and provide good fodder for open, productive discussion and suggestions for improvement.
• Deployables: Each repo’s builds produce at most a couple of deployable packages which can be independently verified and upgraded as often as necessary.
• Services: We create small, discrete services that have specific roles. They fit into an ecosystem of microservices that work together to power the entire product.
• Soft Launches:  With so many customers, testing every possible configuration is impossible. That’s why we start small with early releases to a limited group of customers who are happy to help us test out new software. By using feature toggles, we can iterate on their feedback to get ready to launch to our entire customer base.
• Iteration Cycles: We ask for our customers’ feedback early and often so that we can act on it quickly and keep moving the product forward. By implementing their feedback frequently, we keep our iteration cycles short making it easier to tackle problems and make that process a constant one.

We've found that when you think small and build on daily successes, you can solve some really big problems. 

How do you keep things small so your team can move fast?