How I Got Here: Wayne MacKenzie’s path from TV meteorologist to software engineer - Baltimore

Software Development

Mar. 4, 2021 7:37 am

How I Got Here: Wayne MacKenzie’s path from TV meteorologist to software engineer

The technical product owner offers a look at his journey to NOAA and back. It's a story of waterfall, the cloud and the empathy he learned along the way.
Wayne MacKenzie.

Wayne MacKenzie.

(Courtesy photo)

The journey we take through our careers can sometimes be unexpected.

Fresh out of college, I was guilty of putting some leaders in the field of meteorology on a pedestal, thinking that their career path was easy and straightforward. Perhaps it was, but, just like social media, there is a lot we don’t see that helped them get to the current location on their career journey. So, I’m sharing my burgeoning career journey with you to highlight the value of experiences, and keeping an open mind to pivots that help to realize a personal vision.

I always wanted to be a meteorologist, ever since the fourth grade. Yup, I was the typical weather nerd. As a kid, I would watch a lot of The Weather Channel, read every book that I could get my hands on and even took the National Weather Service’s SkyWarn storm spotting class while in high school. And, yes: Twister was my favorite movie, even though there were a few meteorological inaccuracies.

I went off to college and earned my undergraduate and graduate degrees in meteorology and atmospheric science, respectively. This is where I learned that meteorologists were essentially software engineers, just terrible software engineers. While I was in graduate school, I worked as the weekend TV meteorologist at a local TV station in Alabama. This was my break from coding.

After two years, I quickly realized that TV wasn’t a long-term career for me. The requirement of moving to different areas to “move up” and the subjective nature of job performance weren’t things that appealed to me. But it was a great experience, and I’m so glad I did it. If anything, I completely lost the fear of public speaking.

After that, I decided to move into the meteorology research realm to build new algorithms using satellite data to solve aviation problems. I guess it was my calling to get back into the coding of meteorological applications. To give an example how bad of a coder I was: I turned in my code to software engineers, and they received a segmentation fault when it ran on their computers. The problem was that it used up all their memory. My reply: “Get a machine with more RAM!”

Still, it was a great experience that led me to my next job as a contractor with the National Oceanic and Atmospheric Administration (NOAA). I was doing more systems engineering work (since software engineering optimization wasn’t my strong suit) for the next-generation weather satellite program. After a few years, I became a civil servant for NOAA. I was responsible for operational products for the next-generation satellite and more product management and IT project management in this new role. It was a great job. I traveled to exciting places, met new and fascinating people, and grew as a person.


At the time, NOAA’s large satellite programs were following strict waterfall software development. For those new to software development, waterfall software development is where all the user needs (requirements) are defined early in the project, before software development begins. Still, there are pros and cons associated with waterfall development, but I learned one of the negatives, namely, how long it can take to get a change into production and out to users.

At this point, I began to learn about agile software development. Agile software development is a more iterative and modular approach to software development where you continually work with users to understand and adapt to their needs over time. This was a new concept to me, and I saw some inherent benefits that I felt could have helped with faster deployment of upgrades to end-users. Within my team, we were able to adopt more agile practices. We were still within a waterfall project, so we couldn’t be truly agile. But we could get products into production and out to users much faster than previously, thus delivering value to our end-users quickly, a core tenant of agile software development.

At NOAA, there were also some initial discussions about migrating to the cloud. At this point, I knew that to bring the value to what would be a huge culture shift, I needed to leave NOAA to experience agile development and cloud computing first hand. So I left my safe government job to join the private sector. I knew in the back of my head that I would eventually return to NOAA, bringing my lessons learned from these experiences.

The first stop was at satellite startup Planet Labs as a product manager, where they were building small satellites to take pictures of the Earth, and produce this in the cloud. I got to see rapid prototyping and lean development. I learned the need to continually deliver value and met some incredible people along the way.

Fearless meeting

Fearless team members gathered in Spark Baltimore. (Courtesy photo)

From there, I joined digital services software firm Fearless in Baltimore, where cloud migration, agile development and, more importantly, empathy was at the forefront. I joined initially as a product manager, but quickly became a portfolio manager, managing several agile teams. I learned what worked and didn’t work in leading agile teams. I received great hands-on experience with agile development. I was able to work with many folks from the United States Digital Service and 18F (the U.S. General Services Administration’s agile consulting division) and learn best practices associated with agile development. I even got the opportunity to participate in an open forum at the Eisenhower Executive Office Building next to the White House, talking about product owner training in the government. Let’s just say it’s quite intimidating walking between the Executive Office Building and the West Wing entrance of the White House.

But one of the most empowering things I learned at Fearless was empathy, and how to be empathetic to users, customers and teammates. It’s the act of listening and attempting to understand someone else’s perspective through their lens. This can be difficult to practice, but the rewards are endless. It literally ends with a truly human-centered solution that serves the needs of people. I got to experience the power of empathy first hand, and I learned so much from Fearless’ leadership.

Because of my recent experiences, I was offered the opportunity to re-join NOAA to help with the migration of large, legacy, on-prem systems to the cloud, utilizing agile software development. This is the start of the culture change that I knew would come one day when I left NOAA back in 2018. It’s an enormous undertaking, but will ultimately provide value for our end-users and get valuable science data to weather forecasters quickly to enable more accurate forecasts for the public.

It’s always important to look at the experiences you need to build and gain to realize your vision. Sometimes, this requires a deviation from the original plan to get there. But keeping an open mind will yield immense benefits for your career, and even some vital life lessons. I gained first-hand experience in agile software development. And while I learned some great technical skills on my journey, I learned an invaluable life lesson about the power of empathy and how it can drive successful outcomes. Sometimes, it’s the lessons in life you least expect that have the most impact.


Already a contributor? Sign in here
Connect with companies from the community
New call-to-action


Sign-up for daily news updates from Baltimore