Video details

Document Yourself: A Framework for Career Advancement - Michelle Brenner - REdeploy 2019


The goal of this workshop is to document yourself the way you would document code. You wouldn’t expect someone who wants to use the program you built to read every line of code. Instead, they’re relying on the design documents and doc strings to know how it works. The same is true with your career. This workshop is about making it easy for you to provide overwhelming evidence of your value to the company. When you can show your ROI, it’s much easier to secure that promotion, raise or new job that you deserve.
This workshop consists of 3 parts. Writing your daily accomplishments in the form of success statements. Putting them together into a brag sheet. And finally using them to create your elevator pitch. Using this framework makes it easy to make a habit of documenting, the same way a style guide helps you document your code. Once you have documented yourself, you will be amazed at how much you have accomplished. You will walk out of the workshop with the confidence and plan to take your next step.
Michelle is currently a Senior Backend Engineer in food tech, helping restaurants thrive. She has 9+ years experience, from the front lines of support to managing a team. While spending most of her career in entertainment tech, she worked tirelessly to help movies and television get made faster and cheaper.
A Philadelphia native, she is an art school graduate and a self-taught Python developer. She also runs a tech podcast called From the Source, interviewing working professionals with a focus on underrepresented voices, to answer the question of what tech jobs are really like. Michelle works to promote diversity and inclusion in tech through conference speaking and organizing, mentoring, board membership and making sure everyone knows they belong here.

To engage in the conversation on Resilience Engineering in the tech industry, tweet with the hashtag #REdeployConf.
For more information about REdeploy, check out


Where will you find resilience redeploy? So the first question I want to answer is why? There are two reasons. In a perfect world, my engineer engineering manager would know everything I want to do with my career and give me more complex projects, promotions and raises to go with that. But they can't read my mind, and sometimes they don't even understand what I'm doing. The other reason is basically a bug out bag for your career. What happens if the startup you're in runs out of money, or the division you're in get laid off? Or someone who gets hired and it turns into a toxic work environment? You want to be ready to move on with your career at any time. So it's basically a constant journal of everything you've worked on, so you're ready to go to the next step. And by doing it periodically, instead of when you're in an emergency, it'll be a much easier task. So let's start with ROI. If a product costs $5 to make and you can only sell it for $4, you've got a business problem. If you're selling it for $15, you've got a winner. Most business managers think of these terms because that's how they have to justify themselves to stakeholders, investors, and their managers. You should think of yourself in those same terms. What is your return on investment? If it's much higher than your salary, then you can justify that raise. If you've made your company millions of dollars, they should be able to give you a 20 grand raise. It's also important to frame what you want in a way that helps the company. So if I say it's important that the company invests in my growth, so I deserve to lead the new project, it's all about me. But if I say I increase sales 10% by creating this feature, if I was given this other project to lead, I can do even better. It's about them and solving problems for them. So the second one is going to actually happen. The first one is going to be like, maybe I should just fire you. You're too annoying. So in order to make that claim from the last slide, you need evidence. So we're going to talk about success statements. A success statement is a short, easy to read sentence that describes a single accomplishment. It can be cost savings or a profit increase. It should be 100 to 200 characters, kind of like Twitter, written at a high level, easy to comprehend by someone who might not understand anything that you do. It is best if it is quantified in money, but it can also be quantified in time, because salary is a big expenditure. And if you're saving salary, you're saving money. So here are some examples. Oh, and this is the format. I improve this thing by this measurable amount. Using this method, I added a new way for customers to find us increasing sales 15% by connecting with a third party API. I reduced storage costs by $500 monthly by switching to a different storage system. Notice in that one, I don't tell you the database system that I changed to because sometimes even those words might not make it up the chain, but everyone understands $500. I reduced the time spent doing manual tests, 60 minutes weekly by creating automated tests. So time for your first writing break. So there's a couple of different ways you can go to that link I put up there, and you can download the whole worksheet if you want to see ahead and get all these questions on your phone or just answer these questions. So I'd like you to spend a few minutes working by yourself, and then I'm going to ask you to talk to your neighbor if you would like to. Okay? Would anyone like to share their success statements? There's a microphone over there, but if you don't feel comfortable coming up, you can always tweet at me and I'll read them out. But I'd love to hear someone success statement we could share with everyone. I shared three of mine in the last slide, so I know you're ready. You could share your neighbors and talk about how great they are. And if you don't want to get up, I will come to you, but I will have to. Anyone want to share their success statement? All right. Yeah. What's your name? I'm Kevin. I moved deployments of an internal testing system from once every nine months because nobody knows how it works, to something you can do in 10 minutes by moving to a bunch of TerraForm and ansible. I think this is kind of interesting because I'm trying to translate this to value now. But Mike, do you reduce deployment from nine months to 10 minutes by automating the deployment system? And you either save time or money there, right? So you are able to get out more project features, maybe increasing sales or something? What is the output of being able to deploy more? Usually for me, I could put out more features, so maybe just think about what the end of that sentence is. But I feel like you got two thirds of that. Great. And that's awesome. And thank you so much for sharing. Let's give Kevin a round of applause. Do we have anyone else who would like to share what they did? Come on. There we go. I see some Netflix peeps in the audience. I was going to be like, listen, I'm going to call in a solid for my teammates. If no one raises their hands. And you are? My name is Stephen and I can hold it. That's exciting. I reduced build times by 20% by implementing Caching of library downloads. That sounds great. What did that accomplish? Same thing. Put out more features, save money, do more sales. You got two thirds of it. You're just like, almost there. So maybe if you don't even know one of the things is sometimes you don't know the impact. You can always survey the engineers or survey customer service or whichever team that you impacted. Ask them how it's improved their day. Let's give Stephen a round of applause. Thank you so much, everyone, for sharing. I'm going to move on. So let's talk about bragsheets. Bragsheets are a summary of your accomplishments and what you'd like to do next. These should ideally be one page, like a resume. You should always have the goal of making it easy for your manager to say yes to you and sponsor you for your next promotion. So Record of Achievement has a couple of different sections. The first is Record of Achievement. A record of Achievement is a summary of your success statements. So I would usually write maybe a success statement a week, and my record of Achievement would be the summary of everything. One of my mentors once told me that people overestimate what they can do in a day and underestimate what they can do in a month. By adding up your small successes, you can show all the big wins. Fixing one bug is not that impressive. Fixing 20 bugs and increasing sales by 20% is. And it also gives you that sense of accomplishment, kind of reducing that burnout feel like, oh, every day I'm just fixing bugs. But realizing how much you've gotten done in the last week, months and quarter really gives you that sense of accomplishment. So your career goals should be near term, and accomplishable this is not your five year plan. They should be literally what you want to do next. They should have two parts what you want to accomplish and how that will help the company. For example, if you want to be a team lead, you should talk about how you can help mentor the other engineers to level them up and help them accomplish more and create even more value for the company, because then you're raising them up and then your readiness for goal is how you're currently preparing yourself to succeed at your next goal. This can be something like training classes or taking on stretch projects, certifications or books on leadership. It can be something you're currently doing, or it can be your plan on what to do when you first show your brides. You can say, hey, this is what I plan to do in the next couple of weeks. Does this look like what I need to accomplish to hit this goal? And it gives you make sure that you and your manager are on the same page of what you need to learn for the next position. Now it's time for more writing. So there are more questions here and you'll notice a trend that will get more as it goes on. So spend a few minutes answering this and then talk to your neighbor. Would anyone like to share their goals and come up or come around with a mic. I really want to know what you'll do next. I'm excited for you to accomplish it. Alright, who wants to share what they're doing next? Yes. What's your name? Tony. Well, in sharing my goal, I just realized a maybe four year career goal, which was to be to express something like how good the tools are off the shelf today for doing this very complex work. And it's really not possible to replicate in it what you can get off the shelf anymore. And it's not even funny because sorry, in things we do alone, we don't have anything to navigate by. An off the shelf tools are often very observable. So is the goal to write a blog post or do a conference, talk about that topic? To inform people? It's my job to inform people of that. Okay. So just get that information more out in your company. I've been trying to do it in less than an hour and a half. Sounds great. Thank you very much. Let's give Tony a hand. I feel like because I'm sitting over here, that this side of the audience is feeling lonely and would love to raise their hand to talk about their goals. Who over here has a goal they would like to share? It can be a small thing. I'm sure you'll accomplish it. There we go. We have one. What's your name? Hi, I'm Andy. And one critical that I would like to do is building up more developer relations at my company. Achieving it, how it benefits the company is that we do have a developer community out there. We want more people building stuff up so that there's more for the users to use. And what I'm doing to affect that is going around to our API, like our platform team, nudging them occasionally, like what do you need to get done before we can publicize this? And then just gradually following up working with the marketing team. Okay, how do we publicize this? And eventually we will have more people building stuff. Awesome. Thank you. That sounds great. Let's give Andy a hand. It also sounds like you're very clear incremental plan for getting it done, which is great. I think I'll move on. No one else wants to share their goals. You can tweet at me. So let's talk about elevator pitch. I want you to think about your favorite movie. Did you learn everything was to learn about the main character or just the parts that would remain to the plot? Creating an elevator pitch is all about telling the right version of your story for the audience. So who is your audience? What is their goal for this meeting? How can you demonstrate you have what they're looking for? This project started for me when I was trying to get a job as a back end engineer, but didn't have a computer science degree. So my audience was recruiters who only had a basic understanding of technology. And I wanted them to hear the story of how I was an experienced technologist that could solve their problems without being able to use formal education as a shortcut. So in order to do that, there's a couple of different things I use. One is a pattern of growth. So you are more skilled now than you ever were. It's a pattern of growth throughout your life. It does not matter what your job duties were or the industry that you were in. Every job you learned something, even if technically you move laterally or even down. I was a manager and I went back to an individual contributor. I didn't necessarily want to do that, but I learned a lot while doing so. You just have to find what it is that you learned. If you worked as a barista, you learned customer service, multitasking, and problem solving. If you worked as a freelancer, you learn communication and time management. These are all valuable and transferable skills. So it's all about the skills and not necessarily a job title. So that Sega is great in this. Your skills are more important than how you use them. You just need to learn how to take the task, say, folding clothes at a retail store, and turn it into that skill. In that example, attention to detail and quality control, a stay at home parent, getting back into the workforce. I'm sure they can tell me stories about time and project management and finding creative solutions. Dealing with demanding clients can also require a similar skill set to pacifying toddlers. So the third thing is be positive. Everything is awesome. Always find a silver lining to whatever happened in your career that you would like to change. So, as I said, I went from being a lead to being an individual contributor because I was leading a team of pipeline engineers. That didn't transfer really well when I wanted to go into web development. So when I did that, I talked all about how I wanted to learn new technology and do new things and experience being on the front lines of a B to B application, which I did, which is great. And now that's my story. So it's time for our final writing break. This is very long, so you don't have to fill out all of it, but just start to write down notes of what you're thinking, and then we'll share with our neighbors. Does anyone want to share your audience and what you would like them to learn? Or you can talk about a project and try to explain it to me. I'm going to start on the site this time. I want to hear some lessons you've learned. I heard people talking, so I know there's lots of things going on. I'm eyeing someone. If nobody raises their hand, I know who I'm going to call on. Anyone have a project that they've been working on the last year? Lauren, do you have a project you'd like to tell us about. I was thinking of stuff I can't talk about, but the one I can't there's lots of incidents. I can't talk about any of those. But there's a project that I started called the Oops Project. Which is to encourage people to report when they encounter an operational surprise in Netflix. Even if there's no customer or business impact at all. In order to sort of encourage people to sort of self reflect and learn about things that happen and to focus on learning from our successes. Not just things that we think have gone wrong. Yeah, that sounds great. I totally understood that. Lots of times I hear a project and they'll use a lot of technical terms, and I'll be like, I didn't get any of that, but that was great. Let's give Laura in a hand. And do we have anyone that has a project with lots of technical terms in it that they would like to. Share or any skills you've learned that you've recently leveled up and you'd like to say, hey, this is what I've learned in the last year. Oh, here we go. There are two. We'll do both real quick. My name is Jesse, so I actually was inspired by what you're talking about because I have a somewhat technical background, but I don't have a CS degree either. So, like, coming into a lot of those recruiter conversations, they go, oh, you're perfect for this position. And then when you actually start the technical interviews, they're like, Why are you wasting my time with this? The skills that I thought about were more of the soft skills in terms of communication. I worked in customer service. I worked in desktop support. So I went into more of, like, the operation side of things. I will say, though, as a question back to you, I've always struggled with how do you sell that to a recruiter in the audience in terms of I can learn the hard skills on the job, but so many of them want those things upfront rather than like, oh, you know how to learn and we can just teach you on the job. Yeah. So one of the things that I use is an example how I've learned before. I use this phrase that people seem to really like it. Why would I start a new job knowing everything? Then I just have to learn a new commute because I hate driving, so I'd much rather learn a new programming language on the job. And then also, I always tell people it's much easier to teach Python than people skills. Would you rather teach someone how to be an adult, to show up to meetings, to accomplish things? So when you tell people, that type of stuff is much harder to learn and there's a lot less tutorials online for it. So when you tell recruiters, like, hey, these are the things I've accomplished. These are projects I took from start to end, and here's some things I've done in it. That's what I do. And another trick I have is I talk so much, they can't ask me as many technical questions. Let's give Jessie a hand. Was there one more? Are we all done? I thought there was a second person. Paul doesn't like me, and when he realized it was me, he just wanted to skip it. He's like, you already talked too much now. So I work as a community manager on the Developer Advocacy Team, and one of the things that I've done is start up a podcast where we're interviewing people in our field about the things they're doing and what they're learning from it. So the things that I've learned from that, I guess, are some organization in terms of the door delivering the product, but then also some experience interviewing people and especially learning to really actively listen to them. It sounds great. It's so funny. I also have an interview podcast, and one thing I learned is that if you say, hey, can I have coffee with you and talk to you, people will be like, no. And if I say, hey, would you like to be on my podcast? You're really interesting. Like, yes, I'll talk to you for an hour. It's just, like, amazing. Let's give Rich a hand. So I want to thank everyone for sharing. This is really fun. A couple of things. If you fell asleep after lunch because you were very full and missed all of that. On my Dev Two blog, I have a post that basically details everything I talked about today. And if you're not sick of listening to me, go listen to my podcast.