 Hey, thanks. I'm I'm really excited to talk to y'all. So I should be presenting And thanks for giving me some space to talk about this Quick introduction. I'm Ryan. I'm a principal data scientist in Zilla working on Firefox Bloud pretty regularly. So if you are interested in that you can find the link right there So I'm here to talk about getting credit for invisible work And since time short, I'll jump right in So I said I'm here to talk about visible work. What is invisible work? So for this talk, I'm using a very specific definition And it has these three characteristics. So it's work that is critical to a project success something that you've worked on and is very important Something that takes skill to do well and something that is never shown to your stakeholders So by this definition There's a lot of invisible work this happens everywhere in knowledge work Most of the stuff that we do doesn't ever get shown to a to a collaborator I think this is unusually prominent in data work So if you look at these classes of invisible work, you have like exploratory data analysis and data cleaning Which monopolize the time that you spend producing a great analysis and this never gets shared with anyone downstream Just like a quick doodle of how I visualize the data science process We have a question and then we go through this like data science loop where we like build hypotheses Look for data and reject those hypotheses and build context up the whole time To us this process is pretty clear. We have been making progress the whole time and we can feel that progress What our stakeholders see is they have a question We do some stuff and we come back with an answer And this is this is good. I'm not saying that this is a problem. This is actually super virtuous The data scientist is creating a lot of value when they're building up all this context And nobody wants the complexity that the data scientist is dealing with We're producing a lot of value by simplifying these very complex data sets into something that is actionable But this can cause a bunch of problems When we try to demonstrate our value So I say demonstrate our value What I mean by that is Well, let's talk about it Demonstrating our value I work for a company. I work as an IC. I'm not Mostly doing open source work. So I conceptualize getting Proving my value as maybe going for a promotion or trying to get a raise This is true also working in the open or as a consultant Trying to get folks to recognize the difficult parts of your work is difficult This is actually so this first line is actually a piece that I got from a performance review a long time ago And someone asked me that they wanted to they wanted me to demonstrate more complexity in my work This may sound fine on the surface, but I think this thinking is pretty backwards and this backwards thinking is pretty common in the industry We tend to conflate really complex solutions with really complex problems And what we want is we want to have really simple solutions to complex problems the complexity of our Solution is a cost to be borne not something to optimize for And this is pretty common in the industry I've seen this encourage folks to slip machine learning into places where it doesn't necessarily need to be Uh, and I've seen there I've seen folks make their reports the things that they're delivering to stakeholders I've seen folks make these reports super complicated in an attempt to document all of the pieces That they worked on all of the complexity that they faced when coming to this solution They're trying to express this to their stakeholders that they can understand How difficult this is and in reality what happens is you get a long boring report that nobody really reads And this is super lossy because you could be providing this super clean report Um, but this push for explaining complexity, uh muddies the conversation So, all right, that's what invisible work is that's what it might look like when you're doing work So what do we do? And this is the part where it's going to be a little undersatisfying because I don't have a silver bullet for this What I'm going to suggest is uh, I'm going to explain some of the strategies that have worked well for me in building my career And hope that that helps you in the future Maybe like more importantly what I'm hoping here is that by framing the problem up nicely and demonstrating where this problem is That'll put you in good shape for the next time you're trying to solve this type of problem I found that a well framed problem is 90 of the 90 of the way to being solved So I've had I've three things here I'm going to go through them one by one building a narrative arming your manager and fighting a recency bias So I'm I start by talking about building a narrative because I think this is the keystone To this whole process if we can get this right we can kind of bumble around with the other pieces The key to building a narrative is building this clean memorable story about what you actually did and what was hard about it And this sounds simple on the surface, but I found that a lot of folks don't do it when trying to explain their work Two tips on building this story things that you want to focus on you want to focus about what was actually really difficult about your work I've seen folks really focus on the most technical piece or focus on the solution that they pushed out Those things can be useful to talk about but more often The really difficult part of the work is something that looks like Framing up the problem or finding the right dataset or doing some exploration and getting rid of a bunch of options You want to focus on what was actually hard so that you can communicate that to your peers The other piece is focus on outcomes instead of this is maybe in contrast to the outputs that you created You don't want to focus just on the piece of technical code that you delivered or the dataset that you pushed out You want to focus on how how it changed the company so for example maybe My favorite type of project is one where I decide to do nothing I go talk to the stakeholder we talk through their problems and they decide there's a better way to solve this Than working with data. Maybe they just go out and talk to some folks Maybe they just build a feature and see what happens in this scenario. This is great It's the best case scenario. You haven't done any work. You haven't had to do any work and everybody's happier maybe Maybe your outcome is that you went to a team that was very stressed because I didn't know what was going on And that was making them very skeptical And if you walk away and the team's relieved because they aren't angry anymore, that's a huge win and you should sell that That's something that you should get rewarded for So that's two trips or two tips for building this narrative. I also want to like cover one One risk don't again. I've talked about this before don't share complexity A lot of times folks when building up this narrative about what their work looks like take the Take all of the complexity that they worked with And document it and that they create this big document that talks about all the difficult parts of this work That's really not useful. Folks are going to look at that. They're not going to read it because it is super complex You need a story that you can share with folks and that folks will share with each other Something that can communicate or that can be shared from human to human So that's that's the goal behind this building narrative. I'm going to keep moving at a pretty good click I'll leave some time for questions at the end Once you have this narrative, you need to get it into the hands of someone who can share it around the company for you Uh, sometimes you're going to have to be your own manager But the the goal here is to have this story in the hands of someone who's selling this selling this story around So the high-level piece is that Your your manager or you in this situation is going to be in a situation where they need to Sell your story So you need to arm them and make that as easy as possible for them. Sometimes folks feel like this is a little conceded They don't want to they don't want to share this story about how great they are and have someone pushing that around In reality, everyone's busy. We want you to be successful And your manager is going to be grateful for you for making it easy So giving them this narrative that they can use when they're in a room with a bunch of their peers trying to argue Over who gets promoted if if they have this story and they're armed well that makes them look good And it makes it a lot easier for them to do their job. Well One tactical strategy is once you have this narrative slip it into your one-on-ones and do it frequently This helps arm your manager because this story will be common It'll be something that they've worked over a bunch of times This also helps you build this narrative because the more time you spend thinking about it The more smooth it's going to be and the better the presentation will be Um, it also makes sure that you're aligned I've been caught in the situation where I've built this fantasy about how important my work is And that's not great and you want to get rid of that as quickly as possible This final piece is about finding recency bias. Uh, so This is something that I fell into. I had the first two bits and I was writing pretty good narratives What I found is that when I would look back at my work I would focus on the solution because it's the last thing that I did. It's the thing that solved this whole problem Uh, what I found is that in reality, uh, the solution is an answer to a problem that took a really long time to frame properly And that framing was a difficult work I've seen this reflected even the job ladder that this framing of the problem is the hard difficult work for data work Uh, if you look at different job or as you move up the job letter and you get more seniority The biggest thing that changes is the problems you get are more and more vague So sell that part of the work you're doing Uh, and the recency bias forces you to focus on this last thing that you fixed instead of where you started and what the real business problem was Um, I'm going to skip over this example in the sake of time Um Well, no, I won't all right. So real quick example from my workplace. Uh, this is something that I worked on a long time ago in my career Uh, and it wasn't super technical. It was a uh, etl for a data set that summarized the business metric it Was something like take countries For every day and count this metric and put it into a data sets that our executives can like play around with it and get a feel for What's going on in the business? It's not technically complex At all. Uh, it was very easy to deliver. It wasn't more than a hundred lines of code It took three months to deliver so that's not great. Uh, and all in all this doesn't seem like a great project But once it was launched everyone was thrilled and I got promoted not very long afterwards So what happened there? How did that how did that non-technical project lead to these good results? um, and That goes back to the narrative the actual difficult part about this project Wasn't the data set that I pushed out. It was that the questions I were getting were kind of confused and vague and with a lot of urgency so When I got these questions You know they immediately felt I like to use the the metaphor it sounded like someone asked me to buy them a fridge that they could keep their house cold and it created this type of like skeptical feeling like I don't think That's what you want. Um, and it would have been easy enough for me to Answer their requests the way that they asked it and then just walk away But I knew that that wasn't going to make them happy. Um, so I took some time to dug in and framed this problem Well once I did The main thing that I that I left when I walked away was folks were very confident about what was solved What wasn't solved what we knew and what we didn't know and that like calmed them down that gave them a lot of peace of mind So what I really sold here Was the peace of mind that I delivered to the team instead of the the technical thing that wasn't all that complex So, uh I've got to slip this in so I've I said what you want to do what outcomes you want to create but I didn't talk about like What you actually do like what are the rituals? There's a moment of draw the rest of the owl With this description. So two strategies that I use and I still use today They're super useful or keeping snippets and keeping a brag document. Um, I'll talk about each of these Snippets, this is a behavior that I picked up when I was at google It's been super useful and it's morphed into my own weird type of Ritual uh every week I write down what I did what was important and I try to focus on keeping a lot of Context and keeping a lot of context. This is a really useful tool when you're trying to fight recency bias um Be as specific as you can This has been super useful for me if you're only going to do one of these two definitely do snippets This is collecting data on yourself and what you measure you're going to start improving This also helps you find work that you shouldn't be doing and help you discard it The other piece is a brag document As you do work you get excited about it But that excitement doesn't hold doesn't last right you get more work and you try to focus on bigger things If I look at my work from two years ago, it's not exciting because it's a problem that I've already solved This brag document helps capture That excitement so that later when you're like looking through your work You can be like, ah, this is an index of the things that I should be looking for in my week reviews For my old snippets. Uh, this brag doc helps grab that excitement and helps you share it with other folks so The other thing is it's just a nice dopamine hit and helps you see your progress as a data scientist So I recommend you keep it if only for that reason Cool in summary invisible work happens get credit for it by telling a clean story about what actually happened to your manager And you should probably be keeping weekly weekly snippets Um, I'm going to post these slides later today. I'm going to leave some room for questions It looks like about four minutes If we don't get to questions today, if we don't get to your question Or if you have a shower thought later, feel free to email me blog at harderrt.com And then the only other note is that I'm hiring. So if you're interested, shoot me a resume at csv at harderrt.com Cool, I'll leave the rest of the room for questions Fantastic. Thank you so much for this talk Ryan. I particularly appreciate the reminder for us all to Be persistent and unapologetic about advocating for ourselves and to also frame the narratives That we want shared in a way that is easy for them to be repeated elsewhere by others. Thank you We have one question from Tara and I encourage you to share other questions that you may have using the ask a question Button Tara asks is that value to calculating a return on investment could be time or money? Or is it just busy work? Uh, it depends on how close to the money you are. Um I've had work where like it's very clear how much how much Value I produced in dollars and then that calculation can make sense. I find most of the time We're so far ahead of like actually launching a project we can be in like the research stages or we could be in The very early stages of building up the product and if that's the case It's really hard to make a prediction about how much value or how many dollars will be related to And then that if you don't have dollars it makes it really hard to make that calculation work I think it's maybe more valuable to think about this as opportunity sizing And I just had a blog post about how we do opportunity sizing at Mozilla And there you look at really high level Is this work that i'm doing big enough to be worth my time? And if you can get a like even just a rough estimate about whether those line up I think that can be really useful. Um, it's really easy to work on stuff that You know, isn't hurting the company, but isn't valuable enough to uh, to be worth your salary And no one's going to tell you that that's not worth working on. Um, it becomes a good thing to do great We have plenty more questions ryan. Um, I think I'll highlight one by k and k asks, um What are one second? So what are your thoughts about the challenges of communicating technical work with a non-technical manager? Yeah, that is difficult. I I generally uh What i'm looking for teams I tend to report. I try to look to report to someone who's worked with data in the past if you're in a situation where you're like reporting to someone who isn't a technical manager This this like very clean narrative is Way more important, right because now what you're doing is you're taking your technical work You're distilling it and explaining it to someone who has to be able to tell this particular story Well, and they won't be able to like iterate on the edges Uh, so when they get questions, I'll have to add lip a little bit So focus really hard on making this narrative clean and helping them understand what was really difficult about your work Yeah, what did that answer the question do you think? I think so, um, and there's a related one actually from Eric and Eric asks How will you alter any of your recommendations specifically for academia? For academia. Um, well, I think Uh, I haven't worked in academia. I stopped after my bachelors. Uh, so I I've only looked from the outside and I think they're still very clear, uh Incentives and getting credit for this is still important. Um, academia has a very clear, uh Outline for what they want at least from what I can tell focusing on publishing and getting papers out there. Uh, so I I'd make sure that you were responding to the incentives that they are pushing at you part of this is that, uh In in the corporate world, I've found that companies want one thing and they'll reward another and they just kind of hope that we resist this, uh, we resist this, uh Incentive and a lot of folks do in academia. They're they're telling you what they want. I think pretty clearly and If they're not changing their story, then it's fine to play to their game. Um So they want you to just publish just publish