How to Encourage Innovation in a Large Organization

Problem

A year ago, when I was working at a converged payments solution company, I spearheaded an effort to introduce a company-wide, five days-long hackathon that unleashed innovation and motivated our engineers to come up with bold and novel solutions. For a while, I was noticing that many engineers were nearing burnout and that the repetitive nature of an engineering job was starting to take its toll. In a situation where we had to continuously ship features and keep the lights on, not much room was left for innovation. I felt that engineers were craving for an opportunity that would allow them to tinker with things, try-and-fail, or experiment with creative approaches.

Actions taken

We decided to organize a five-day virtual hackathon, a.k.a. The Payments Innovation Week. We chose to go with the Payments BU, which was the largest and oldest business unit with more than 200 engineers, designers, PMs, and QA engineers. The very prospects of running an innovation event involving 200 people for five days sounded exceedingly exciting. I knew my engineers: if they didn’t have to participate in standups and sprints and could instead solely focus on innovation, they would make the most of the given freedom.

Once the initial idea was floated in management circles, I put together a brief concept note. It didn’t take long for leadership to realize that running this kind of event would benefit us greatly.

The main concern I had was how to ensure accountability, given that we would be organizing a virtual hackathon and that it would last five days. It was the first time I did it in an all-remote setting, and I had to ensure that people didn't end up building something entirely unrelated to what we needed and could benefit from. This was where the themes came to play.

By identifying a number of themes on which teams would work, I put in guardrails that allowed people to operate freely and with full flexibility. Guardrails ensured that when the evaluation day comes, we would have an uniform evaluation as well as relevant and tangible outcomes. Selecting the right themes was critical.

We considered a number of criteria for themes, but one that stood out was that it should be something that could easily be shipped into production. Sometimes we didn’t need innovation; we knew what we needed to fix, and we wanted to experiment with different solutions. Those were low-hanging fruits -- if we could fix them, our customers would be happy. Other criteria focused on pure innovation, the feasibility of the solution, if it was production-ready, if it was unique or novel, how delightful it is for a customer in terms of UI and UX, etc.

We set up themes and came up with a fancy name for an award. Essentially, we provided engineers a track to race on. That also allowed us to assess uniformly everyone who was running on that track. Having tracks was a way to deal with controlled chaos. I had to ensure that people were not slacking off. One of the most serious concerns I had was how to bring such a large audience together once a day. I decided to organize side events like magic shows and fun activities for the team, keeping the mood light and people in the loop. We rolled out some food coupons for people to order their food and send them out some goodies to help them get them in their zone.

Next, we assigned mentors to all the teams. A team should work with a mentor on what their pitch should look like in terms of demo-readiness, ensuring that they would be able to digest the project they were chewing for four days. Mentors would help the team set the right milestones, break down the problem in appropriate pieces, etc.

After four days of innovating, our engineers lined up for nine hours of demoing that included 50 teams. We had to split them into two tracks with two groups of judges, each assessing their track. The judging panel consisted of people from business, technology, finance, and product, each weighing in on from their own standpoint. We also hosted AMA with company leaders such as the VP of Engineering, who would candidly answer all questions our engineers asked.

In the end, we made sure that nothing would get dropped, which is often the case if you don’t have the right cadence to ship things into production. People would get back to their day-to-day work, and things would never end up in production. We followed up with the teams multiple times, ensuring that they got supported by their managers to push those things through production. Two to three weeks later, 60 percent of those ideas were in prod.

Now, I can proudly say that what we did in those five days would otherwise take us a few months.

Lessons learned

• Engineering work can sometimes become monotonous, and a prolonged state of repetition can impact creativity and innovative spirit. An opportunity to participate in a focused but still flexible and experimental event is critical to motivate your engineers and encourage their out-of-the-box thinking.
• Freedom should always come with boundaries. Having pre-created themes is a powerful tool to organize work in a controlled-chaos environment.
• Carve out enough time for innovation and then think through what success criteria for the program would be. What I too often saw was that success criteria become an afterthought, not a pre-thought. You should know your success criteria and then work backward.
• Hackathons come out of a team effort. While one leader should be driving the initiative, most activities should be delegated. The same goes with teamwork, which best embodies the collaborative nature of engineering effort.