What I’m best at (professionally)
Presenting technically complex topics in a “bottom line” fashion. It only took a few decades to embrace this and make it my full-time job.
I started my technical career almost 30 years ago doing support for one of Seattle’s first dial-up ISPs. Since that involved a lot of SLIP/PPP, shell accounts, personal web accounts and such, my focus was primarily on the system administration side. My desktop was a Sparc 5 running SunOS, and I had never used any *nix variant before. The need to get up to speed quickly started a few decades of on the job learning.
Over the next few years, I learned to write a bit of code (mostly Perl and shell scripts). As the user base grew, but the staff didn’t, we automated more and more. I learned early on the value of making a computer do work instead of typing it myself over and over. I also learned the downside of being on call, as the point of presence (big modem rack) 300 miles away would only seem to go down at 3 AM.
I founded a web development company in 1995. We enjoyed great success, even making the cover of the LA Times for some revolutionary applications we created. Despite that technical success, I realized that I enjoyed solving complex business problems more than writing code and running servers. One of my first “big” consulting clients was the Chief Financial Officer for a large university. I reviewed significant technical proposals, such as providing internet access to their students and staff, for effective use of technology and responsible use of funding.
In 2001 we sold the web company, and I joined VA Linux. I was the first person hired specifically to help bring SourceForge Enterprise Edition (SFEE) to market. Hiring new people was a bit controversial, as VA had just announced the closure of their hardware division and laid off hundreds. This friction was my first introduction to solving conflict in the workplace.
It was my job to present SFEE to C level staff. The job meant going onsite with my laptop and doing presentations on their projectors while connected to their networks. If you tried to connect a Linux based laptop to a random projector in 2001, you know how that went. So, I went back to the office and told them I needed a Windows-based laptop. They reminded me that the name on the door was still “VA Linux.” I told them I promised not to use Windows on any servers while there if they wouldn’t force me to run Linux on a laptop.
The laptop experience was where I learned to use the right tool for the job, even if it’s not the most popular.
During my 8 years working on SourceForge, I managed a few different teams, and ultimately became the Global Director of Engineering for SFEE after CollabNet acquired the platform.
DevOps / Continuous Delivery
During my last couple of years running engineering for SourceForge, one challenge came up over and over. Despite fairly good agile practices including continuous integration, our time to market and initial quality were horrible. It was a fairly toxic culture post-acquisition, and the groups had a lot of friction. We’d toss a build over the wall to QA so they could toss it over another wall to ops, and the rest of the story you can probably guess.
In 2008 I heard ThoughtWorks was creating a new thing called a “continuous delivery” server. I was instantly sold on the value this would bring to engineering organizations.
In 2009 I started working for ThoughtWorks as a “product specialist,” a fancy term for sales engineer. The job was a highly technical role despite being attached to sales, but it also allowed me to do what I’m best at, present a new complicated topic to organizations in a way that highlighted what it would do for their business. Frankly, this was easy since I was in their exact position trying to solve the same problem before.
In 2010 I attended my first DevOpsDays conference. It was only the second or third event since the conference (and the term) was created in 2009.
Finally, it all clicked.
Continuous delivery had a considerable challenge, neither Dev nor Ops would accept the other’s automation tool. DevOps encouraged developers and operators (and all the other roles) to more closely align and (hopefully) work together on common goals. I was incredibly lucky to be at the intersection of both.
A few years later I became the Program Manager for GoCD, charged with converting what had been a commercial product to Apache 2.0 open source. Among other things, this meant getting out in front of as many people as possible to talk about the change. While I had been speaking to reasonably large crowds for years, this was when I started submitting talks to public conferences.
I joined a great team of folks in 2015 to organize DevOpsDays Seattle. In 2017 I was invited to join the global core team for DevOpsDays.
In 2016 the Managing Director of my group noted that I was far better at the public-facing aspects of my job (speaking at conferences and such) than I was at the program management aspects of my job. I couldn’t have agreed more.
While ThoughtWorks has always been very active in conferences and public speaking, we didn’t have any full-time advocates. So, I became the first, and still only, Technology Advocate.
So, if you’d like someone to speak about DevOps or Continuous Delivery at your conference let me know. I don’t have the typical background, and I think that’s a good thing.