How I became a Technology Advocate

~ kmugrage ~ Leave a comment

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.

Background

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.

Using your pipeline to enforce corporate rules

~ kmugrage ~ Leave a comment

I just took part in a discussion about Continuous Delivery fundamentals at a conference. During the conversation different questions came up about security and compliance, with reactions varied from “well of course you have to do that” to anecdotes about shadow IT where corporate polices are ignored.

It wouldn’t have been appropriate for me to point this out in the conversation, but this is one area where the differences between a CI tool and a CD tool really stand out.

I talked about the ability to run things like security pipelines in parallel with other pipelines in a blog from a couple years ago ( https://www.gocd.org/2016/02/08/not-done-unless-its-done-security ) but I may not have pointed out of one the most powerful options…

The folks responsible for designing and maintaining the security and compliance checks don’t have to be on the product team.

This diagram represents a single pipeline fanning out into two pipelines and then back into one. It’s important to note that these are not just parallel jobs, but entirely different pipelines.

It’s possible in GoCD to have the security / compliance pipeline be under the care of a dedicated team. As much as I’m a fan of cross functional teams, it’s not always reasonable to have all the knowledge you need on a product team. It’s also possible that you would want the work verified by another team for other reasons.

It’s this possibility of parallel pipelines that came to my mind first when I read the new “trust teams but verify” theme for the latest ThoughtWorks Radar. I think it’s a great way to make sure you’re following all the corporate rules (which are there for a good reason) without slowing down your development.

More information:

Is it time to give up on what DevOps isn’t?

~ kmugrage ~ Leave a comment

We recently completed DevOpsDays Seattle. The feedback for the event was overwhelmingly positive in most areas. The exception was some feedback that there weren’t enough technical sessions. This is fairly common with DevOpsDays events, because DevOps isn’t about technology.

Fast forward to this morning… I volunteer to do some mentoring. I was on a Slack channel about DevOps, when someone starting asking Tomcat configuration questions. Again, a technology question. Because in this person’s mind DevOps is what system administrators do.

The problem; most people think DevOps is about technology.

DevOps is about culture. It’s about getting the people developing and operating the software to work together. This shows itself more in organizational structure that any specific technology. I even went so far as to write my own definition of DevOps which I share before doing a talk or workshop so people know what I mean when I say it.

When I was growing up and made a point which may have been correct but didn’t actually help anything, my father would say “That and $5 will get you a six pack”. 

My job is to teach people about Continuous Delivery (which is technical) and DevOps (which isn’t). If people are coming to DevOps events that I’m helping organize and not getting the information they need, am I failing at that job?

Words change meanings over time. Every year the folks who create dictionaries add “new” words which have to make English professors shiver. Maybe DevOps doesn’t mean what it was supposed to mean anymore.

I’m not quite ready to wave the white flag.

All of this said, I’ll still try to teach people what DevOps truly means, because without the culture change the rest of it is doomed to failure. But maybe it’s ok to let a little more technology in the door to meet people where they are.