Tell me about your role at Red Hat
Rain: Officially, my title is Technical Program Manager and I realize this gets into a future question, but this is kind of how Red Hat handles open source projects. Sometimes a project is managed by the business unit and sometimes it’s managed by a member of the Open Source and Standards (OSAS) unit.
In this case, I’m a member of the OSAS group and while the technical program managers theoretically help manage only one maybe two projects every few years, I am dedicated to the RDO Community. This is the rpm packaged version of OpenStack and there are two installers for it – packstack and TripleO. And since it’s all interrelated, I call myself the OpenStack Liaison.
What brought you to this point in your career?
Rain: THAT is a roller coaster magic trick.
I have always felt that talking about what you’re doing for your project or company is part of my job. And, it turns out, that’s part of advocacy. And then you add documentation, which should already be part of your workflow, and a little social media as icing on top, then you’re suddenly an advocate. And then Red Hat asks you if you’d like to make it official and become the project community manager and you freak out a bit and then it all falls into place and then you’re there. It’s like that.
But on a broader scale, I have an undergrad in dance and a masters in IT. I was never meant to follow a straight ladder career. I’ve been a magician’s assistant and wrapped presents at the mall – I was a cashier at Kmart and I worked at a bank for many years. I’ve pretty much followed the opportunities with a lot of guidance from my gut and my heart and a little nudge from the student loans and this is where I’ve ended up.
Thankfully, I love what I do so I’m quite happy.
How does dev rel work at Red Hat?
Rain: I think of dev rel as an umbrella term under which many roles sit. There’s community management, sure, but also engineers, marketers, project managers and community managers and all kinds of people are involved in dev rel; especially in a company like Red Hat. For example, a Red Hat engineer who contributes to OpenStack might also give a keynote at an OpenInfra Days event and therefore is representing Red Hat and open source as well as openstack and rdo and tripleo. I think of everyone in the engineering, sales, marketing, business units, support and product departments as members of dev rel.
And that’s kind of how Red Hat works.
It depends on the individual as well as the project and how they implement the values of Red Hat and open source and therefore guide the community project and what their strengths are as to how they conduct their dev rel strategy. I tend to focus on coaching others to speak on our behalf because that’s my strength. And I continue the amazing metrics that the previous OpenStack Community Liaison started because that was his strength and it’s quite easy to continue down a path that’s already created. But another project may find that they’re more focused on growing their user community and that it’s more important to get the story out so they focus more on a marketing aspect – social media, blogging and such.
It also depends on what a community needs. If it’s so young that it needs everything, you’d need to pick and choose what will help the community grow and last while an older community might have entirely different needs.
What’s your dev rel philosophy?
Rain: Do whatever needs to be done, but also take care of yourself first. Because you can’t take care of anything else until you take care of yourself.
There’s a certain flexibility that needs to exist in order to adjust to all the changes and requirements and needs that happen within an open source project. One thing that may be vitally important is old hat tomorrow. But while you’re busy changing and adjusting and running around like a chicken with your head cut off, it’s also important to remember to breathe and take a moment for yourself and have a slice of cake.
What do you see as the big challenges for dev rel right now?
Rain: Definition. It’s so new that no one really knows how to define it or whether it should be in marketing or sales or engineering or on its own or if a “DevRel’r” should be super deep dive specialist technical or require a degree and it’s all just chaos.
Thankfully, there’s Mary Thengvall’s, “The Business of Developer Relations” that defines dev rel and starts to outline all the possible requirements and opportunities, but companies are mostly making decisions in the dark without a lot of research. My hope is that the book becomes a guiding light and a starting place from where companies can find define their needs more clearly and dive into the brave new dev rel world.
What are you hopeful about?
Rain: Everything. All of it. I’m one of those horribly optimists that hope all the damn time, even when there’s no reason to do so. And I find that I have to be – especially now with a four year old and two sixteen month old twins.
And then there’s that damn depression that every once in a while sneaks up and takes all the hope away and then I’m a bit of sludge on the ground under a rock for a while until I remember that we’re all million year old star dust and will end up there again some day and then I remember to make the best of it and carry on.
Also, I’m hopeful for cake.
Lots and lots of cake.
All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech, if you serve them well.
Are dev rel teams just here to make everyone feel good about using a technology or is there a deeper responsibility?