Made by
Made by
K Rain Leander and Mary Thengvall
A robust replacement plan is a great resource with benefits for you, your replacement and your community. Persea Consulting’s Mary Thengvall and Red Hat’s K Rain Leander use their personal experience to give some practical help. This talk was recorded at DevRelCon 2018.
[Mary] So, I’m Mary.
[Rain] I’m Rain.
[Mary] We’re happy to have Avocat shirts today.
[Rain] Actually, we officially have a request, because someone else bought these for us, and they wanted proof that we wore them on stage. So if you could tweet the hell out of this.
[Mary] Pictures.
[Rain] That would be great. And then we’re going to change, so that’s the whole talk. This talk is also technically passing the torch without dropping the ball. Because we are very big sport fans and we thought that would be hilarious for us to correctly use all the sport stuff.
[Mary] It’s true. It’s true.
We want to talk about leaving. In a helpful way
[Rain] So FYI, it’s not just about flipping the table and walking out the door, or politely handing over the keys and walking away. So this is what not to do for just a few seconds. But first, we’re going to introduce ourselves.
[Mary] I’m Mary Thengvall. You can find me at mary_grace on Twitter. If you were in here for Baruch’s talk earlier, I’m the person he kept quoting from, which was really, really, really, weird. But I do have a handful of books if anyone’s interested for after the talk.
But basically, I’m a developer relations consultant. I help companies figure out strategy for dev rel, what the team should look like, what it does look like. And kind of help them figure out what it means for their company specifically.
[Rain] Cool, and I’m Rain Leander. I have not written a book, and have not been quoted today.
[Man] Yet.
[Rain] Yet. You get it, you get me. I am a baby community manager.
[Mary] She’s a legit community manager, don’t let her fool you.
[Rain] A baby. In that for years, I have not had the title or any kind of related title, but other titles like support engineer, or straight up engineer. And have just recently actually acquired OpenStack Liaison. Which kind of brings us to what we’re talking about today, because we’re talking about how to actually take a full project or pieces of the project, or pieces of your own job or responsibilities that may or may not be yours, to hand to someone else.
And we’re going to talk about why you should care maybe, and how to actually logistically do it. The reason we’re here today, is because of a little project called RDO. It is…has anyone heard of OpenStack? Hey, hey. Good buddies. Hey, buddies.
OpenStack is a cloud computing infrastructure, open source, upstream, and RDO is the RPM-packaged version of OpenStack. I was an engineer in there, except that I had this annoying habit of going around the world and talking about it, and giving out swag, and drinking beer. So I was already a community manager.
And eventually, they were like “Why don’t you actually go to the department within Red Hat…” by the way, I work with Red Hat IBM and…
[Mary] That’s all we’ll say about that all day, by the way.
[Rain] No, there will be no questions. So I worked within the engineering department, but there was this person who was actually in charge of RDO, and he was like, “Why don’t you come over and take over this project officially, and then I can go take over this other project and it’ll be cool.”
And I was like, “That’s cool,” and my boss says it’s cool, everyone said it was cool, except that my uterus said that’s not cool because we’re going to have twins now. And I was like that’s less cool, but yaay. In the Netherlands, you’re allowed to be sick when you’re pregnant, and completely not go to work at all for the entire time when you’re vomiting nonstop every single day.
[Man] What?
[Rain] It’s weird right, really weird, they’re such a weird country. That’s where I live.
[Man] It’s a great country.
[Rain] I think it’s cool. I love living there, I’ve been there for seven years. And basically, when I was having twins and puking every day, I am not exaggerating I weighed less than I weighed with a single child. I was very, very sick and Rich was doing the job of two people.
He was in charge of RDO, but he was also in charge of CentOS, and those are very, very big projects. And when Red Hat found out that while I’m on maternity leave, the Dutch government will give them a stack of money, they went “Okay, we’re going to hire someone to help Rich out.”
[Mary] Hi. So that’s where I come in. So they basically came to me and said, “Hi, we need someone to take over this job that no one has really been doing for a little while. And Rich’s been trying to do, but we need someone to come over take, over while Rain is out, until she’s back. And I said, “Sure that sounds awesome.”
I love new communities, I love helping to figure out some of the ways that things can be streamlined, and processes and all of that. So I came in, started helping out and you’re probably at this point asking why this is relevant. Because unless you’re pregnant with twins and live in the Netherlands, or planning to switch jobs, you’re relatively content in your job, you don’t have plans to move on, so why do you care.
But there’s a couple main reasons here. First of all, maybe you won’t be content in your job forever. Secondly, maybe there are parts of your job you would like to hand off to someone else. Maybe you don’t want people to think that being a community manager, is just flying to exotic places and drinking beer, and documenting what you do actually gives people more respect for your job.
Because there’s so much that we handle on a daily basis, that people don’t understand because they don’t see it. And so if we can document it, then they can see it, understand, we gain some respect, also potentially gain headcount, which I think we can all agree that we all need. But also it opens up the opportunity for some of your community members to sometimes step up and volunteer.
It opens up the ability for you to take on bigger projects. And in general, helps people around the world better understand what the community manager role truly is. Lets us delegate, like I said, lets people volunteer to help out in other ways, which frees up our time among other things too, like you know, take a vacation, or take sick days when we actually are sick, and not feel so guilty about leaving projects when no one else is handling them.
[Rain] It’s not good.
[Mary] Also, we probably aren’t going to be doing the role that we are in forever, right? Someday you will want to move on, and you don’t want to spend your last two weeks like I have done, and I’m sure other people have done documenting everything that you can possibly document so that none of the things fall on the floor. You also probably don’t want to rage quit, and just flip the table and walk out with no documentation. So doing this lets that be a little more manageable, makes that possible.
[Rain] Exactly. So how do you actually do that? And this is where we get down to the actual logistics of what Rich, Mary, and I, have done. It is called the handover document for obvious reasons. But it’s basically a Google doc that rested online, and at first was internal only to our company and shared only among us three.
I might go into details about why that is, or I might run out of time. But it has a lot of information that you want to pass along to the first person. Rich started this doc as soon as he and I started talking about possibly migrating. And so that started in January of 2017. The twins are very healthy and beautiful.
[Mary] But basically, when I came in, there was this 23-page Google doc, not kidding, single-spaced. None of those tricks you pull in college when you’re trying to fill in space there. But 23-page doc that basically was supposed to set me up for success, and walk me through all these processes. It started out with the project goals and the reading list, the basic overview, right?
So linking to what’s the goal of this project as a whole? What’s the goal for the community manager role within this project? What are the things that we want to accomplish? What are the things that the overall project wants to accomplish? What’s the history of the project? All of the things that should get you up to speed on why this matters, and why your role as a part of this project matters.
[Rain] And to let you know, the reading list is kind of like historical documentation. It might include the website itself, it might include email that a founding person sent to someone else. It’s anything that helps set the scene for a person who is new to the project. And it, theoretically, is all online because we’ve put it all online.
But it could also be something that you only verbally share. So, when we put something up here, it might be physical that you put it on the handover document, or might be something that you talk about over coffee or whiskey.
[Mary] The nice thing about putting together a reading list like this is it gives people context for what they’re walking into. But it also keeps you from at the very end of your job, having to go, “Shoot, there’s an email that I got sent on my first week here, and I have to go sort through my email and figure out where that lives, and what I tagged it as, and if I can find it anymore, or maybe it got archived years ago.”
But it puts everything in one single place. The advantage to having it in a Google doc, this could be a paper doc, it could be whoever else has shared collaborative documentation, GitHub. It could be anywhere. But the advantage to having it there is that you have that history, right? So people can go in, they can edit it, they can add things in, they can ask questions and everything else.
[Rain} Dramatis personae. That’s me in the middle. It’s not about…so when you take over a new project it’s…unless the project has never existed before, and therefore there’s never been any stakeholders, I think even in that situation, you would still have people who are important, people who are invested in whatever you’re doing.
In this case, we needed to know who the important people were with OpenStack, with RDO, within Red Hat. And it didn’t just have to do with the collaborators, it had to also do with the people who were indirectly influencing like the managers or the engineers, who gave travel budget to go to OpenStack Summit and whatnot.
And it was also people like Tim Bell over at CERN who has an amazing upstream instance… it’s millions of…it’s massive… of OpenStack running on RDO.
[Mary] So some of these people are going to be people that will wind up named in that document. There are some other people who, as Rain implied earlier, will be discussed over coffee, or drinks, or lunch, or what have you. Because these are the people who may be more on the drama side of the dramatis personae and are causing issues.
And your incoming person needs to know about them, but those people should not be named in the doc.
[Rain] Just in case.
-[Mary] At all.
[Rain] That needs to be said.
[Mary] And that can be a problem, right? Where, okay, it starts out as it’s only shared with your team, and then the team goes, “This is amazing, and we should have other people throughout the company do the same thing.” And they share the document throughout the company, and now suddenly there’s a lot more people that have access to who you think is a drama person in your community, which is not a great thing. So some of this is documented, some of it’s not, but all of it is information that needs to be passed along to the next person.
Next is our regular tasks. Rich did an amazing favor to both of us and broke this down into a daily, weekly, and monthly list. This was huge when I came in because I was able, as a contractor, to come in and go, “Great, here’s the main things I can take off of your plate that will take even if it’s just two hours of your day every day. And I can start there and ease myself in.”
So that as I got used to the community, as I got used to the tooling, I was able to then take on more. But it was a great starting place for me to be able to come in and go, “All right, here’s an easy task that I can take on, it’s one less thing for you to handle.” This also included all of the meetings, which there were a lot of as you can imagine.
But it included things like, you really should be at this meeting, you really don’t need to be at this meeting. This one is one that you should keep an eye on the agenda, and sometimes you should go to and sometimes you don’t need to. The nice thing about this is as well, is he was able to attend meetings with me, and then when Rain came back, was able to attend meetings with her. And as questions came up, he was able to go, “That’s not me anymore, but Rain’s here, you can ask her that question.”
And so it was a very easy pass-off, a transition in that sense.
[Rain] And also when I didn’t have the answer I could go, “Oh, yeah. Rich?”
[Mary] And this also includes the important annual event. So for RDO it was things like…
[Rain] OpenStack Summit, some specific meetups that don’t exist anymore. It was a list of, this is how little you could travel, and this is how much you could if you really didn’t want to see the twins at all.
[Mary] Right, and this was huge in prioritization, right? Because it allowed both of us to look at the list and go, “Where can I start right now? What’s going to take me a little bit more time?What am I going to need more information on?” And going back to the collaborative doc part of it, we were able to then put questions right in there and go, “Hang on, I don’t understand what this acronym means. I don’t understand what this meeting means. Do I really need to be up at 5 30 a.m. Pacific Time, for a meeting that happens in Europe? Please tell me no, because I’m not a morning person.”
But being able to ask those questions collaboratively and work together to figure out those answers was huge.
[Rain] Yes, and I’m going a little bit faster, there is going to be a certain point where you’re like handing it over, and you’re like, “You know what, these are the pie in the sky things that I wish I had gotten like way more cake,” and didn’t quite get to yet. And so if you want to take care of it this would be super keen, and maybe this is why…because cake is awesome, but it’s not necessary.
It’s just important to make sure you hand that over along with, “Here is the budget, here is the credentials that you need to do, and please, reset them.” All of the keys to the castle need to be handed over. And I realize that our situation was kind of an anomaly, in that we still had those previous people available to me as a resource, even as I came back, Mary was still there for a few months.
And you may not have that situation. But this is one of the most important things to make sure you handover, is those things to actually let the new person unlock everything. And that’s all there is, it’s totally finished. I promise it was a 23-page document, and there was no…absolutely no evolution to it whatsoever.
[Mary] It looked a little more like this. Honestly, there was a lot of suggestions in Google docs, there were a lot of comments. There was a lot of like this makes no sense to either one of us, and I think this is very deep in Rich’s memories from four years ago when he started this, right?
[Rain] Yeah.
[Mary] So there was a lot of back and forth, a lot of edits, a lot of questions, a lot of figuring out, what’s no longer accurate? That person doesn’t work there anymore. How do we dig into that hole of OpenStack and figure out who the right contact is over there. What’s missing? What’s confusing? How do you figure that out? This right here is a big part of the reason why I would strongly encourage all of you to start doing this in your day today, don’t wait until your last two weeks.
Because if you wait till those last two weeks, all of those little things that are ingrained in your mind, that are second nature to you, are not second nature to other people. And so the longer you wait to document things, the more difficult it will be to make sure all the details are included.
[Rain] It really comes down to prioritization of what your daily tasks are, what all of your tasks are. What can only you do, and what can you pass off to others within your community? So important. And we even added this yesterday because we were like Avocat-oes.
[Mary] And we didn’t have any cats.
[Rain] Kitties!
[Mary] Which was a problem.
[Rain] It really comes down to don’t be afraid to make changes, even if this community has been found around for many, many years, which RDO has. You come in, you are a new person, so there’s a certain balance between honoring what’s come before you, and also making changes that need to happen, which is totally fine.
[Mary] And you kind of have a grace period there, right, because you are the new person. So you have the ability to go, “Oops, sorry, that was me, I won’t do that again.” But it also gives you the flexibility to figure out what can you apologize for, what can’t you apologize for. And you obviously don’t want to make huge major intentional mistakes. But it lets you figure out where those different boundaries are.
[Rain] Exactly.
[Mary] And you figure out where they are by remembering to listen to your community and figure that out.
[Rain] If you’re going to take a picture of one slide, here you go, this is a summary of the whole talk, and we only have two minutes left.
[Mary] It’s true.
[Rain] Are we giving space for questions?
[Mary] Sure.
[Rain] Okay, questions?
[Woman] Can you go back to the one slide?
[Rain] Oh, go back one more.
[Mary] There you go.
[Rain] Sorry, if you’re going to take pictures of one slide, take it now.
[Mary] You had a question.
[Man] Do you have any advice on how to…as a manager, how to incentivize the person leaving to…
[Rain] Write things down.
[Man] To do this, because this is, maybe, sort of above and beyond?
[Mary] Right. So the question is as a manager, how do you incentivize your team to write things down, to document things.
[Rain] And it might be as much as giving them that space. Look on Fridays, every Friday, I’m going to give you space to focus on this project for one hour, from 8 to 9 or something like that. Or if that doesn’t work, it might be okay, during our one on one this week, we’re just going to… and then you help do their outline, and then maybe they flesh it out. Or you offer them cake.
[Mary] I think one major goal to remember too is by writing all of this stuff down, it helps them figure out what isn’t going back up to your goals, right? What isn’t relating back up to, here’s our quarterly goals. So it might be keeping them from actually accomplishing that, which in a sense, almost makes that a team goal, right?
Because you need to be able to solidify this is what we’re doing, these are the only things you’re responsible for, what can we pass off to other people.
[Rain] And the other thing is you can emphasize that as their manager, that’s how you see how awesome they are. That is a clear black and white demonstration of this is all the awesome shit I do. Don’t say shit on the stage, Rain.
[Mary] I would encourage you to recognize it’s not micromanaging, it’s helping to empower them, to give them the space to figure out what it is that they’re doing, what they should be doing, what they can pass off.
[Rain] Exactly. If you want to talk to us and get a book, then our time is up.
[Mary] Yeah. Thank you.