Asking for innovation Published Dec. 3, 2013 By Capt. Shane Gillies 14th Weather Squadron ASHEVILLE, N.C. -- The common complaint from innovators is that the bureaucracy just doesn't understand us. We have great ideas, but "they" don't seem to care -- "they" being our bosses and the bureaucracy around us. When the discussion turned towards bosses who do not listen to our ideas during Howard Lieberman's breakout session on Accelerating Large Enterprise Innovation at the first-ever Defense Entrepreneurs Forum in Oct. 2013, fellow attendee Navy Lt. Cmdr. B.J. Armstrong made a poignant comment. "In many cases, we are someone's boss," he said. "How are we encouraging innovation?" So how did I get innovation as someone's boss? I asked for it. The 14th Weather Squadron, formerly the Air Force Combat Climatology Center, is the defense department's most complete repository of historical weather information. An active duty unit located in Asheville, N.C., and collocated with the National Climatic Data Center, the 14th ingests approximately 1.5 million weather observations per day from around the world. These observations range from surface readings at airports to upper atmospheric conditions recorded by aerostats and much more. Once ingested and quality-checked, this weather data is used to build applied climatology products that serve the DoD. In March 2013, I shifted from developing long-range forecast methods for the squadron to leading a team dedicated to ingesting weather observation data. My new team, consisting of several enlisted weather specialists ranging from E-4 to E-6 as well as a couple of GS-12 civilian meteorologists, was close to finishing a three-year development of a brand new data ingest platform. They were accomplishing the ingest mission without any issues, but the retiring of the legacy ingest platform and introduction of a new ingest system had left a considerable amount of overhead and stale procedures -- plenty of areas ripe for innovation. Shortly after taking over the team, I unveiled what was essentially my commander's intent. As a meteorologist and weather officer brand new to the team, I accepted that I was not an expert on data management, but I wanted the team to continue performing at a high level. Yet, I also wanted the team members to seek ways to make their jobs easier. To guide the team, I communicated three vectors: 1. Safeguard the Data 2. Problem-Solve Deliberately 3. Innovate These were my expectations for the team in the absence of any other specific tasks or guidance. The first two vectors were intended to emphasize the continued mission of ingesting weather data and protecting against data gaps. The first vector is the very reason for the section's existence. The second vector stresses the importance of acting carefully with the data. In most cases, if we accidentally delete or otherwise render the data in our database unusable, that data is gone forever. We routinely back up data to tape as a safety precaution, but recovering data from these tapes is time-consuming. Fortunately, the vast majority of the ingest processes are automated unless there are network issues or we receive bad data that violate constraints. Thus, the third vector, innovate, targets the time when the team was not troubleshooting data issues and could instead develop innovative solutions. Rather than simply tell my team to "innovate" and leave it at that, I defined the type of innovation I sought in an effort to set the left and right lane markers. The catch phrase that I used was "better, faster, cheaper." This was intended to keep the team focused on specific types of end states, yet not specific results so as to not discourage good ideas that I could not foresee personally. I encouraged them to think about what they did on a routine basis: what were they doing that they hated and how could they could make those things better? Given the number of stakeholders submitting and using meteorological data in the U.S. and around the world, I realized that game-changing ideas affecting the data would likely not gain traction. The emphasis on routine tasks kept the innovation ideas grounded in reality and closer to execution. I also pushed my team members to identify how much time they were saving with a new process. What was the time cost of developing and implementing their solution and what was the expected benefit? This enabled me to ensure that their time investment in the solution would not far outweigh the potential benefit, not to mention assist me in communicating to higher levels of the chain of command the work that they were undertaking. More importantly, though, answering this question forced them to think through how they would execute their idea because without execution, it would simply remain an idea. As long as they could articulate a favorable cost-benefit ratio, they were green-lighted to innovate and execute. And innovate they did. Some of the implemented solutions include: An E-5 and E-6 tackled a process of manually notifying weather flights that have not sent their automated daily weather forms in a timely fashion. The E-5 learned Python and, with some assistance from an E-4 programmer in the squadron, developed a Python script that reads an inventory spreadsheet and automatically sends emails to the weather flights in question, notifying them of the exact days that are missing. The automated process saves approximately eight man-hours per week and enables the E-6 to instead dedicate time to contacting repeat offenders and to develop materials to disseminate to reduce errors in these types of weather forms. An E-4 developed a Microsoft Excel macro to identify and extract key values from different, manually created weather forms, saving nearly three man-hours per month in tedious hand-keying. This came after she had taken initiative to create a how-to guide that was sent out to weather flights to reduce data entry errors at the source. The entire ingest team collaborated to design a metrics slide that communicates a more robust picture of the value the ingest team provides while reducing the amount of time that was required to build the previous slide. To further reduce the amount of time required to build the slide, a GS-12 developed a script to compile all of the required data counts for the most recently completed month. This metrics slide is briefed monthly to higher headquarters. As each new innovative idea was conceived and executed, we briefed it within the section. The ideas and resulting benefits were then communicated to the rest of the squadron and up to higher headquarters. The visibility given to these implemented ideas then spurred additional innovative problem-solving--a snowball effect. Each new idea reinforced a culture of innovation, encouraging team members to become more comfortable with proposing innovative solutions that might be "outside the box." I asked for innovation and my team wholeheartedly embraced it. They learned that not only was it okay for them to develop innovative solutions, but it was highly encouraged. Instead of "what we're doing is stupid," it became "here's how we can do it better, faster, cheaper."