Scaling an engineering organisation: It’s no easy feat
In 2010, Freshworks started as a six-member team working tirelessly on the first version of Freshdesk. Over the next eight years, the team has grown to nearly 2000 members. We’ve launched nine products covering the gamut of customer engagement and we have now created a Customer Engagement Platform (CEP). It has been quite a climb. We’ve successfully raised $249 million in these eight years, with a valuation of more than $1billion from some of the marquee investors in the world today. Simply put, we have built several products over the last few years; hired and onboarded hundreds of engineers, and built processes that have helped us scale. This is our story of how we did what we did.
Rallying Engineers
Engineers not only work with technology to build products that solve problems but play a crucial role in generating business value. So, it was essential to think about how we could function as a team and ensure that there was collaboration across the various team members. Also, we had to ensure that we act nimble and stay on top of things while scaling from being a small team to a large organization with multiple interdependent teams.
Initially, our founder and CEO, Girish, was spearheading the product management, to weave the functional specifications. Shan, our co-founder and CTO, was the architect and worked with the spec to ideate a solution and had distributed the work among the three developers on the team. Kiran, our director of technical operations, had taken care of infrastructure requests while Parsu had taken care of the design requirements. They shared a vision, and had the agility that translated into quick execution of business goals. Together, they had built our first product – Freshdesk, a customer service software.
As we expanded, we built our teams around the major functions—product management, frontend development, backend development, and quality assurance—grouping engineers based on their skill set.
Simultaneously, our customer base grew steadily. By 2014, we had scaled our sales team to amp up our selling velocity. The sales team was bringing in a lot of requests for new features or bug fixes, but we were unable to keep with this increase in the number of requests because we weren’t hiring enough engineers then. Therefore, over the next two years, we worked on proportionately scaling our engineering team. What used to be a small team consisting of a handful of people, now had expanded to become large distributed teams.
As we scaled our teams, we went through multiple phases: conception, initiation, analysis, design, coding, testing, deployment, and maintenance. This turned out to be the Waterfall model of engineering design, where each phase has to be completed before moving to the next step in the sequence. This model worked for us for the first few years since each functional team was small. But later, as we grew, we realized that the cycle times were getting longer; we were slowly losing the flexibility to iterate at a granular level as the deliverables from each team were large. Any learnings from the later phases would have to be reworked through the entire process, and this resulted in an increase in the time taken to release features for our customers.
During the initial days, communication among teams was not a challenge given everyone worked under one roof. Again, as the teams started scaling, each team began functioning in a silo, focusing on perfecting their chunk of the feature release. The teams weren’t communicating as much as they used to. Information was scattered across functions although it was still aligned towards the same product goal. Integrating the efforts of various teams into a coherent feature release was not just an engineering task; it was becoming a communication challenge as well. We realized that we had to move beyond the Waterfall model as we scaled further.
What next?
We wanted to unify the product development efforts by bringing the product owners and the development team together to have one shared vision across teams and build a better product for the users. Retaining our entrepreneurial values was cardinal. We always believed in transparency, cultivating mutual trust, and speaking up, but never wrote these down in our office walls because we spoke that language and it was an integral way of working. As we grew, we wanted to adopt a framework that aligned with the culture of our organization. We decided to work on the Agile framework to explore the fit and then adopted the framework by customizing it to cater to our strengths.
We had kept in mind three fundamental tenets while coming up with what we called Freshwave.
Alignment
We reorganized multiple cross-functional teams into squads, and this brought the business and engineering functions together. It enabled the teams to build a stronger product and take it to market. We no longer had silos; people from multiple functions were grouped together to work on the same goals.
Collaboration
Once we got everyone aligned, people started exchanging feedback and that helped us improve our processes. With quicker ways of prioritizing, we were able to build features and incorporate customer feedback.
Speed
The new model of Freshwave gave us renewed energy and helped us ship features with agility. We were able to prioritize our work, build features incrementally, and continuously deliver it in smaller pieces. Breaking down the larger team into squads helped increase our velocity.
Once we adopted our own Freshwave model, we transformed and empowered our team to take decisions and set their own goals. This enabled teams to act with agility. We also had teams organizing themselves to achieve goals while contributing cross-functionally. For instance, if someone needed to build a front-end layer for a feature, it didn’t matter if he/she was a back-end developer; there were no longer any self-imposed restrictions based on roles; everyone was able to do the task that needed to be done, regardless of the function. The reorganization and realignment helped us bring teams together with the right skillset and build what the customers were expecting from us.
With respect to delivering features, initially, we would release the software only after all the functionalities were developed. However, today, with continuous delivery, we develop in a way that means the code could be released to production even if the feature is incomplete, using techniques such as feature toggles. The focus was on shipping bug-free code in regular release cycles, thus increasing the velocity and rate of deployment.
Freshwave was just one among many initiatives that helped us build a solid foundation for our engineering teams to scale their processes effectively. Many other initiatives came together to help us realize the goal of shipping fast with a customer-centric approach. The vision we had while initiating the Freshwave moment was to retain the ways the original team that built the Freshdesk product. We wanted to remain a startup in every way of working – be nimble in taking decisions, own the work we did, and work together with a common vision to deliver moments of wow to our customers.
In the subsequent parts of this series, we will deep dive into our various engineering initiatives such as
- Freshwave (agile model of development)
- Global Priority List (GPL) (quarterly prioritization across the company)
- i2P (idea to product – the Freshworks style of building products)
- Aspirations (a company-wide forum to create transparency and showcase what each team has achieved)
- People development programs (tailor-made learning and development initiatives)
- Technical Architects Committee (TAC) (core committee to discuss architectural reviews)
