Blog Post Banner Image
17 March 2020

Cracking the innovation time code

By Karen Geiger

As the Chief Development Officer for SS&C Advent, I often get asked by clients and partners how I incorporate innovation into our product development process. Google famously allows its engineers to spend 20 percent of their time on projects that interest them, also known as “innovation time.” As most engineers know, innovative ideas don’t materialize simply because you’ve carved out space for ideas to spark. Innovative ideas come about in the course of our everyday work, as we speak with customers, work to solve complex problems, and make connections between our work and what we see in the world around us. Most of these ideas remain half-baked because we are too busy with our day jobs to take them further. That’s where innovation time comes in. It gives engineers dedicated time to tinker with ideas, to research new technologies and experiment with solutions that have as great a chance of failing as they do of succeeding.

Years ago we considered the idea of dedicated innovation time. We weren’t as bullish as Google, but we thought we could reserve half a day each week for free-form projects. But here’s the thing – we are an enterprise software company servicing some of the largest financial institutions in the world. Our engineering team is incredibly customer-focused, and most team members regularly work more than 100 percent of the time to meet the needs of our customers. That half day each week? It was far too easy to get absorbed by critical work that more immediately served our clients.

While our clients certainly want their most urgent needs met, they also want to know we are investing for the future. To that end, we’ve settled on an innovation time model that works well for our business –twice-yearly hackathons. During a hackathon, engineers get 48 hours to dedicate to a business-related passion project. We’ve found that it’s much easier to protect two days every six months than it is to protect half a day every week. Engineers have used hackathon time to experiment with machine learning models, natural language processing, speech recognition technology, graph databases, elastic search, containerization and more. We award prizes, but not based on the business viability of the output. Instead, we evaluate projects based on how novel the idea, whether the team went out of their comfort zone, and how substantive the experiment or prototype.

Over the past couple of years, numerous hackathon projects have evolved into real product enhancements, including machine learning that predicts user actions in our Lumis product, a global search feature in Genesis that allows users to navigate to nearly any screen with just a few key strokes, and natural language processing that auto-tags research content in Tamale. Though most of our hackathon projects never see the light of day, the practice of pursuing innovative solutions, experimenting with new technologies, and testing out prototypes cultivates a culture of curiosity and mindset of challenging the status quo. The learnings from hackathon projects also plant seeds that may evolve into future solutions, perhaps for problems we may not have even identified yet.

With technology advancing exponentially faster than it did a decade ago, technology leaders must find a way to incorporate time for free-form experimentation. There isn’t a single right way to do this; find a way that works for your business that does not compromise critical business deliverables, and ensures that innovation is always in service of building better solutions for your users.