For over a decade, I've strived to champion innovation in every team I've been a part of. I currently serve as a Technology Solutions (TS) innovation leader at the American Institutes for Research (AIR) – a behavioral and social science research and evaluation not-for-profit. I'm most fascinated by the unique ideas and culture change that arise from a successful innovation implementation, but establishing and nurturing such a program at a frugal organization in the midst of leadership shake-ups required a hefty dose of inventiveness itself.
During my annual goal-setting sessions in early 2018, my mentor and TS VP at AIR encouraged me to pursue a desire I had expressed for close to a year – to run an innovation program. I wanted to ensure that our team was positioned to provide clients the best solutions available and believed that an innovation program was the means to achieve that goal. Over the previous three years, I had earned the trust of colleagues and gained a solid reputation by implementing end-to-end development lifecycle process improvements in addition to running a successful DevOps shop and shifting client technology solutions to a cloud-first strategy. My mentor affirmed that I was primed to step-up to this new challenge. However, a company-wide re-org several weeks later saw his ouster. Due to missed revenue forecast, new technology leadership made it clear that high billability along with cost-cutting measures were a priority. An Innovation team budget was out of the question.
I ran a determined campaign for the next several months to convince technology savvy researchers spanning education, health, and workforce areas to contribute funds to an innovation project if not a program. One proposal that gained initial traction but ultimately fell through involved re-architecting data-sharing and harmonization efforts of rural opioid response grantees. I had proposed using AWS Glue to crawl through disparate data sources and construct a data catalog for ETL (Extract, Transform, and Load) processing, but the approach was deemed high risk due to the lack of past performance and expertise in the relatively novel AWS technologies, and the potential high cost of the learning curve.
With similar results on other proposals, I switched tack and attempted a more subtle and budget-friendly approach. Our technology staff on average were required to hit 75% billability which equates to 40 hours per month allowance for overhead activities – generally utilized by staff for non-billable correspondence, team meetings, and training. The eureka moment was to capitalize on the already approved and budgeted overhead hours in order to execute innovation projects. After obtaining approval from leadership, I assembled a small group of highly motivated developers willing to sacrifice a bit of time to attempt this experiment. I laid out several ground rules: billable client work would trump overhead innovation projects; innovation projects would need to produce a minimum viable product (MVP) within the overall 40-hour constraint; if at any point the team determined that an MVP could not be realized, the effort would be thoroughly documented and the project temporarily scrapped; and most importantly all innovation projects must be clearly traced to AIR's mission and vision. I called these projects 40-hour Innovation Mini-Projects and affectionately labeled the program and team the 40IMPs.
In order to instill a culture of innovation, I led lunch-hour brainstorming sessions and encouraged all development staff to document their ideas in weekly status reports which included questions such as: What have you learned this week? How have you gone above and beyond? What positive feedback have you received and/or given? How would you make things better? If you had unlimited funds, what would you want to work on? As we continued to generate ideas, an ad-hoc internal client request for bulk e-mail options for surveys grabbed my attention. The client research group had previously used Mailchimp and ExactTarget – e-mail marketing platforms – to send surveys, but were not keen on sharing recipient e-mail addresses with those vendors. This project appeared to be a great candidate for the 40IMPs, especially as I had independently been exploring cloud-based e-mail services for DevOps notification functionality. After gathering detailed requirements, I designed a pared-down cloud-based serverless application using AWS Lambda, SES (Simple Email Service), and S3 (Simple Storage Service). The system would allow a developer or client to create a mail template (text or html file) with tokens, and populate a CSV (comma-separated values) template with recipient e-mail addresses and columns with data for token replacement. The CSV and mail template files would then be uploaded to S3 which would trigger a Lambda function written in C# that would process each row in the CSV and send the e-mails using SES. We built, tested, and rolled out the application in under a week. The minimum learning curve for clients, no recurring monthly charges, low-cost pricing, and affordable labor hours to operate and maintain the application earned the team a feather in the cap and paved the way for future successes.
Favorable client feedback, critical vetting of ideas, a fail fast philosophy, and tangible realization of benefits helped to convince leadership to back the Innovation program. We continue to prototype and go-live with various applications and products. Highlights include a two-way SMS (Short Message Service) nudge bot for use in student and classroom outcomes, secure video hosting services for classroom-based initiatives, and Flutter and Xamarin mobile starter-templates for social science research initiatives.
I attribute the continued success of the Innovation program to clarity of vision, discipline, creativity, luck, and most of all to a team willing to step outside of their comfort zone and expand their horizons. I am incredibly proud of the steady shift in developer perception towards systems awareness and openness to continuously learn, improve, and innovate.