How HubSpot Builds its Engineering Culture (While Maintaining Speed)
Download as PPTX, PDF•18 likes•28,083 views
Eric Richard, VP of Engineering at HubSpot, discusses building an engineering culture that fosters rapid learning, ownership, and autonomy among small, cross-disciplinary teams. Key practices include minimizing production hurdles, maintaining efficient deployment tools, and avoiding common organizational pitfalls like large teams and monolithic codebases. The approach emphasizes the importance of platform infrastructure while balancing velocity with ownership and accountability in product development.
How HubSpot Builds its Engineering Culture (While Maintaining Speed)
- 1. TALKING TECH Building Engineering Culture (While Maintaining Speed) Eric Richard, VP of Engineering
- 2. AGENDA 1. Introduction 2. How Do We Work (Patterns and Anti-Patterns) 3. Pros and Cons 4. Case Studies 5. Q&A
- 3. Introduction
- 4. Inspirations
- 6. Inspirations
- 10. About ● Inbound marketing, sales, and CRM growth stack ● Helping small and medium sized businesses (10 - 2000 employees) grow ● Founded in 2006. Over 35,000 customers in more than 90 countries ● Cambridge, MA, Dublin, Ireland (EMEA HQ); Singapore; Sydney, Australia; Tokyo, Japan; Berlin, Germany and Portsmouth, NH. ● Publicly listed (NYSE:HUBS)
- 11. About
- 12. About the HubSpot Product Team
- 15. How do we work?
- 17. We believe ● If you give a team a compelling mission, ● the autonomy to attack the mission the best way they see fit, ● and the support to accomplish this… ● Magic happens
- 18. Core Engineering Philosophies 1. Learning Quickly 2. Ownership Builds Better Products 3. Invest in the Platform
- 19. Learning Quickly
- 21. How do you enable rapid learning? ● UX Research Team able to vet ideas quickly with real customers ● Minimize the distance from keyboard to production ● Ability to deploy to targeted sets of customers
- 22. Technology Implications ● Extremely efficient build and deploy tools ○ We have > 5000 production deploys / week. ● The architecture has to align with teams. ○ We have > 4,000 separately deployable units ○ These components are `apis/web services`, `kafka workers`, `scheduled batch jobs` and some `on_demand` processes that we use to do migrations and other manual work. ● Hovering on the master branch
- 23. Technology Anti-Patterns ● Large, long lived branches that have a big distance from the trunk ○ Avoiding “the big merge” ● Monolithic code base shared across multiple teams
- 24. Ownership Builds Better Products
- 26. Organizational Implications ● The team is the center of the universe ● Teams are kept small (~5 people) to avoid communication scaling ● Teams are cross disciplinary (product, design, dev) ● Teams own their entire stack
- 27. HubSpot’s Trinity ● Product Manager ○ DRI for figuring out which mountains to climb ● Tech Lead ○ DRI for figuring out how to climb the mountain ● Product Designer ○ DRI for the user experience ● Co-equal partners in running the team
- 28. Organizational Anti-Patterns ● Teams that are too large muddle ownership and create friction ● No separate QA, IT, or DevOps teams that you throw the build over the wall to or that have pager duty ● No “sustaining engineering” maintenance teams that own the code
- 29. Technology Implications ● You need to provide a ton of infrastructure to allow teams to focus on solving the business problems and not get mired in the weeds
- 30. Process Implications ● There are no overarching processes (Scrum, Kanban, etc.) for teams to use. ○ Our goal is to provide high level direction, guardrails, and the coaching to achieve their goals. ○ Teams decide what processes work best for them.
- 31. Process Anti-Patterns “Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right.” http://www.geekwire.com/2017/full-text-annual-letter-amazon-ceo-jeff-bezos-explains-avoid-becoming- day-2-company/
- 33. Platform Infrastructure ● About 20% of our engineers are in our Platform Infrastructure team ● Their customer is the rest of our developers ● They own: ○ Build and Deploy Tools ○ Core Java Libraries ○ UI Component Library ○ All tooling to manage AWS, HBase, MySQL, Kafka, ElasticSearch, etc. ● This is not seen as a cost center of “operations” folks. ○ This is seen as a core differentiator to make our developers more successful
- 34. Platform Infrastructure ● This only makes sense at scale ○ You have to be able to get leverage from the infrastructure teams to make this work
- 35. Pros and Cons
- 36. Where This Works Well ● Incredible velocity on teams ○ Able to make huge progress on major feature areas. ○ Every developer can push real code into production on their 1st day.
- 37. Where This Works Well ● Tremendous ownership of the product ○ Freedom to experiment with new technologies to meet business needs. ○ Huge cultural impact: people feel like they are doing meaningful work.
- 38. Where This Works Well ● Very strong DevOps model that aligns ownership and accountability
- 39. Where This is Hard ● Cross cutting initiatives are more difficult ○ The structure was designed to limit cross team communication challenges. ○ Cross-cutting initiatives need to be broken down into a large number of team-level changes.
- 40. Where This is Hard ● Providing technical and design consistency across the product ○ Yields “eventual consistency” model for technology. ○ Rely on product design team to ensure design consistency.
- 41. Examples of Platform Thinking
- 50. Thank you!