Me

Hi, I'm Grayson. I have worked in software since 2012 when I got my first job building an apple database. I have worked in technology since 2011 when I got a job at the U of M help desk aiding frantic undergrads getting connected to the internet. I have loved computers since 1995 when my dad first got our house connected to the internet and I weaponized it to get him to stop smoking.

I've also always been an avid outdoors enthusiast ever since I threw my first Mickey Mouse fishing pole into the lake at 2 years old. Some of my best memories are camping with my family in some of the best state parks the country has to offer in Minnesota. I have hiked and biked all over the country, most recently clearing the Highline trail in Glacier National Park. It is hard to reach me most weekends since I'm usually somewhere without cell towers in the vicinity.

Professional Career

It all started for me when I went to college for Computer Science at the University of Minnesota, Twin Cities and landed a job as a technical support representative. This was largely valuable in the sense that I interacted with technology users and customers on a daily basis and learned how to empathize with them and understand their needs. Sadly, I was unable to do much to improve the usability of the software and instead needed to sit by and just help them as issues arose. This became frustrating for me and I started looking for a better way to solve people's problems.

While I was still working for the Office of Information Technology, I managed to land my first software development job - building an apple cultivar database for the University of Minnesota Extension. It turns out that apples are very important at the U of M. Have you ever eaten a Honeycrisp? They are responsible for that one as well as many others. Their ongoing research makes them one of the top resources for orchard operators across North America, so imagine my surprise when I got the job to build a free online resource to select the most appropriate cultivars for a given hardiness zone. Here, I figured out how to work with stakeholders and operate within a large academic institution where there are limited resources and stringent branding requirements as well as how to find resources I need while working as a team of one. With a weekly budget of 10 hours, I figured out how to be scrappy and resourceful as an engineer, and in the end I delivered a functioning product that was in production for years.

Before this project was done, I needed to find a position that was a little more stable than 10 hours a week, and I was hungry for more problems to solve. That's when I got a job building and managing all the web properties for the Earth Sciences Department, the St. Anthony Falls Laboratory, and the Polar-Geospatial Center at the U of M. During my tenure there I created and supported several public-facing websites in Drupal, developing PHP extensions to fill gaps in functionality along the way. While fulfilling this as my primary job function, I also served in a technology and hardware support role sometimes stepping away from my desk to build PCs and pull wire for the laboratories and offices we were charged with. I even built a javascript extension to improve the usability of a government database, which is pretty cool if you ask me.

It was here that I really began to solidify my style as an engineer. I worked on a team of other student engineers, but because I was the only one who did what I did I was tasked with becoming the expert in my position in a matter of weeks in a technology I had never worked with before with nobody around to really guide me. This is not unlike my job with the Extension, but it struck me that here I had more than one stakeholder to disappoint if I could not achieve. I also learned that without a product manager or something similar to facilitate the communication with the users, that job was most appropriately mine. I would spend as much time as I could with the product owners for the web apps to really make the product exactly how they wanted it, much of the time going as far as making changes and building out features while sitting with them - this turned out to be an extremely effective feedback loop and is one I prefer to use still to this day. Here I also learned the value of (although I didn't know there was a name for it at the time) a minimally viable product and just-in-time delivery.

Years later, I know now I was sowing the seeds of the most important learnings of my career:

• You cannot know everything. The most important thing is to always be learning and to be learning quickly. My coursework and career has allowed me to learn how to learn.
• Few things are more important than user needs in developing software. You are trying to effectively solve their problems, they do not care how complicated or ingenious the solution is unless it changes how they interface with it.
• The best way to figure out what the user needs is to interface with them directly.
• There are ways to build good software quickly and with minimal effort and human-power. These ways usually involve intentionally minimizing complexity and feature-sets down to the fewest and most-useful.

It was my junior year of college when one of the most valuable opportunities of my life presented itself in the form of a little medical-tech startup called Homestream. As a young man of 20, I was a little concerned when I found out it would just be the founder and myself working on a single-page application to do the improbable: address a global issue known as the "Silver Tsunami" which recognizes the population is aging and our worldwide health infrastructure is not equipped to handle the coming influx of senior citizens. I was not, however, concerned enough to say no to the opportunity to finally make a real difference using my skills in an environment that needed them most. For me, it was a chance to be innovative, scrappy, and to find inspiration and purpose in my work. I spent two years at Homestream (which was renamed BeBloomin in that time), a rich period in my life that I've come to recognize as the true beginning of my career.

Within weeks of being there I was up to speed and in charge of a J2EE web application and all its users. I had never worked in a Java web framework before, but I picked it up quickly. I had to. The penalties for failure at a startup are more pronounced, so you need to succeed. Back then I believed that meant getting it right the first time, and I would not learn the value of failure until I inevitably left the company. In the meantime, I gathered as many valuable lessons as I could, mostly the value of a crispy value proposition and executing on that promise. Even then I believed we had to start doing one thing incredibly well to have the opportunity to do more good things, but at that time I didn't have the words for it. My time at BeBloomin came to an end in late 2015 and I opened a new chapter as an Application Engineer at Thrivent Financial.

Thrivent offered a broad new opportunity. As the only engineer at BeBloomin, I found myself wanting to get direct in-market feedback on many of the UX design aspects of the application, but had little time or skillset to do so. My first two days at Thrivent, I got funneled into a conference room to learn about Scrum and Agile in depth for the duration of the the days. A few weeks later, I was sent to Optum to learn about Lean Startup and the mechanization of innovation. It was a dream come true! On top of it all, I was taking my first steps into a cool new world which I had only come into contact with once before: Rapid Application Delivery. In the case of Thrivent, I got to start digging into OutSystems - my tool of choice for the coming 4 years and counting. With OutSystems and my newfound knowledge and colleagues, I was now participating in the business and technology innovation process from start to finish.

I immediately took over the role of main administrator and sole developer on the OutSystems platform, but soon my role took more of the form of Center of Excellence leader for the platform. Part of our task in the business innovation group of Thrivent was to bring new technologies and frameworks into the broader company. We had success bringing in Agile, Scrum, Lean Startup, Playing to Win, Jobs to be Done, and Human Centered Design as accepted work and innovation frameworks. We also brought technological changes to Thrivent which were harder to sell. We worked hardest to sell Rapid Application Delivery into Thrivent because it would shake up the way the whole company looked at software development.

As the years ticked on, I would say I led, designed, architected, and built or helped build in the realm of 15-20 production web applications. It was a game changer when OutSystems released platform version 11 and we started building native mobile applications. One of my major achievements at Thrivent took place shortly after this update. We were keeping a "wall of empathy" sort of thing in the office by duct-taping little slivers of paper to the wall with stories we all gathered from the road while interacting with customers. We had a goal of gathering in the range of 500 of these before the year was out, but this was clearly a poor solution (both to me and the facilities department who were not pleased about the duct-tape walls) which stood to be revolutionized. I got permission to chase the idea, and 1 week later I introduced Curiosity - the learnings gathering, publishing, and tagging app. It ran on Android and iOS and would install directly on all employees phones so they could gather learnings on the road, offline, whatever condition they were in. It also included a web app which did all the same things. Eventually we introduced analytics and gamification to incentivize people to keep track of as many of these learnings as possible. Our president caught wind of it and was constantly on the app reading the stories.

My time at Thrivent has been the most learning-rich experience. When I started at Thrivent, I had only heard of OutSystems once from a friend who built their whole business on its technology. Now, I am an active member of the community, an OutSystems Ambassador, and on the tech advisory council. I have also finished my first pitcher of "Customer Experience Kool-Aid" and I am not sure I could ever go back. Gone are the days of waterfall-style, old-school development where someone in a suit tells someone in a tie to tell a group of developers in a windowless cube farm to build the completely wrong thing in 9 months for $2 million. It is time for developers to take an active interest in creating customer empathy and building software that actually solves problems. I am also a huge advocate for low-code development and Rapid Application Delivery - there are many who would have you believe that almost all development will be done in low code in the next ten years. I am not one of those folks. However, I can say after seeing the power of at least one implementation (OutSystems) that almost every company in the world needs to integrate low-code into their technology stack. It should not be possible for me to say I built 15-20 production apps in under 4 years with a maximum team size of 3 at any given point, but it is the reality.

And now, I find myself here. Sitting in Seattle on a Tuesday night finishing up the first draft of my website homepage. If you stuck with me this far, feel free to contact me! I would love to talk more about any of the topics here. Also, keep an eye on my engineering blog for more information on some of my professional history and musings on the evolution of software development.