How to create innovation culture in product development teams
We aspire to nurture a customer-inspired organization. In line with this vision, we consistently ideate and experiment with processes in order to optimize our skillsets and leverage efficiency. This article talks about one of our recent experiments—dedicating a single day in a month to be a ‘Hack Day’.
The idea was to simulate a hyper startup mode where all the team members come together to build something that they can ship on the same day. Over the last three quarters, we’ve had 22 Hack Days at Freshworks, delivering exactly 63 enhancements that have bolstered our products.
Here are our learnings from our various Hack Days.
1. Grooming the Hack Day action items
We spent some time prioritizing the list of work items since the scope of items that we pick can quickly derail into a bigger chunk. The importance of writing a good user story and acceptance criteria, even if it’s Hack Day, shouldn’t be underestimated. The squad ideates on the list of the items and decide on the technical approach while the designer helps with the directional mocks.
2. Getting the squad together
The squad decides when the Hack Day will commence. We chose to work together in an isolated room blocked specifically for the Hack Day to ensure we avoid any distractions.
3. The magic of coming together as a TEAM
Often, engineers tend to focus on one specialization such as frontend or backend. However, we have moved to the era of DevOps that unites rather than divides our engineers. An engineer in a team should be able to practise frontend and backend as well as automate the testing without any hindrance. Hack Day gives engineers more hands-on experience in multiple functions while staying on top of the team’s goals. For example, backend engineers don’t have to rely on frontend engineers to build their frontend. Instead, they can seek their advice to build their frontend muscle.
4. Not aiming for perfection
As much as we groom the story and understand the scope, sometimes there is negotiation, and items may spillover. In a few instances, we were able to complete 70-80% of the action item, and we still treat them as wins. It’s ok to have a few spillovers that you can pick afterward.
5. Creating your version of a Hack Day
Although two of my squads had adopted the Hack Day to solve the problems that were identified, we realized that Hack Day is also a brilliant way to solve problems with context. One of our squads decided to do their version of a Hack Day to solve their issues with the QA bottleneck. The developers had helped QA clear the backlog. It’s essential to understand what problem you are trying to solve while understanding the context.
Overall, Hack Day is a mindset and environment to spark hustle, innovation, and motivation within the teams. There are a lot of benefits associated with this experiment, and we will continue to execute it with slight tweaks to suit our squads.
