Freshwave — The Freshworks way of working

Freshworks (formerly Freshdesk) was launched in 2010 by a small six-member team that built and launched the first product, a helpdesk tool — Freshdesk. The team shared a common vision to build the next generation helpdesk , had its business goals and roadmap clearly set, and executed the project efficiently. Nine months after the team first came together, the first product was out in the market.

Over the first few months, we gained around 100 customers, and the company moved into the ‘hyper growth phase’, and by 2015, we had over 500 employees. While it was great for the business, we employees felt like we had grown to the extent that no team knew what any other team was doing. We even felt like we were slowing down and like we were losing the agility that the six-member team had. But this agility was what brought us to where we are now. We had to find a way to bring it back. We wanted to create a framework, a way of working, that ensured that the efficiency remained intact even as the team scaled.

We had a lot to lose if we didn’t come up with a framework quickly:

• Functional silos would begin to creep into the organization. Each function starts perfecting their area of work, and multiple independent teams focusing only on their work rather than on the overall task might cause delays in the final output. But we knew that we should put the overall company’s and the customer’s interests ahead of the team’s.
• A divide emerges between engineers and customers. Engineers tend to get siloed, focusing on the engineering aspects of product development, and the vision of creating user-centered product blurs.
• Iterations are slower as engineers tend to take up features as a whole rather than splitting them it into small items and add value to customers iteratively. Splitting tasks will also enable teams to ship features and updates often and add value to customers with a shorter cycle.
• The agility that we had when we were a six-member startup was, however, core to our success. We wanted to be an ‘eternal startup’.

The agility that we had when we were a six-member startup was, however, core to our success. We wanted to be an ‘eternal startup’.

And thus, Freshwave was born.

Freshwave is an initiative to foster a ‘happy work environment’ and make efforts to bring back the startup mode of working wherever possible.

Key elements for the foundation

Introducing a new framework, and bringing about a transformation meant relentlessly unlearning, relearning, and adapting to multiple changes within the company while still maintaining the culture of the organization and the foundations on which the company is built.

We studied different Scrum models, examined different tools in the market, and customized a framework.

We organized ourselves into multiple cross-functional teams, having small squads within that can be autonomous, move like ninjas, and get things done.

We kickstarted a quarterly exercise called “Eagle”, where we directionally align the team’s roadmap with the organization’s broad goal, and collaborate with customer-facing teams. The entire product development team comes together to understand the direction each team is taking, why we are building certain features, and what impact they will have on the business.

We called this exercise ‘Eagle’ taking inspiration from the bird’s trait of ‘having an extremely powerful vision’. The bird teaches us to remain patient, but ever-present, always keeping our eyes to the future, while not forgetting to take note of our present surroundings. It also reminds you that when opportunity strikes, you need to be the first one to see it and you need to move fast.

The goal of Project Eagle is to identify and publish one global prioritized list across the product so that we can concentrate on the customer’s broad requirements and wants rather than focusing on certain modules and features. Our customer-facing teams — sales, marketing, customer success, support — speak to them about their needs, and the product managers and engineers align our roadmap based on broad themes that emerge from these meetings.

Doing the transformation right

Setting up a new framework is a lot easier than actually implementing the changes and bringing about a transformation in the way things work.

Here are some things you should keep in mind during the phase:

Providing big picture: It’s always important to let teams know why there’s a change in status quo, especially if it’s a change in team’s ways of working. At Freshworks, we often hold ‘all-hands’ meetings where all employees including the leadership members gather to discuss where things stand in the company and what direction the company is taking. We also run online forums that allow employees to interact and pose questions to the leadership teams.

Take advantage of co-location and boost collaboration: It’s important to ensure that communication and collaboration between teams is strong because silos emerge if there’s no communication between different teams and functions. If you have most of your employees in one location, take advantage of it and make sure different squads work together rather than just interact virtually.

Foster autonomous culture: Teams should be able to decide for themselves what problems needs to be solved, why they need to be solved, and how to do so. We encourage this, and provide an environment to experiment and move fast. We enabled the teams to find ways to make this work, and came up with an idea of ‘Hack Day’, a one-day hackathon to take up items that can be developed, tested, and reviewed within just a day.

Structure and ceremonies

We started with setting up multi-dynamic teams, creating backlogs, establishing a consistent feedback system, and organizing sprints. We usually keep our teams pretty lean and each squad has one product owner, one UX designer, four product developers, and two test automation engineers.

Our sprint cycle consists of the team members collaboratively creating a list of tasks to be accomplished, reviewing and prioritizing the backlog items, planning the functionalities that we will be building over the next two sprints and agreeing on the number of items that should be completed in the current sprint cycle. The backlog is continuously updated — irrelevant items are deleted, newer items are added, the priority of items is re-assessed, and big priority items are split into smaller modules.

While we were able to get our teams to work on a rhythm that helped us establish a baseline for our ways of working, we started analyzing the different improvements, and noticed how ceremonies add value to teams.

Here are some of the takeaways from the ceremonies:

Stand-ups: We hold daily stand-up meetings, — a 15-minute time-boxed event — a checkpoint for teams to inspect and adapt in order to achieve the sprint goal. However, the stand-up will turn redundant if the work items are not broken down well during the meetings. So, ensure that the different items are broken down so the teams are able to identify risk and mitigate them accordingly.

Estimations: We use planning poker to facilitate conversations between team members during the planning to estimate the user stories. The focus should not be on the numbers but rather the relativity, complexity, and unknowns. The aim is to reduce the ambiguity of the work items for the team. This is also a great opportunity to help teams to upskill themselves since when we talk about how can a five point user story be a three point for another developer and how the team can start improving learning from each other.

Retrospectives: Retrospective is one of the strongest techniques that teams can use to inspect, and adapt for a continuous improvement. The standard questions of what went well, what didn’t go well may quickly turn into a monotonous activity that teams will stop doing it until they feel it’s adding value. The major outcomes for a team with retrospective is to have limited action items, and having the directly responsible individual (DRI) mapped to items so that the teams can experience how small steps are helping them to improve. You could also bring in visual metaphors, fun retrospectives, and other such techniques to help the team collaborate and make it sustainable.

Retrospectives from our journey

It’s been two years since we started the transformation at Freshworks with the Freshwave way of working.We would like to share some of our retrospectives from the journey:

Cross-pollination over standardization: Teams should be able to choose their ways of working. Give them a framework but allow them to improvise. Cross-pollination trumps enforcing standardization across teams. At Freshworks, while we still have major products adopt Freshwave, the ways of working are very different from one product to another.

Break the work items into smaller pieces: If there is a large story which is commonly called as “Epic”, it should be broken down into multiple user stories which should be independent, testable, and shippable. However, this is a difficult part to perfect, since slicing the stories in a meaningful way and ensure that it’s just sliced in the right amount is key to ensuring that we are able to add value to customers frequently.

Limit WIP: Setting limits on WIP items allow you to complete single work items faster, by helping your team to focus only on current tasks. We follow a thumb rule that at any point in time, a squad will work only on one epic. This will ensure the teams are able to focus on that item and ship it as a team before picking up the next item.

Upskilling: We constantly pursue people development, and provide an environment for all our employees to upskill themselves. We encourage developers to become full stack developers, drive entry-level engineers to participate in contributing to developments without inhibition, and allow developers to participate in system design to develop features.

Foster cross-functional culture: We encourage teams to work across functions but While we don’t expect our squad members to be perfect in both front-end and back-end, they do step in and pick work up when there’s some critical, time-sensitive work that needs to be done.

Measure happiness index: It is important to consistently measure the happiness index across teams. We hold anonymous surveys during our all-hands meetings to address concerns, and also carry out surveys with a diverse set of questions to find out if they are happy about the work they do and try to tease out the things that need to be improved, such as collaboration, trust, motivation, or accountability.

This is the second of a series of posts we are writing about the engineering culture at Freshworks and how we are scaling our engineering efforts. You can read the first one here.

About The Author:

Anand Vaidyanathan is an agile coach and lead technical program manager for the Freshservice BU at Freshworks.

This post was originally written on the Freshworks blog.