Building a Model is the Least Important Part of Your Job

In this Data Science Popup session, Kimberly Shenk, Director of Data Science Solutions at Domino Data Lab, explains why building models is the least important part of data scientists' jobs, and what they must focus on instead.

Video Transcript

Hello everyone. My name is Kimberly Shenk. I actually lead product at Domino Data Lab, so thank you guys for coming.

I am going to talk to you about why building models is actually the least important part of your job, through a lot of the experience I've had as a data scientist and in leading data science teams in the past.

I'm going to start off, basically when we grow up as data scientists, we're actually told this really beautiful story of what life is going to be like. I was told the story. And it was really exciting that we're going to work with massive amounts of data. There's a lot of stuff out there. And we're going to be able to leverage this data and ponder through it to think about really, really cool things that we're going to do with it.

We're going to write these amazing algorithms, and we're going to talk to a lot of our friends and collaborate with them and figure out how we can optimize them and get the most out of them. And then eventually we're going to save the world. I mean, ultimately, with the work that we're doing. And that's the most exciting part, and why we're all in this business together.

Then we grow up and we get in the real world and we start working in businesses, and we find that this is not that romantic of a story, and there's a lot of challenges in this process of data science. And so one of the most unfortunate things is that we all start off and we build these beautiful models for business, and then they end up sitting on a shelf.

What happens with a model that's on a shelf, it's actually not valuable at all, unfortunately, we should just throw it in the trash. And this is actually really, really sad.

Why does this happen? Why is it the fact that businesses struggle to find value out of what we as data scientists bring? Why do we as data scientists struggle to provide value and show the business the value that we bring?

A lot of it is because businesses know that they need data science. There's hype. It's all out there. Like your business is going to fail unless you start leveraging data and get really smart about how you're doing data science. Oh man, I gotta get me one of those.

That doesn't mean they actually know how to use you and your skills, and what you're actually going to bring to the business. There's a difference between theory and like what you really, really do and deliver. That's kind of what they think they hired you for in the first place.

Like, “Hey, I'm just going to hire somebody really smart and they'll figure all this other stuff out for me.”

I learned that the hard way, and so that's kind of why I'm really excited about this talk. It's not technical, it's not about modeling. It's actually to tell you that the trick I've found is stop focusing on the modeling so much.

There're four things that I've learned the hard way about driving data science value in a business. And so these are the four things that I'd like to talk to you about:
1. Sales, the most difficult part of the job.
2. Being an interpreter.
3. Thinking like a CEO.
4. Making best friends with your fellow data engineering team.

I'm going to start with being in the sales business. There's this concept where we think we're going to show up, and people are going to know the exact projects we're going to work on and how we're going to deliver value to the business.

In fact, that is not the truth or the case at all. Your job actually is to go in and shine a light on the areas that data and data science can either help the business make better decisions, or drive the product forward. And the reason you're best suited at doing that is because you are knee deep in the data all day.

The business might come to you and think of this really cool thing that you're going to work on, you're going to be like, “Well actually, that doesn't work because I (a) Don't have the data or the resources or blah, blah, blah. But I do know I have these seven things, and this is how I can help you.

You're the one that's actually going to be shedding light on what you should be working on. And then you actually have to craft a compelling story and put together a pitch deck, and this is really, really frustrating.

It can't be in theory. You can't walk around and theoretically tell people what you're going to do. You have to get sample data. You have to work on a small subset of the problem or a single use case. And you need to get a prototype into the hands of the business. Show them, tangibly, they can see, “Oh wow, this is what you do?” That will help with the buy-in process.

Finally, I think that the last point on here is something that you would see in any sales 101 training, like, believe in what you're doing. This is something that I found to be one of the most important pieces of what I did, is that I was—or you, as a data scientist, are the face of data science, and the biggest advocate of what it will do in your business.

If you don't, in your core, really believe in what you're doing, and that what you are going to do is be a competitive advantage for the business and help actually drive the business forward, then it's going to be really hard to sell that and have the business leverage what you work on.

You've got to walk around and be the face and the champion, and as you start to embody that and advocate for that in the business, other people will start to come along that journey with you.

Okay, now you've sold it to the business, and you're working with lots of people, and you're getting in a lot of requests. The next phase of this is really understanding the actual problem that you're working on.

The next piece of this is, “Oh my goodness, we're getting a lot of stuff to work on. We're delivering, we're delivering, and them we're finding what we're delivering is actually not providing value in the first place, anyways.”

Another basic 101 that you would do probably in any kind of agile exercises, the five whys.

This is really dumb to put up on the screen, but I cannot tell you the number of times I myself, or have seen another data scientist, sit in a room and all of a sudden get Yes-man syndrome and be like, “Uh-huh, Okay, yes, I will deliver that to you.”

Instead of getting to the core of, “Wait, what's the problem we're trying to solve? What's the root of this? Why are we doing this? How is this helpful to the business?”

What ends up happening is that, so the immediate problem is, okay, you work on something, it's not actually valuable, it doesn't actually do anything for the business, and it wastes everybody's time. It kind of ruins your morale. That's the immediate problem.

But actually the meta problem that compounds over time, is the business starts to ask, wait, what is this data science team really doing, and what value are they really bringing us?

That's not a good thing, because you're not actually solving any of the problems that are really valuable. That's why the key here is to really decipher, what is the problem that I'm going to solve, and get to the root of that, and be really good at doing that?

Okay now, you've sold to the business, you're actually interpreting and working on the right things. The next big thing is, you're going to have a lot of stuff coming in, and you're going have limited resources, and you're going to have to prioritize and figure out like, “Okay, well what the heck are we actually going to work on?”

This is a really hard skill set to have, because you have to think holistically and strategically for the business. What could I do that's going to actually drive the business forward? So you have to be the objective party in the room.

For example, one of the really fun exercises that I used to do with my teams was role-playing in a room. Maybe we all practice what it's like to get somebody give us a request. They're selling you hard like, “This is going to be the most important thing!” And you have to think through, “Okay, well how is this really going to impact the business? Where do I really see this fitting in?” And learn not to say yes right away.

That's the hardest skill set actually, right there is not being like, “Yes, yes I'll do that for you!” And run back to your—because you naturally want to be helpful. Practicing as a group and peer practicing playing is actually a really powerful way of doing that.

Another one of my favorite things is to—my counter-question in all situations is to say, “What decision are you really going to make with this work that I'm going to do for you?” I cannot tell you the number of times I've heard, “Oh, cause it would just be nice to know.”

That's great, but if you're not going to make a decision, it's not going to drive the business for it, and we have limited resources and five million things else that we could be doing. We're probably not going to prioritize that thing.

Very parallel to that stream would be, “What thing is going to change based on the work that I'm going to do for you?” That's a very similar but nuanced question because it helps you get at the privatization piece.

Is this thing that I'm going to do fundamentally going to change the way we generate revenue? Is it going to change the way we do this marketing campaign, email campaign? The magnitude of those two things are very, very different. If you can get at the core of that, it will help you understand how to prioritize what you and your team is working on.

I think the final thing here is it's like, as you're assessing things for the business holistically, and having that strategic lens view, so this is a lot different than being on your computer coding, but actually trying to figure out, what are the things that will drive the business forward? It'll kind of fundamentally change the way you're structured as an organization, a data science organization.

Say you're essentially a structured team, so you all live centralized. This might be something where you are prioritizing requests from all over the business against each other. Is it product requests we work on today? Or marketing versus sales? You're kind of pitting those against each other.

You really have to see like, “Okay today, what is the thing that is actually going to be most important?”

If you're not centralized, and you're more of an embedded team—so say I live within marketing. I think the challenge there is you have to be able to still up-level yourself and strategically see how the work you're doing is actually impacting the business. Because the challenge there is you get stuck down in the weeds and the tactical day to day of a marketing machine or engine, and then you actually also run the risk of working on things that are maybe not really that important business. That would be the CEO hat.

Let's see. Man, I am whipping through these slides. Okay. So the final point here is that data engineers do have to become your best friend. This was kind of the struggle that I learned firsthand, and that I kept avoiding through a lot of the beginning part of my career, because I didn't really embrace the fact that I couldn't actually successfully do my job without them.

They give you access to data, they give you the tools and infrastructure that you need to do your job. And they also actually help you put the work you do into use by the business. So for example, if I need to get the work I'm doing integrated into a business tool, or if I need to get it run or scheduled to run on a certain basis. Or if I need to actually throw what I'm doing into play into a production environment. They're there to help you do all those things. But the problem here is that they're usually very disconnected and disjointed from the business. So they don't understand how you are actually working closely with the business to drive something forward.

One of the most powerful things that I have found working with a data engineering team is actually walking them through your day-to-day, and having them understand and have empathy and context behind what you're doing. Literally, like sitting next to them. Because they need to understand, first off, the problems that you're actually working on. They need to understand the demands that you have coming at you from the business.

A lot of times they don't have context behind the magnitude of what you're actually working on, and how serious it is that you get something delivered. And then your workflows, because a lot of the push back I get it—why do you need that tool? What are you doing for? What, you can't just use this kind of concept? If they actually walk through your day-to-day and understand how you're working, then there's that buy in of, “Oh, that's why you need that tool.”

I think another point is interesting is that—I don't know if this is just the maturity of the field in general—but a lot of times they think that what you're doing is very theoretical, and like, “Oh you're just out there thinking of really cool things to do,” but not actually tying it back into, “This is the business objective that we're driving forward.”

Finally, if you are integrating something into the business, I found that it's powerful to bring that business partner along with you, especially to help give context into the significance of the work that you're doing.

Okay, so this all sounds really great in theory, and I think I gave a couple of tangible points on how you could actually act on some of this, but how do you put this into practice?

We all know that in tech, the probability of becoming a billion dollar, or a.k.a. unicorn startup is actually .07%. So stop looking for the unicorn in your team. I think that this concept is just really frustrating because they're just really expensive. It's going to cost you way too much. It's really hard to keep somebody like this happy. And I'm not actually convinced that this person really, really exists. It's too hard to do all and be all and actually be successful.

Something that I found that is really, really powerful and another dumb quote, but we all know that the whole is greater than the sum of its parts. There is this concept where you can find things that people on your team, or you, naturally gravitate to.

Do you have somebody that is a natural sales pitcher that just likes to go out and create crafting, compelling stories and show examples? Or is there somebody on your team that is a natural problem interpreter that can really get to the root and say, no, I got through all that fluff and this is the core of what we have to solve? Or is there somebody out there that's like a little mini strategist CEO thinker, and that has a conceptual concept of the business really down, and understands what is going to drive the business forward, and how you or the team are going to be a competitive advantage for your business? Or do you have like a data engineering socialite that, you know, can speak that language and really get the buy in of that team?

Building out these individual areas of expertise I think is what gives you that well-rounded team, and letting people focus on that area, and come together in a more symbiotic whole. And so finally, the last thing I will say here, and I just blew through these slides, so I will have lots of time for questions, or not. But the last thing that I'll say here is that we obviously also consider a software solution that will help you facilitate a lot of these things.

There are a lot of concepts here that we believe actually, at Domino, that we help with, and I'm happy to have a conversation with you about that afterwards. But that is all I had.

So does anyone have any questions?

Questions

Q: I have brilliant data scientists, lots of PhDs with degrees in decision sciences and statistics. And we have—in a different part of our global organization, we have data engineers. So I was curious more about your journey that lead to making friends with the data engineers. It turns out to be a lot of my job, is to calm them down about actually agreeing with their people. But what was your journey like, and how did you bridge that file?

Yeah, so the question is the journey of becoming best friends with your data engineering team, and bridging the gap that occurs when your data engineering team sits all the way over here, and you have your really, really intelligent smart data science team, full of PhDs and statisticians and people that don't necessarily know how to fill that gap.

The answer is, my journey on that was first, denial. Like, I do not want to deal with that. I don't like that stuff. Infrastructure, blah. Like, I want to be over here. Then learning the hard way, multiple times, and getting burned, I started to—I think I've used this phrase before—me and the head of data engineering became attached at the hip. And I had to forge that relationship myself. So first, starting with him, his name is Colin, or at the time, Colin.

Me and Colin—I would sit down with him. I would invite him to team meetings. I would have him understand, this is what the business is asking of us. A lot of times data engineering just sits in the back, and this is not condescending at all, but literally they like to sit in the back room and do things that they don't actually see driving the business forward. But if you get them in the hot seat, and they're with the head of sales who's asking you for this thing, then they're like, “Oh, shit. Like that's actually really important. I didn't realize the heat you were getting, and how I was preventing you from actually doing something for that person.”

That will have them spawn that sense of urgency. The other thing I found and was able to do is, I ended up building a very tight relationship with our VP of engineering so that I could have the analytics and data science roadmap drive the data engineering roadmap. I think that's extremely important that those roadmaps are tied together, because I can't have the data engineering team working on something that's completely orthogonal to what's important and what we're working on right now. There had to be a, “Okay, this is what we're planning for this sprint or quarter, or however you do your data science planning, based on what we're seeing from the business.”

And then I have to go immediately and almost be PMing, ew, but driving the data engineering roadmap and be like, “Okay, this is what's on the docket.” How are you going to help me with those things? Are you going to have bandwidth? Are you going to have an engineer on call to help us? All those kinds of things.

But yeah, it's painful. And it's like a full time job. And it's not sexy.

Q: I was going to ask about backlogs and roadmaps and all that good stuff. But what I'm interested in now is, it sounded like there should be, or could be a trend to maybe use, Agile, Scrum, to get all the different stakeholders, engineers, together and kind of form a team. Do you see that as a trend, where they're going to start to projectize, and use Agile methodologies and things like that, like they have done in other standard IT projects?

That is something we struggle with too. So the struggle I have with that is that the reason Agile works so well in engineering—and this is actually going to be very personal. This is my viewpoint, is what I'm trying to say—is there is a defined project, and you pretty much know, or you're going to do a Spike to understand what the solution to that is. You can define, like with this amount of time you should be able to deliver this, and you can get really concrete on that.

Data science is a little bit more ambiguous, to the point where you kind of know—you know the problem that you're going after, but you have no idea how you're going to get there, what data—there's a lot of thinking and testing and iterating and experimenting. If you put bounds around that, I think that's what limits the really excellent innovative work that can come out of it.

So I do absolutely believe there should be bounds, because if you never deliver anything—which is what I'm like just advocating against—you actually provide no value. So it's like that 80-20 rule. But the problem with strict Agile, Scrum methodologies is, is it really does say like, “All right, you have a day to experiment, good luck.” And you're kind of like, “Alright, well it's the first thing I came across.”

So, check. Moving on to the next thing. And then what you produce is not actually even valuable at all. So it's that weird line. I do think there's going to be interesting ways of tracking workflows, and how that process is done I think needs to be really well-refined and hasn't been solved in the industry. But yeah, if we're not careful we'll get to that.

Q: Yes, yeah. Very well said, by the way, what you just said. I strongly, strongly agree. I'm curious, where do you tend to see data science teams fitting in to your organization. In other words, is there other, better kinds of executive sponsors? Like is it engineering? Is it finance? Where?

Oh, that's a really good question, because I've bounced around quite a bit within my organization. So I started off in finance under the CFO. The thing that I struggled with there is that everything is looked at in terms of a financial problem.

So everything has a revenue target. Everything has to be in. That's fine, that's an interesting lens of the world. But when it comes to how you're impacting product decisions, or how you're actually trying to—maybe not optimize something that has to do with revenue and marketing, but something else—those kinds of projects get cut. That was a really frustrating experience.

Also—this could've just been my personal experience—I've found that people in the finance organization don't really understand what data science is anyways. They're like, oh, it's Excel, and you build a model in Excel. And that's not really anything close to what we do. So that was frustrating. So then from there, I actually built a very close relationship with the head of product and the head of engineering. At one point we were going to move to engineering, but then it was like, oh wait, it's the same concept we have over here.

Like, we're not really engineers, and we don't want to follow this Agile process, and that doesn't really make sense. You move into product, there's this concept of, this is kind of where we were headed, as data is a product. And it has a couple different customers if you service data as a product. The customers are either external—so external would be how customers are experiencing your product and how you're leveraging data to influence the customer experience—and then there are internal customers, which are the business, and how you're leveraging data and data science to make decisions and drive the business forward.

If you treat it like that, it does fit very nicely into a product organization, and doesn't get wrapped only in that first subset of problems, which is, how do we just build better products?

That's actually where we ended up, but I've heard it's different in every organization, so.

Q: Tell us about a project that you did you really struggled to get started, and then finally, tremendous success, you blew the doors off and everybody took you out for lunch.

That's hysterical. Okay, so this is a great—this actually—I can probably tie this in a little bit with what I was just talking about. So living under the CFO, there's—I wonder how many details I can get into. I could probably give you a more tangible example of being at Eventbrite. That's where I was before.

We really wanted to up-level the kinds of in-product recommendations we were giving for events to go to. So this is like a really basic example. But there's a lot of nuances that go with that, and how you leverage data to do that. So how do I know what a quality event is? How do I know what a quality organizer is? How do I know what's popular? Blah, blah, blah.

There's a lot of interesting problems to do there. But if you're under the CFO, he doesn't really care about that. Like is that going to drive me more money? It's like, yeah, in theory, we think. But this is an experiment. So this was also— we don't have the infrastructure to necessarily support this end to end. I got to have friends with the data engineering team.

This is an exercise where it wasn't that exciting in terms of the work that we did, the algorithms that we built. It was a relationship exercise. It was like, “Alright, now I've got to make friends with the head of data engineering, and let them know why this is so important. Will you take a chance on us? Can we have this be a labs environment, where you will give us the resources so we can have this be a proof case?”

This goes back to creating the compelling sales pitch of, we're just going to make this be a tiny little thing, where we're only going to give recommendations to this group of people, in this city, and for this amount of time, on this little tiny data set, with this little prototype, and we're only going to let—you know.

It just kept boiling down into this smaller project. But then, when we are able to deliver that tiny little thing with the resources and the support from a high level champion—like at that point was the VP of engineering—that was able to show and prove to the CFO like, “Oh you guys do, do things other than revenue.” And “Oh, maybe it is important to build out this data engineering team and actually hire more people to support you.” It started all of those conversations that then led us to be successful in the future.

But it was this really frustrating, tiny little relationship building exercise that I didn't realize, so that's helpful.

Q: Looking at your previous slide on the team, do you believe that—you're being concerned—There you go. Yeah. So looking at this slide, do you believe that every data scientist needs to start in a strategic or technical role before you can go into a strategic role?

No, that's a really good question too. I have had really great success. So both ways, so I've had people that have started extremely technical and have wanted to pop their head above water and be like, whoa, there's a big world out there, help me figure this out.

Then I've had people that have actually started as—a really great example would be, there was a sales operations analyst, and she was very extremely intelligent about the sales side of the organization, how that drives revenue, and all that kind of stuff. But she was fascinated by what the team was doing and how we were coding and building models and what that meant.

You know, I personally think that the attribute that is most indicative of a successful data scientist is not the technical skills, but is innate curiosity. You can't teach somebody to be curious. And so those people are the ones that are going to go the extra mile, and sit down with your team, and do stuff on the weekends, and teach themselves, because they just want to learn. And so, absolutely. I don't think you have to start technical at all.

Sometimes I find that people that start technical are the ones that are building the models on the shelf, and then you're throwing them away, so, ah, frustrating.

Q: Yeah you were talking earlier about where you thought the best spent through your data science team was. Do you have any experience or can you speak to at all a more decentralized team? Or just, do you assign a person in each department?

Yes. So when I first showed up, that's the structure I was handed, or dealing with. The struggle I found with decentralization on a small team is that you do end up—first, there's a lot of redundancy in work. So somebody over here on marketing team might be doing something very similar to somebody on the product team. But they're just redoing it. They're making up on their own. They have no shared context. So there's that.

There's that aspect of it. The second aspect is actually a little bit more nuanced, but it would be career growth and opportunity. So I as a data scientist, and reporting directly to somebody in marketing. Like that person doesn't know what I do. I don't get to work with any other data scientists and collaborate. Or if I do, I have to force this to happen and be like, hey, brown bag lunch, and nobody wants to show up to that because they're busy. Or, it's really hard to facilitate that learning and atmosphere of, we're all in this together, and we're building something great for the company together, that kind of thing. Okay, so there's that context.

Then also just the kind of work that you're doing, I really did find at that size of team, we were starting to work on, like you are essentially doing whatever they tell you to, and it's hard to pull out like, “Okay, you know, there's this concept of, when there's space work will fill the time.”

There might be time, and there's all this like other little work that isn't actually very useful to the business. But you'll just pick it up because you're embedded in that team anyway. So the first act that I did was centralize, because we were small, and it took care of all those first three things that I talked about. But then what you find, which sucks, is that you then become a bottleneck. Everyone's like, “God, it's takes forever to get anything out of the team, and like ugh.”

So now you have to work on the prioritization piece. And you don't want to be the bottleneck. You've put some standards in there. It's like, “Well yeah, we're saying no to you now.” It's taking forever because you're realizing what you're asking for is not very important in our prioritizing the right important things, but has an aftermath.

I do think then there becomes this concept of—at later stage, where we grow big enough to—you start to have a hub and spoke model—that's really technical—but literally you're centralized to reap all of those benefits. But you're also embedded, because you do need to have functional expertise. Like what is going on day to day on the ground, and the marketing team, or the sales, or the product or blah, blah, blah. And how do I make sure I'm meeting those needs, and I'm really learning that business inside and out?

But I also can come back to my core group. And I can share thoughts and ideas and ideate and say, “Oh you've done that before?” I can leverage your work and not reproduce, and stuff like that, so. Yes.

A lot of the problems that we deal with coming from an engineering background, I feel like I have all the pieces that I can do, and I can put a timeline together that's roughly in place. Some of these data science problems can be more moon shots.

Like we're gonna try to land a person on the moon, and if it was, you know, 500 years ago, all the money in the world wouldn't get you to the moon. But if it was 1960, you say, “Oh, you've got a decade to do it. What are the ways that you communicate to management to find some milestones to know is a lost cause, that you should wait 500 years, or, “No, this is about the time”?

How do you work through those milestones that show deliverability on the way? So this was “Okay this problem exactly, I know exactly you're talking about.” My first biggest priority was, “How do I get a seat at the table in the senior leadership room?”

I was like literally, that's what I had to figure out how to do. I—this is why this talk is so painful for me because, it has nothing to do with data science. It's all about the wheeling, dealing of getting in the organization.

Honestly, I've got to get in the room because I've got to get in the conversation of where we're planning out what we're doing as a business and what are our strategic priorities are. Because then, when I know that, I can align all my work against those and say like, “Oh yeah, that thing that's going to drive us $100 million in revenue next year, these are the ways that I'm going to help that, and this is how I'm going to plug into those things like oh man that's how we're going to do that yes resource.”

If I'm outside of that room, and those decisions are all made, and then I'm like trying to pry in and say like, “Oh yeah, that's really cool.” It's all been done, and you're not a part of that conversation.

You're not seen as a strategic thought partner in those—in any of that. And so I think especially—so my experience was, I was part of an organization that was learning what it was to do things with data science, and not just like brute force and got an end product. And so inserting yourself into those conversations opened up a whole new world. But it wasn't me coming up with ideas and selling them.

It was honestly me being a part of it, and then building with those conversations, and then it was just like a natural fit, and you were a resource, and part of the roadmap. I don't know if that answers your question, but you become part of the moon shots, instead of creating moon shots.

So I'll move into a quick problem. Yeah. So if you were starting to fly at the moon in 1600, at some point, you should realize, “Oh this is a lost cause.” It'll be trivial in 500 years, but it's not trivial today. Some of the projects that I have mentioned we're all working on are things that might be trivial in 10 years. But it's not trivial today. It may never happen for another decade.

How do you know when to pause something because it's—you haven't gotten to that level yet? The best way that I can say that I combated with this was, really helping the company to embark on an experimental journey, and having the appetite to be okay with experiments.

I think a lot of what we do should be in a labs kind of environment. You don't know if it's going to work. If it does, it's going to go crazy, and it's going to shoot. But being okay with knowing, like “Okay, there's—we have the leeway, and we have the space to experiment with these 10 things, and we think one of them is going to hit off. But we actually have no idea, and that's just the nature of what we do.”

But that comes back to like, this is why that was so important to me. Like I am the face of data, and in my core I believe that this is going to happen. These are all the examples that we see through time and other companies where this has been successful, where people have made data and data science the core of what they do and how they drive revenue.

We will figure that out here. I don't really know what the answer is. I don't have the gold star. But I know through this iterative exploration and experimentation, we will get there. So give us the space to do that. That was kind of the way we combated it.

Q: So you talk a lot about building relationships. Practically speaking, what's the quickest way to gain some of those skills if you have an interest in that?

Kimberly: If you have an interest in that. Uh, that's a really good question. Gaining the skills in terms of relationship building is what you're asking? Relationship building and also being able to communicate—being able to communicate. Yeah. Being able to work your way into that, being the one making all the decisions. Yes, yes. So there's this concept of—oh, I'm going to forget the word—having a mentor and then a—oh golly sakes, this is so basic it's running out of my head—but somebody who you can look to mentor you in the company through those things, that's exactly what I look for.

I found a senior leader who would be my mentor, but not necessarily the other side—the thing that I can't think of a word for is the person who'll be your champion in the room when you're not in the room, kind of thing.

So there's two kind of relationships—Like Exec Sponsor? Yeah, thank you, Exec Sponsor. So like, yeah there's the person that you trust, that you can get vulnerable with in a room and be like, “Man, I can't do this. Tell me the ways that I can effectively communicate. Can I practice this with you before I give this talk?” Or this comment—like how this conversation—”Can I run ideas by you?”

I used to do that before I would go—thank you—before I go into a meeting with our CEO, I literally would sit down with my mentor and be like, “Okay, these are the points I want to go over, and she'd be like “Ugh, don't do that. You should never say that to a CEO.” I'm like “Okay, thank you.” Practice, and really understand what I should be able to rattle off the top of my head, what she might like come back at me with, all those kinds of things.

Then there's the other side, your executive sponsor, who somebody that you, one-on-one, are selling, essentially, and having them believe in you. For me, that was the VP of engineering.

Literally that was behind closed doors, unless whiteboarding and me like just spouting off my ambition and what I wanted to do, and getting him to really believe in that, and then I didn't have to be in the room and he would advocate for me, to the point where one day senior leadership was having a conversation about what we were going to do, and they're like wait, “Why is she just not in the room?”

And then I was invited, and then it went from there. So those were the two ways that I went around that. Okay, I think I'm up on time. That was fun. Thanks guys, I appreciate it.