Robyn Bergeron makes life awesome for people participating in the Elasticsearch, Logstash, and Kibana communities. Passionate about improving ease of development and deployment of infrastructure and applications, she tirelessly advocates for end-users of open source projects, which why her current title is Operations Advocate at Elastic.
She has been a sysadmin, program manager, and business analyst, and has an ongoing role as mother of two stellar kids. Her most recent gig was as the Fedora Project Leader at Red Hat, where she herded cats through several releases of the Linux distribution.
Robyn is talking DevOps at DevNation, where she'll cover how tools can help with communication, how open source can help provide new points of view for teams, and more. Her past experiences with Fedora and her various other roles makes her well suited to provide insights into evolving teams. And dear to my heart, she's from the Ops side of the DevOps gap, often unheard from and usually in the camp of "No!"
In this interview, I asked Robyn for some concrete pointers based on her experiences.
How did being the Fedora Project Leader influence your current role as ops advocate for Elastic?
Being the Fedora Project Leader put me in the fortunate position of listening—often—and I did my best to diversify the types of audiences and people that I'd be able to meet, whether by geography, organizational role, types of technologies used. Having been a systems administrator early in my career, I definitely have a deep amount of empathy for folks in ops roles, and repeatedly hearing stories about the day-to-day problems people faced really impacted my desire to have my next role be in the space of improving life for those people.
The ELK stack (that's Elasticsearch, Logstash, and Kibana), being incredibly flexible and adaptable to many use cases, appeals to both operations folks and developers—but my love for it really has grown from seeing how fantastically it has allowed folks working in ops to not just start more rapidly identifying that "something broke," but also to be able to visually identify the patterns that lead to those broken things. Getting to a point where you're not just on fire all the time fixing technology, and instead fixing the processes that lead to fires, or implementing ways to proactively avoid fires, is not just redeeming, but frees up time to do other things besides firefighting.
People love breaking that loop, and it's fabulous being an advocate for something that is literally making people's work-life balance and general happiness levels better. I've been in those fires. It's not fun. It makes me happy to see users feeling awesome.
Beyond buzzword bingo, what are some useful common starting points for teams moving towards a new way of delivering software?
Reading, watching, listening. There is a wealth of information shared by people about their DevOps successes and failures—and you'll note that while tools are sometimes mentioned, it's usually secondary to the sharing of the actual story of what happened, what was learned, what worked, or what failed. If you've been to a DevOpsDays event, you'll know that this is one of the great features of the event—people are telling their stories, not telling you how to use a tool. Reading blogs from great engineering teams—Etsy's Code as Craft blog is a fabulous example—can help spark great ideas as well.
In-person learning is awesome as well, and connecting with folks in your local community is a great way to not only network, but it also provides an experience that is a bit more hands-on, more memorable, and... well, your attention is a bit more focused, usually, than a YouTube experience that you can pause at any time. Even the smallest of towns have Meetups, and of course the bigger towns have the luxury of having many to choose from. Attending anything—a very generalized IT folks meetup, a cloud meetup, a DevOps meetup, or a more tool- or language-specific meetup—can help give you perspective on how other folks are doing things in their workplaces or free time. The Elastic community has meetups all over the world (except Antarctica) which are great learning opportunities for both beginners and experienced users—and if we don't have one in your area, we have a handy new guide for getting one started. (It's even useful for getting a non-Elastic meetup started; we even shared it under a Creative Commons license for anyone to remix and reuse!)
Most importantly, I think teams need to have a vision. Not of what they want to achieve or get done technologically ("totally new website in 6 months!"), but a vision of being a better organization that has fewer issues and higher productivity. Reading The Phoenix Project—which is actually an entertaining novel that most folks who have been in an IT department can relate to and not a boring how-to guide—can really illustrate to the uninitiated that there is a future state in which they can be the heroes of the company, accomplishing more, doing it faster, and doing it better. Making people feel like they can love their job and feel more valuable as an employee is a great motivator, and reminds them that all the work will be worth it.
Sounds like listening is a key starting point. What listening practices do you use to build cognitive empathy between different teams?
You know the saying about "walking a mile in someone else's shoes"? It definitely applies here. While I wish that all teams could do things as immersive as literally trading spaces with other teams—having folks from Dev come and work in Ops for a week for perspective—it's certainly not always feasible. But sitting down next to someone, or remotely sharing your screen with someone from another team, and letting them watch your actual experience, can certainly be eye-opening for that someone, and can help build a sense of empathy and care for how things actually impact you. Personal connection is awesome.
Beyond that: transparency about what is going on in other teams is just essential. Let folks be on your mailing list, or in your IRC/Hipchat room; generally being able to observe and participate and comment about anything, even if it's just
Also: FUN. Did I mention fun? I love fun. We all love fun. Do fun team building things with other teams—putting people together makes communication possible, builds trust, builds empathy. It's all part of the road to the bright and shiny future.
You'll be talking about tools that foster communication and do DevOps better. Does this mean I can finally buy DevOps?
Yes! And if you buy one today, you'll get a second... FREE!
Okay, maybe not really. But let me tell a little story, and perhaps it will illustrate things more clearly:
I had the pleasure of heading out to Europe in January of this year to attend FOSDEM and Configuration Management Camp in Belgium, followed by Ansiblefest in London. Ansiblefest is, of course, put on by the fine folks at Ansible, the company behind the popular open source project of the same name, who just happen to employ a bunch of my Fedora Project pals.
My company, Elastic, was a sponsor of Ansiblefest, which meant that when I wasn't tweeting, I was at our booth chatting with folks. And there were two common, repeating themes that I heard, about both the ELK stack and Ansible:
"It was easy to use and useful for both ops and dev—and both sides were just amazed that we found something we ALL liked. And that "I can't believe it!" conversation was the icebreaker to just talking more and improving communication. It also led to having more peaceful conversations about what other parts of our processes were hard for our teams—so we could start solving those."
And:
"By accident we found that we were both using the same tools, just for different things—and we started swapping tips and ideas about how to use it, best practices, that sort of thing. Next thing we knew, we were figuring out how to use it together—and realizing all sorts of places we could make improvements."
IT departments have long been a place for territorial behavior ("don't you dare touch the network!")—and most have examples of tools that were great for one group but terrible for another, causing friction between teams. When you have a tool that is easy and solves problems for both Dev and Ops, that's a great improvement simply because you have one less point of contention.
But some tools go beyond that, and being an open source project with a healthy, empowered community is the key factor here. Simplicity and flexibility, combined with a vibrant contributor community, is a recipe for sparking passion. Users become passionate in their constant recommendations, passionate because it's something they feel good about using, passionate because they came to the community for help and grew into helping others. Contributors become passionate because they've moved beyond using and into feeling like they are part of something greater, and contributing to that success.
Nothing brings people together better than a shared passion for something; it creates the place where communication begins, which can get folks on the road to a state where everyone is improving things together. There are plenty of barriers on the way to practicing DevOps; communication is a big one, and simply finding the time to even learn new technology is another. A tool isn't a DevOps magic wand, but when a tool hits the magic trifecta of ease of use, cross-team functionality, and having a healthy community, it lowers those barriers—because people want to share their successes with others. And the ELK stack projects and Ansible are just two of the places where I've heard actual evidence of how a tool ignited the process of bringing teams together.
OK, so I can't buy DevOps. What about hire? The hiring of a "DevOps engineer" is approaching cargo cult status, how can we help folks in hiring positions to understand that?
This is a tough one. There's definitely a shared responsibility here between the hiring manager and the people doing the actual recruiting to educate (or be educated) about what they're actually wanting in a qualified candidate, and to know how to appeal to those candidates.
For participants in the DevOps community of practice—that is, all of the folks who are sharing their experiences, practices, code, opinions, and generally trying to help improve the state and craft of the DevOps-practicing community—I think the most immediately useful thing that can be done is to let recruiters know that this isn't going to attract potential hires. If you're on LinkedIn, or you have your resume posted to your personal website, and you have the word "DevOps" anywhere, or "Docker," or any of the other keywords mentioned in the sample above, chances are, you've been pinged. If it says DevOps and Docker, well, I feel for your inbox. It must be strained.
The fact is: Nobody who understands DevOps is going to give a second look to a company that appears to not understand that DevOps isn't a thing obtain by hiring a team and giving them a label. If you're uninformed, you won't get the people that you need.
A quick, polite response simply indicating non-interest, accompanied by the friendly advice that the job description implies a lack of understanding of what DevOps actually is, and thus will be a turn-off for anyone that might actually have the knowledge and experience to qualify. Followed by perhaps a link to a useful article and a recommendation to read The Phoenix Project. If there was a cut-and-paste template for this on the internet, that would be spectacular. Hey, interwebs: Free idea for leveling up your reputation!
What's your favorite open source project mascot, official or unofficial?
OH, GOSH. One of my favorite subjects. It's a three-way tie.
The Beefy Miracle (@beefymiracle), the namesake for Fedora 17, is, of course, near and dear to my heart. While some people thought it was the wurst name ever, his legacy lives on. If you don't know the history of Beefy, you should definitely ketchup on it—it's a great story. And remember, kids: The mustard indicates progress!
But, gee whiz, Sir Logs-a-Lot (@logstash), representing the Logstash project, is super cute. So much built-in awesome. Logstash "stashes" your logs away in myriad ways. Sir Logs-a-Lot has a mustache. He is a log. He is amazing.
If I need more cowbell, though, the Ansibull (@ansibull) is always at the ready with the cowbell-deploying Ansible playbook. Making cowbell deploya-bull. And his amazing puns are completely retweets-bull. He makes me snicker randomly, which is awesome. Actually, now that I think about it, I'm pretty sure there isn't a cowbell playbook in Galaxy (Sorry! My mis-steak.).
Speaker Interview
This article is part of the Speaker Interview Series for DevNation 2015 an open source conference by and for developers from across the globe.
Comments are closed.