Let’s Start a Ruckus
I fall in love with wicked problems! I enjoy providing clarity to strategy, design, and engineering by keeping the “main thing the main thing” during a project’s journey.
When I’m not helping inspire product teams with my customer knowledge, I am telling stories and teaching niche audiences has a podcast producer and host. Together, these skills turn me into an internal evangelist that keep teams aligned, optimistic, and practical.
First Big App
My first Big Application experience came when I was doing Freelance PHP development with my first company Leafbreeze Productions. I contracted with a small design firm called Sparkplug out of out of Portland, Oregon, to build them a prototype application called TeamSnap.
I took the paper designs from Sparkplug and built TeamSnap out as a sports team management tool. During the project, I convinced Sparkplug to reconsider who actually manages a sports team. While they thought it would be run by a team manager or a team parent, the actual customer of TeamSnap would most likely be coaches. Coaches were the ones that needed to save time organizing their teams and groups online.
The end result was a TeamSnap working prototype, developed as a PHP/MySQL LAMP application that focused on a coaches perspective of their amateur team. Sparkplug then turned around and sold the prototype to a private investor who turned the application into US$20-million Software-as-a-Service company based in Boulder, Colorado. The current version of the application still has many of the features I helped create.
The TeamSnap experience taught me how enjoyable developing Software-as-a-Service applications could be. Especially when I could work with others using a whiteboard, butcher-paper sketch pads, and paper-based demos to brainstorm functions, workflows, and features.
In Search of Monsters
I love telling stories and teaching niche audiences interesting ways to look at wicked problems. That’s why I find talking at conferences is a perfect way to streamline an idea, test its validity, and gain instant feedback. Sometimes the crazier the talk, the better the feedback!
I started my experimentation talks with WordPress. My first real technical talk was at a WordCamp event in Asheville, North Carolina, with the introduction of WordPress Multisite (WPMU) Design Patterns in a talk I called Monsters of WordPress. From there I explored the possibility of simplifying WPMU installations by experimenting with turn-key solutions and plugins that could combine and separate WPMU network sites. Unfortunately, few developers were interested in using WordPress Multisite due to its wicked complexity. It was an idea before its time.
Enter the Gagglepod
All my WordPress exploration lead me to find a way to share my ideas beyond blogging. That’s when I discovered podcasting! I took my creativity and talk experience to a whole new level by diving into the wicked problems created by developing, recording, and producing a podcast. In my haste to learn everything about podcasting, I made a ton of mistakes. My first podcast Merchants of Dirt started off with everything wrong: from the microphone selection to the audio editing.
However, in doing it wrong I learned all the ways to break it, tweak it, and ultimately fix it. This hard-fought journey helped create a new experimental platform: Gagglepod. Gagglepod started as a meetup to give back to others what I had already learned about podcasting. But after a year of using my talks to test my understanding, ideas, and processes, I moved out from local talks to share my ideas at national podcasting conferences.
The Next Leap
I’ve now turned my focus back to building Software-as-a-Service. I’ve gone back to updating my programming skills by learning Node.js, and have been heavily involved in support Enterprise migrations of on-site applications into Amazon AWS environments. The challenge of the lift-and-shift fallacy is in learning how much the customer requirements have changed from when the application was first created to now.
I love how cloud migrations are not simple and enjoy the complexity that comes with figuring out how wicked moving code from one location to another can be. There is nothing like redesigning overcomplicated parts of software systems and filling the gaps that stop it from breaking the same way again. I’ve really become fascinated with understanding what can be learned from fail-fast and post-incident experimentation. It not only has allowed me to see how a service can be improved but allowed me to learn something new every day.
Who knows what tomorrow’s wicked problem will bring me. Hopefully, it will be something I can use to start another ruckus!