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.Continue reading “How I became a Technology Advocate”
I went through a lot of information in a short amount of time today in my talk at That Conference. In fact working on this list I’m not sure it wasn’t too much! Interested to hear from anyone who was there if it was.
Here are some resources to learn more about the various topics.
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.
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.
The term DevOps is commonly thought of as a portmanteau of two nouns, developers and operators. It should be thought of as two verbs, developing and operating.
During discussions and open spaces at DevOpsDays Hartford the past few days I’ve recommended some homework. Here’s a list of (hopefully all of) the things I referenced. If I mentioned something to you and you don’t see it here please let me know.
Everything has an online mostly anonymous rating system these days. Restaurants, Doctors, Auto Repair, rideshare drivers. Everything. I like the idea of knowing other people’s impressions about stuff, but the way we use the systems is completely broken.
We just wrapped up DevOpsDays Seattle. It was awesome. We had a bunch of truly engaging and informative talks. We also had one talk that really pissed me off.
I want to be clear here… I’m not upset with the speaker, or the content of the talk. I’m upset with the idiots who made the talk necessary.