Making Hundreds of Developers More Efficient by Creating a Frontend Platform Team

Written by Julie Nergararian (She/Her) & the HubSpot Frontend Platform Team | Dec 16, 2019

Every organization holds certain values and beliefs that shape their culture. In the HubSpot Product org, we believe in moving quickly and iterating to constantly evolve with our customers’ needs. We’ve found, for example, that a small team empowered to make decisions and relentlessly drive toward their goals will deliver results and insights much more quickly than a larger group. That said, we also know that any organizational decision — like having these small, autonomous teams — will both solve problems and introduce new ones that require effort to solve. The primary challenge in this small team model is continually driving design and technical consistency across the organization for a quality customer experience and efficient development cycles. Conway's Law poses an obstacle that requires teams to collaborate and communicate effectively to avoid silos and diverging user experiences.

With this organizational structure in mind, we have 200+ frontend developers who must be able to efficiently create consistent user experiences in our product while maintaining fast-paced iteration cycles, shipping to production multiple times a day. While these teams are autonomous, they still need to work closely together. Over the years, HubSpot has organized a Frontend Platform team to provide a strong foundation for our frontend stack. This keeps HubSpot frontend developers as productive and efficient as possible in continuously creating value for our customers, and helps those small autonomous teams operate together.

Frontend Platform Principles

The goal of Frontend Platform at HubSpot is to create the most efficient and productive team of frontend developers possible. Here are the principles we hold:

Optimize for small, autonomous teams. The tools are optimized for tons of focused apps that teams can own themselves. A single team owns several repositories of separate apps and libraries. Our microservice architecture has over 500 applications and over 500 libraries. With teams owning their own apps and libraries, they are completely empowered to make iterative changes for their piece of the product, when a monolith would only slow them down.
Many teams, one stack. We believe in the benefits of shared knowledge between teams, and a fractured stack means a fractured org. Additionally, developers shouldn’t have to relearn everything when they change teams — where’s the efficiency in that?
Pick one and stick with it. When it comes to stack decisions, the Frontend Platform opts into picking one technology and sticking with it. It’s better to have an organization of developers built around being excellent at one technology than mediocre at a bunch of different technologies. By picking only one UI framework, or only one acceptance test framework, we’re able to create opinionated support, tooling, and guidance around them, making all teams more efficient in getting their jobs done.
Continuous delivery. We build a platform that lets teams deploy confidently, several times a day. Since we believe in the learnings gained from iteration, this empowers us to continue to support our customers in a rapidly changing problem space.

By creating teams around foundational areas of our stack and development process, we’ve been able to elevate the problems that hundreds of our frontend developers are working on every day. Only four developers need to think about the datepicker component, not 45. Only three developers need to think about frontend build tooling, not 300. Additionally, these specialized platform teams are able to provide the rest of organization with tooling, guidance, and real-time support on Slack, in-person, and on Zoom on their areas of expertise.

Focus Areas within the Frontend Platform

Build tooling and core infrastructure

One group in the Frontend Platform focuses specifically on frontend build tooling, from the moment developers commit their code to the moment that code is in front of thousands of customers. Our core infrastructure team dedicates their time to JavaScript bundling, minification, and dependency management so the rest of the teams don’t have to. They’re also responsible for managing how we publish our assets and get them behind the CDN (content delivery network), and offer support with low-level tooling to the other parts of the Frontend Platform.

Monitoring and performance

Building and deploying applications is just the first step: we need to make sure they’re performant and reliable. We strive to make frontend monitoring tools (such as New Relic and Sentry) top-level citizens at HubSpot in the same way we invest in our backend tools. Our frontend performance and reliability group supports all product teams with guidance on how to make and keep their apps fast. They’re advocates for product quality, and will dig into the code of our hundreds of applications to help kill tech debt, remove deprecated dependencies, and make recommendations on how to meet our various SLAs.

Testing infrastructure

Testing automation is a critical component to shipping software quickly and often. The HubSpot Product team doesn’t have a traditional quality assurance department, and instead heavily invests in continuous integration. Our frontend testing infrastructure team does not write tests: they build the infrastructure all other frontend engineers within our product organization rely on to build those tests themselves. While tools such as Selenium are notoriously flaky and hard to use, they also have a near monopoly in the cross-browser automation space. By investing heavily in libraries and documentation around this browser automation software, we ensure each team has the tool they need to ship reliable software without relying on expensive manual testing.

Common components and patterns

The HubSpot Canvas Design System comes with a standard library of React components to allow product designers and developer to create consistent, fast, accessible customer experiences. This team focuses on creating an evergreen component library that can adapt and evolve with changes in the frontend ecosystem, in customer workflows, and in the HubSpot Canvas design language. When a change is shipped to this library of components, the next time an application builds and deploys, customers are interacting with that change. This team works hard creating, documenting, maintaining, and supporting these building blocks so everyone else can focus on using those components to create new value for HubSpot customers.

Internationalization tooling

HubSpot helps millions of small businesses grow better, so it’s imperative that our software be localized and accessible in a wide variety of languages and locales. However, it’s unrealistic to expect every frontend developer to be a cultural expert in all of our marketed regions. Our frontend internationalization team is responsible for building infrastructure that connects our developers with localization specialists and translators. They also maintain an extensive set of libraries and components that make it easy to optimize the experience for our supported locales without needing to think about the nitty gritty. For example, should the given name come first or last? Is it acceptable to omit the last name altogether? How should phone numbers be formatted? The internationalization team makes sure our frontend developers get it right without too much trouble.

Developer experience tooling

With hundreds of frontend applications and libraries (and new ones being created regularly), there are many efficiencies to gain from streamlining and standardizing our development experience. First, every new developer goes through a frontend onboarding workshop where they learn the basics of using our stack and our core dependencies, such as React. Then, in their day-to-day work, our developers use our internally maintained wrapped versions of static code analysis tools such as ESLint and Prettier. Additionally, in order to support our developers as close as possible to the code, we have a custom internal extension for our primary supported editor, VSCode, with features like autocompleting our internationalization string keys and showing their translations on hover. (That said, our developers are free to use whichever editor they're most comfortable with.) Finally, when it comes time to spin up a new application, developers can quickly create one that's ready out-of-the-box to be pushed to GitHub and deployed to production using our frontend application and library generator.

Higher-level, HubSpot-specific building blocks

Frontend applications at HubSpot have common needs for foundational features and infrastructure. Another focus area of Frontend Platform is building these higher-level building blocks that an app will likely need, but that a given small team shouldn’t need to reinvent themselves. For example, a library of prebuilt UI components that can be plugged into an app and can invoke endpoints to search for and select various types of HubSpot objects managed by other apps in the HubSpot product. Or, a component that lets HubSpot customers opt into (and out of) new features that a team is rolling out. This focus area also includes providing patterns and practices for using technologies like GraphQL. By providing opinionated solutions to these common problems, we ensure consistency across the frontend and allow teams to focus their time solely on creating new value for our customers by solving new problems.

Frontend Platform, Small Autonomous Teams, and Continuous Delivery

The Frontend Platform teams are dedicated to owning and supporting core pieces of our frontend stack. However, it’s another thing to fit those teams’ maintenance work within the greater organization’s culture. We already have a strong culture around small, autonomous teams that own their own pieces of product, so we need to think carefully about rolling out changes to our core stack — it’ll affect hundreds of developers.

If the Frontend Platform were to make a change to a core library without careful testing, we would break the build of just about every app and library at HubSpot! If the Frontend Platform were to make a breaking change to a core library alongside a major version bump, that would put a “to-do item” on all of the 100+ teams to migrate all 500+ apps and all 530+ libraries to the new major version as soon as possible. In addition, that single breaking change would fracture the HubSpot customer experience and the HubSpot frontend developer experience. In this scenario, the Frontend Platform would not be a positive force multiplier — instead, it would create a situation where everyone was burdened in learning and completing endless upgrades.

In the spirit of small team code ownership, moving quickly, and crafting a consistent user experience to fight against Conway’s law, HubSpot’s Frontend Platform works toward having every project on the latest of any given library, always. This means our organization can avoid the associated costs of major version bumps.

In order to make this work, the Frontend Platform team has developed an internal tool called Mothership. Mothership is a tool designed to make it easy to programmatically test and roll out changes to a large number of repositories and projects. Mothership combines different ways of targeting the various repositories across the organization that may need a specific set of changes, clones those repositories, runs individual modular scripts within the context of that repository, pushes changes to a branch, and creates PRs for teams to review.

By automating these types of changes, frontend developers still don’t need to know all the nuances of stack upgrades and maintenance, and don’t need to carry the burden of tech debt associated with trying to keep up with endless major version bumps. Instead, the work to migrate all microservices onto the latest and greatest is a task for the Frontend Platform team, with Mothership in tow.

Conclusion

Solving for developer efficiency is solving for your product’s customers. A frontend infrastructure team can make developers more efficient by taking core problems off of their plate. With these foundational solutions in place, developers can spend their time solving novel customer problems that bring new value. HubSpot’s dedicated Frontend Platform team has become extremely knowledgable on specific focus areas, and actively supports hundreds of developers in their ongoing projects. By building and supporting a shared frontend stack, the Frontend Platform team has crafted a shared foundation for all projects in our microservice architecture, making it easier for HubSpot’s small, autonomous teams to work together seamlessly.

Interested in working on or with our Frontend Platform team? Check out our open positions.

View full post