Chandler Carruth

I just want to clarify for our audience. Why? Why? I think we can just leave that where it is.

Bryce

He's not in the closet right now. Referring to the closet that he then he records in. But you're not actually helping me.

Conor

I mean Welcome to ADSP the Podcast, episode 30, recorded on June 5th, 2021. My name is Connor, and today with my co-host Bryce, we continue our interview with Chandler Carew and Patricia Oz, which we started in episode 29. Chandler finishes telling us about his path to Google, and then we dive into topics including interviewing, leadership, and so much more. If you haven't listened to episode 29 already, I highly recommend you pause this, listen to episode 29 first, and come back.

Chandler Carruth

And then I get the the two other job interviews that I've I've ever really had. And it was Wednesday interviewed at Google and Thursday interviewed at uh Apple. And I failed both interviews.

Conor

Wait, what also what was the second one? The first one was the uh you didn't get your own job.

Chandler Carruth

Oh, the second one was uh uh I interviewed for uh a startup in uh uh out that was spun out of the university uh that I did internships with. I interviewed with them um uh but it wasn't much of an interview because I'd actually done an internship with them, and and so like they actually they actually were going to offer to hire me. Um but I didn't really want to work in North Carolina for the rest of my life, and so I I wasn't super motivated to to take that particular offer.

Patricia Aas

Okay, so wait a second. So you you interviewed at Google and Apple, and you were rejected by both.

Chandler Carruth

I wasn't rejected. I just bombed the interviews.

Patricia Aas

Oh. I I I you know what? You you are like, I don't know, you're like dipped in luck or something. I I don't know what with your appointment.

Bryce

Um well it's it's funny because but both both Chandler and I got our like first tech job through somebody, through DMing somebody on IRC.

Chandler Carruth

Yeah. I I couldn't have been more lucky. Um so so I do my interviews, and and the interviews are interesting here. So so at the Google interviews, I got uh a really good interview um uh that I I didn't do very well on, but I also didn't crater. And it was actually a very good interview question. I I I ask it myself now, so I'm not gonna I'm not gonna I'm not gonna go into that one too much. But it was it actually made me think about kind of challenging technical problems and explaining concepts in a useful way. Uh it all it thus thereby demonstrated how little professional software development experience I had. Zero. Um so but it but it also demonstrated that I could think critically and such. That was probably my strongest performance. Uh there was another one that was a terrible interview question uh that was basically a brain teaser about how floating point works. Um and I did really well on that one because I happened to have struggled with floating point because I happened to have worked on LLVM. Um but like it's a terrible interview question that like that didn't uh it shouldn't have been a significant factor. Um the other interview question that I remember um that I've talked about publicly as just like one of my least favorite interview questions was like is the last interview of the day at Google. Um and I you have to understand, like this interview process was horrible for me. So I had one outfit that was like interview level professional, uh, because I was a graduate student paying for things from credit cards, right? And uh that outfit, of course, wasn't what I was going to wear at Apple, because at Apple it matters what you look like when you interview at Apple. Um and so for my Google interview, I showed up in jeans and my thesis hoodie.

Conor

Isn't isn't that like what they expect now?

Chandler Carruth

Like What is a thesis hoodie? Well, like like the the hoodie I'd been wearing hadn't had a chance to launder like the call of the thesis.

Bryce

That's what I thought. That's what I thought.

Conor

By thesis, I thought you meant you got like a no no I defended my thesis. No. No, no, no. I misunderstood. No, no, no.

Chandler Carruth

I'm sitting kind of kind of punch junk from having defended a thesis on Monday, printed it, submitted it on Tuesday, got on a plane, flown across the country, slept after flying across the country for one night, got up and like arrived at Google's campus at 9 a.m., and I'm sitting in a lobby surrounded by people in suits with portfolios, like looking sharp, like for an interview in my jeans and my thesis, like, hmm, hoodie. Hmm. It was it was something else. The last interviewer shows up, and he asks anything that like shows up, and he's like, uh, I want you to implement Wget. Like the tool, Wget, just implement it on the whiteboard. Go. Go. I looked at just like I was like, I was like, I've I've never done networking pro network programming in my life. Like, I literally have not written socket open parin once. I didn't like it just it just never came up. It was not a particular focus of mine in school. I just like all the code I'd written was all around compilers and video game graphics and not around like networking. And he looks at me and is like, I mean okay, but like fine, fine. Just walk me through how this works like like you can use pseudocode, that's fine. I don't care if you know any network, like, but like walk me through like what you would need to implement Wget. Like, you know, send an HTTP request and get a response. I looked him like I do not know anything about the like HTTP. I don't know the protocol. I have no idea what's needed here. I don't know how he blinks at me and he's like, you don't know where you're interviewing, right?

Patricia Aas

Yeah, I was that was that was basically what I was thinking. He's like, this is Google.

Chandler Carruth

And this And I was like, yes, but I've worked on like compilers and programming languages that says so on my resume. Like you shouldn't be surprised by this. I didn't actually like claim anything else on my resume. Um and and so he kind of like uh and so like he's like, okay, well diagram what you know. And I basically like said, like, we're gonna send a request to the server, and the server's gonna send a response. And he's like, So let's talk about your favorite programming language. By the way, folks, that's code for the interview's over, and I'm gonna fill the remaining 45 minutes. Um dear. Yeah, my interview didn't go well.

Patricia Aas

Would you have hired you?

Chandler Carruth

Probably not.

Conor

Good question.

Chandler Carruth

Um, honestly, probably not. Uh so I can I can tell you why I got hired. Um, it was because of my open source work.

Bryce

And so I was about to I was about to say that that I that I'm almost certain that the reason that they hired Chandler and the reason that they went out of their way to set up an interview with him had nothing to do with um how he did in the interview. Um like I I I I think I may have told this story in the past, and uh if not, I I apologize in advance to my team member who I'm about to embarrass, but not by name. But I had somebody who approached me at CPPCon um uh a few years ago and said, Hey, I think I want to come work at your team. And uh I told her, send me your re your resume. Um and uh she did. And I like this isn't somebody that I'd known previously. We'd we'd met at the conference that year. I talked a little bit, thought she was impressive. She sent me her resume, and I like looked at her resume in her GitHub for about five minutes, and I was like, Yeah, like I I I I I have all the information that I need now. Like, and like I like there will be interviews that will happen, but like I am deciding here at this spot, five minutes after looking at this person's resume, that I am gonna hire this person. And we did hire, and it was worked out wonderfully. And you know, for for sometimes you just know it's somebody that has, you know, a prolific open source background, and it's just like you want that person.

Chandler Carruth

And so uh because this uh person who got me to send the resume in in the first place knew about my work in LLVM, and he knew how the hiring process at Google worked, and so he made sure that in addition to my interviews, they also were aware of the open source work. Uh and uh my understanding is that uh this was still not especially impressive, and I've looked at my open source work from then, and it was not especially impressive.

Patricia Aas

Um it's time.

Bryce

No, no, it's it's a lot of it's it's about potential though. You know, like I I I think that this is like one of my skill sets is like being able to like recognize untapped potential or whatnot. Like sometimes it's not about what the person's done, but it's about what potential you see in what they've done. Like maybe maybe somebody hasn't done a lot, but if they're if they're like very early stage career and at this point in Chandler's life, he would have been very early stage. And so you you know and honestly, my guess is because this was somebody that you knew Chandler from IRC, right? That it was not somebody that was like new from IRC. Is it somebody that you'd interacted with previously?

Chandler Carruth

Only on IRC. I've never met them face to face.

Bryce

But it was probably less about the open source contributions that you made, and it was probably more about how you'd interacted with that person, the sort of questions you'd asked on that IRC channel sort of discussion.

Patricia Aas

I I then I have a question because you have like Connor, you you can you can bow out on this one, but but both Bryce and Chandler have met me in real life. You've interacted with me on various media, uh and you know, and I've maybe watched me speak. Um so would that be I I don't know if you have looked at my GitHub, but but would that be sufficient for you to say I think maybe we should hire her? Yeah.

Chandler Carruth

This this doesn't compute in a bunch of ways because uh you're not you're not like super new in your career and just starting out, right? And so there are a whole bunch of other questions that I want to know about.

Patricia Aas

Oh, and that brings us to the list.

Chandler Carruth

And that does that does bring us.

Patricia Aas

So I will I will I will catch you up on the list. Uh so the so the list is basically uh four stages of your career. Uh, and and it's a lot around hand uh handling conflict. Uh so so um the junior, I I'm I'm I'm I have named them, so you you might not agree with the naming of them, but the junior role is a lot about uh uh uh conflicts uh within the team, so with other other team members, but but very much at a peer level uh and and and failures uh uh in uh within the team, with the project, but something that is very directly to the person. Now I I'm interpreting, so you can you can tell me if I'm uh yeah. Um the second one I I I call senior, uh and that's that's more about like building consensus uh as well as as looking further than the team, looking towards the customer and towards other teams. And then also again dealing with conflict uh here. And then the the one that I had a hard time, uh so like middle something uh role, and that's that's now in vision and and and aligning teams and having more of a broad multi-team kind of thing, uh, but still pretty hands-on, you know, it seems to me. Um and then you know, you're in the more of the leadership kind of role, tech leadership kind of role, uh, which is like the fourth one. And now you're in influencing higher uh like ex like the like the XX and and and also looking at at strategy, but not only within the company itself, but also in the industry. And again, dealing with with but but I I I don't there are a little bit of a conflict there, but there it seems not so much dealing with conflict and more like how to to move things. Yeah. Would that would that roughly describe these?

Chandler Carruth

I think the only thing I want to tweak about that is the the leveling here. Um really the third group is so I think of this as right like uh junior or like entry level, right, like like engineering, right? And then the second one is as you know, senior or or kind of like team lead, right? Like like you know, uh project lead, that kind of thing. The third one I think is already really into leadership, and that's that's why that's why it shifts a lot between the second and the third level here. Um and the fourth one is is um not about kind of entering a leadership role, but scaling your leadership, right? Um and so so kind of the the scaled up aspects of leadership when you want to kind of operate at a even broader uh even broader kind of scope and scale.

Patricia Aas

So so one of the things that that a lot of people think about or wonder is how you transition from one stage to the next. Um and and and so where do you consider yourself to be in these like four stages today?

Conor

Oh gosh, I don't know. Is it also worth mentioning? I'm not sure. We can ignore this, I can cut it out even uh, but like at most companies too, there is like two different tracks that I think there's like the management track and the IC track, IC standing for individual contributor. Um like does that is that worth mentioning here?

Bryce

I I think I think it is, but I think there's also a common misperception here, which is that there's almost always a third track. There's almost at at some companies the the the management and leadership are combined, but um uh that's not always the case. So I think that you should think separately about solely an individual contributor, leadership, and management.

Chandler Carruth

I mean, I I we can we can imagine a bunch of stuff. I can't I can't speak to any other companies. I've only like like you you've heard the story now of how I got my job at Google. That was the first real job I got, and so I can't really speak to anything outside of Google, but on at Google at least, there are there are two tracks, right? You're you're either on kind of the the the technical track or the management track. And uh they both go up, and you can you can become a leader on either track. Um and and and so they both have the kind of growth potential here, but they they do change your focus, and there's plenty of overlap between them two. They're not they're not like rigidly separated tracks. They're really about you know what your primary focus is as like in in your job and in your career.

Patricia Aas

Okay, so you are on a technical track, I assume.

Chandler Carruth

So I happened to be on the technical track um uh at Google, and I I don't know, I mean, I I I struggle to be kind of I don't wanna I don't wanna be. Yeah, Connor, you might have to cut this out. I don't know how to say where I am. Like, on one hand, I think I don't have a clue about any of this stuff. On the other hand, uh uh at this point at Google, I'm I'm pretty pretty solidly in in you know operating in the fourth bucket here. Uh I've been I've been I've been very I was very lucky to get into Google. Um but one of the one of the consequences is that kind of uh coming in at Google as like the the bottom end and just barely getting past the interviews kind of uh shook my world a bit and I got kind of weirdly ambitious all of a sudden.

Patricia Aas

Uh like ambitious like career-wise or ambitious like Yes.

Bryce

Oh, okay. But you but you say you're on the technical track at Google, Chandler, but you do have director ports, right?

Chandler Carruth

Oh yeah. Um so I'm I'm on the technical track at Google, but I actually manage a large organization at this point.

Bryce

Yes.

Chandler Carruth

Like I have I have over 60 people in my organization, uh and I'm I'm responsible for not just managing people, but managing managers.

Bryce

Yeah. See, and it it's a bit, I think it really depends from like company to company. Like I I'm I'm in a you know a leadership role. I don't I'm I spend very little of my time these days at NVIDIA writing code, um, but I don't have direct reports. And that's just sort of the um uh I had I had opportunities to go into uh uh a track where I would have um direct reports, but it I did not think that that would allow me to rise as high. Um and in NVIDIA there's you know that there's a role where you can be a leader of people without you know being without actually managing any people. So I think it really depends from company to company.

Patricia Aas

So what what what is that role called?

Bryce

Like is that like a principal engineer or what is so at NVIDIA usually that term is associated with like architect, um but also NVIDIA is not a company that has a very rigid hierarchy. Um so titles aren't really that significant at NVIDIA. It's you really you get to shape your own role. Um so it was really just that you know uh at some point I decided that the way for me to get more things done was to uh spend less of my time as an individual contributor, more of my time sort of as a leader of people.

Chandler Carruth

But uh for for for what it's worth, right, while I have reports that's not universal, it's not even all that common for people on the technical ladder. Um and and I'm probably going to be having fewer reports over time, not more. Um but uh this is kind of like uh uh you know it's come and gone. Uh the group I was in had a real need for someone to kind of step up and do kind of higher-level organizational management. Um and so I you know stepped into the role because there was a need for that. Um but in uh in some ways my my goal has also been to largely kind of you know replace myself in that role over time. Uh I'm hopeful to go back um even more towards I'm about as far towards the kind of management and organizational leadership as I ever want to get. I'm hoping the pindle swings it back a little bit more towards technical uh things in the future.

Conor

Yeah, just it's I think it's worth mentioning because for those that aren't that are listening to this, that aren't at what I would call a technology first company like NVIDIA or Google or, you know, there's a lot of large names, but there's also a lot of smaller names that are the technology first. I first worked at a uh financial company that was not technology first. And one of the big draws to wanting to switch to a technology first company is the fact that they have this delineation between tracks. And at a lot of non-technology first companies, there's a single track where for the first few levels you're technical, but if you want to progress past that level, you have to switch to management. And I, at least at this point in my career, don't really want to be managing people. I want to be solving hard technical problems. And at technology first companies on the IC track, it uh typically you don't you don't have to have reports if you want to. You can go from your senior engineer to principal engineer and have like a big impact by solving the harder technical problems, by mentoring, you know, younger senior engineers and whatnot. Um, and that's a path that exists at basically every single tech first company, um, which like for me, someone that wants to like follow that path, at least at this point in my career, is like awesome. Where there's a lot of companies that um you hit this sort of like level, and then they're like, well, if you want to progress, you gotta start managing people. And uh there's a lot of I don't want to speak for everyone, but like at least for for myself, I definitely know maybe maybe at some point I might want to manage folks, but definitely right now I just I love typing code too much.

Patricia Aas

Um when I was at Cisco, they had they had this uh idea of a principal engineer, and it was actually like something that because we're like we have like a satellite office thing thing. Cisco buys company, so we had a company, Cisco bought it. Um so but but so I basically found like all of the documentation for this like principal engineer stuff myself, and uh part of that was like um it said uh basically to become a principal engineer you kind of had to have already been doing the work. That was like a thing. Uh and the funny thing is that I I was at that time doing the work, but but but then I was told when I was like I brought it up that I want to kind of go in that direction, and they told me no, this is an honorary title. This is like we give people that they've been here for like 15 years, then you know, they get this title because their hair turned gray or something.

Conor

That's unfortunate.

Bryce

I think anytime you see a company that has um uh a strong association between seniority and rank, that's that's usually a little bit of a red flag. Um I mean it's obviously I think it's you know it's usually gonna be present to some degree at some company, but um that should not be titles shouldn't be honorary, right? Titles titles shouldn't be uh something that you reserve for the folks that have been there for 15 years.

Patricia Aas

Um so but but but uh the reason why I thought about it was because one of the one of the requirements for getting this was that you couldn't have any direct reports. And so they gave the title to to uh to someone while I was there, and they that that person had to to uh to lose their direct reports to be able to get the title. Interesting. It's just it was weird to me.

Conor

That's weird. Yeah, especially if it's honorary.

Bryce

Earlier this year I switched to sort of a new role at NVIDIA and um I had the I there was an opportunity for me to like consider switching over to the management track, but the the reason that I didn't was that um it it sort of unintuitively to chance you know Connor was talking about how some companies you have to manage to to rise up the ranks. Whereas I looked at if I was going to become a manager at NVIDIA you know what level of manager would I be? And I realized for me to get to the next tier of manager and the tier beyond that, I would have to be managing more people than I thought I would be comfortable with managing in the next five years of my career. Whereas on the technical track, I could be in a role where I was a leader for very for for the size of people that I was comfortable being a leader for, or even more. And there was plenty of room for me to grow that that there were at least two levels you know above where I was that I could reach for in the next five years without going outside of my comfort zone. And so that's why I decided to stay in the technical track.

Patricia Aas

Okay. So so you you're both speaking like both you and Chandler at least are talking about this idea of leadership but but separated from management. So so you're talking about technological leadership in some way and it seems to have like that that expression seems to have content for you. So what does that mean?

Chandler Carruth

I mean for me it's it's it's about you know influencing uh and like setting direction and this is and this is why you can kind of see this uh showing up in in the kind of questions that I was probing here right like it's about establishing a direction and a strategy uh at and and the scope at which you do that right the scope of the problems that are solved by it scope of influence you have to deploy to it to achieve it.

Patricia Aas

What does that mean though? That sounds like very vague like give me an example.

Chandler Carruth

Sure. So you know uh uh an example of this would be your your I'll take one from from my own experience here right uh if we're if we're if we're at Google and we're we're actually using you know uh GCC and at the time the the compiler is not really meeting Google's needs right um actually figuring realizing that the the the needs that we have are not for just just a better compiler but for example for tools built on top of the compiler in order to help our code base scale and our developers kind of deal with uh the challenges of C. It became very clear that we needed a different platform. And so one of the things I had to do was to go around and convince everyone at the company that like no we're going to we're going to directionally pivot from building on top of GCC to building on top of Clang and LLVM not because they're better. At the time they weren't even they weren't better, they were actually worse as a compiler. But because they're going to give us the leverage we need. We're going to be able to build the tools we need to build on top of them. And so as a direction we have to kind of pivot the the entire company's direction so that we can build those tools.

Patricia Aas

So how do you do that?

Chandler Carruth

Largely it's about presenting uh a good argument with good evidence to support it to the right people at the right time. And so you you have to be able to get into that room I guess to those people that is one thing you do have to have access to the people who are who who you need to kind of convince. However at least at Google that part is is is actually probably the easiest part. If you put in enough effort you can almost certainly talk to anyone at Google that you need to in order to try and convince them of something. It's very unlikely that you you can't find a person that you talk to even if there are kind of you know some some layers that you have to work through you can at least find the person at the first layer and if you can convince them they're going to make sure you can talk to the person at the next layer of the company. And it's an incremental process right this took us uh uh this took probably I would say six to seven years to really establish this uh directional shift at Google um fully right and there were just a lot of milestones along the way and there was a lot of you know kind of pushing this directional strategy further and further and further at each set stage of this. And and the kind of the the surprising thing is that even this the thing I've outlined, right, changing the the compiler from one one technology stack to a different technology stack because of a different set of use cases that we have that's actually that's actually itself just an incremental step. That that right like everything kind of decomposes into these kind of incremental components. And so that's actually an incremental step of you know changing the direction of the strategy for how we write Code at Google. And another component of that was Google kind of uh becoming much more heavily involved in the standardization process um and right and trying and trying to push on the industry and the standardization process in order to shift C and kind of bend C towards being a better a better tool for our developers.

Bryce

So I I think for me I I think a lot of people tend to think of like when we talk about the distinction between leadership and management people think that means that oh the the leadership means having the vision and and like management is dealing with the people and I don't I don't think that's actually the case. I think leadership is about recognizing sort of where you want where where things need to go and then inspiring people to believe in that vision. So I think it's fundamentally about people. It's about there's a big difference between ordering somebody to do something, saying do this because I told you to and inspiring them to do it because you've you've convinced them that this is an exciting thing or that this is the right direction to go in or that this is something that they should believe in. And I think that's really what leadership is about. You have to understand um the problem that you need to be solving you know the the um the the business that you're in what your users need and then you need to be able to identify what is the you know the solution to that problem. And then you need to get your people to believe in the problem to believe in your users to believe in the business and to believe that the solution is the right way forward. And I think that my experience may be a bit colored by working so much on community driven projects and standards committees and volunteer organizations because when you're in a volunteer organization you can't just tell people what to do. You have to work with you know when people volunteer they're going to volunteer to do what they want and you can't just give them orders. And so perhaps my experience is a bit colored by that of of you know of that that the only way that I can get people to do things in a lot of contexts is if I can inspire them to do it because I can't just tell them to do it.

Chandler Carruth

I want to I want to let everyone in on a secret uh that's always true. Um so so a lot of people think that like open source or standards committees or other things are different here. I don't think they are I think I think this is actually truly common. Um right so I I you know at Google we're we're we're we're a big company these days right we're a big company. So there are plenty of teams and managers who I've seen basically like receive direction like go build this thing over here. If the people on that team don't believe that this is a good idea it fails every single time with like like there's no I have zero success examples when a group of people a team didn't believe in what they were building but they built a thing that was successful.

Patricia Aas

Like I have literally zero examples I I have an example but I have an example for like really sad reasons. So so because one of the things that I noticed when you are talking about this is that you are never really talking about uh getting people to listen to you. Uh whereas so my entire career has basically been every room I walk into I have to prove that I am competent to be in that room. So that is like my entire career is is working from like negative 500 the moment I walk through the door. And and so so so I so like the shift that I I managed to do inside of Cisco we build these telepresence systems for for conferencing rooms. I did a massive amount of research I did uh like probably like 20 hours of presentations I built prototypes I built an actual like like a like a like a full product where with with cameras and and microphone arrays and and a touch screen and we had web stuff on it and it was like I I I had to this I had to really because nobody would listen to me because I was a girl so so the lengths that I had to go to just to get people to listen and when I went into the room and I said the way that we're doing things now it won't work and and getting someone to actually listen to that it was so hard because nobody and and and in the end when they bought my idea they they called a meeting with 20 male engineers and they didn't ask me to come and then I I think you're absolutely right um and I it's you know I think people like Chandler and I um I think we we tend to be loud people who who um you know we have strong opinions and we don't we're we're we don't have a problem sharing them.

Bryce

And I think because we're you know white guys in tech, that's very acceptable accepted right um that you know like if if I I spend most of my time going into meetings and pitching people on crazy ideas that nobody believes in yet and trying to convince them to believe in that. And it's easier for me to do that because I know that it's acceptable for me to do that and that like I feel confident doing that. But you Patricia as a woman in tech um one uh you're not gonna feel as comfortable doing that because you know that you know that there's a huge bias against you. And two, it's so much harder for people to listen.

Patricia Aas

I would be the one presenting and people would shush me in the meeting I had a guy who was like an executive saying in the meeting who do you think you are and I was like I'm just here answering a question you asked me.

Chandler Carruth

I think I think there's also like it it's it's weird right because um one of the I mean one of the things that's kind of I I've been fairly lucky with is uh that the the you know certainly I I get a get a foot in the door right by being by looking like everyone's expected image of of random geek helps. But I think it's important for people to realize that um that that helps and it makes a big difference. But I actually think the goal and like the challenge is is it's structurally the same. It's a difference it's a it's different than magnitude a big difference in magnitude but you you still have to convince people to listen to you.

Patricia Aas

Well the thing is that the thing is in the end the the way the way I won was by proving my point. I didn't win by convincing anyone like I I could I convinced them by by proving the math. I I didn't convince them because they believed in me. They didn't believe in me at all. What I managed to do was to prove by implementing by it because what I was saying was not and no matter how much research and no matter how much I would present nobody would believe me. So the only and and this is the reason why I won and this is also one of the reasons why I think women have to be engineers because I won because I could make it I would have never won if what I came in there was was some kind of like crazy uh idea I I I came in with a product I could demonstrate it.

Chandler Carruth

And and by what I'm trying to say is that's that's how everyone ends up winning. At least in in the meetings at Google like I I have I certainly have never been able to just convince people.

Bryce

Yeah.

Chandler Carruth

I I've had an easier time with it, don't get me wrong but like you you you always have to uh I think come in with the product.

Bryce

Usually usually for me the tide sort of the tide tends to turn like when it's far too late. Like like it like I what like I I typically try to convince people of things you know early on um and they only will get on board once it's become inevitable that that's what we're doing like and it's already sort of already happened. But but I but I do think that um like yeah I think what what Chandler what you're saying is right is like yeah that like often oftentimes you're not going to convince people you just have to go and find a way to show them um I had one particular project recently where I sort of realized there's no way that I'm gonna convince people if I don't just go show them on that although I turned out to be wrong I was able to convince them otherwise um but but it's harder for for I still think that the but that the bar is different for for if you walk into a room and people don't expect you to be competent then then they will treat you differently.

Patricia Aas

They will speak to you differently but even worse they will not listen to what you're saying. I I've been in meetings where I will speak and then then the next person will speak and nobody will ever mention that I s said anything and then you know four minutes later a guy will say exactly what I had said four minutes earlier and then everybody be like oh yeah very good point and I'm like yeah but yeah no but it's it's I I yeah I I had I had a manager go to me and said Patricia you need to be more like because I said that I will people were stealing my work and you know and he was like ah you have to be more assertive and you have to like like like say I made that and blah blah blah and it's like and and so I was like okay fine because you know that's how all of this process works it turns it against you so it's you that's wrong. It's not the system that's wrong it's you that's wrong. So I was like okay fine so next time somebody presented my work as their work I said yeah it's great that you could use the thing that I made to do this and my boss was furious. Yeah it was yelling at me and I was like I'm sorry but this was what you told me to do. It's like I'm sorry I can't win here. It's like there's no there this is not a game that is winnable.

Chandler Carruth

I mean I think the only winning move is to you know go to a go to a company or an organization where this does not happen. That's that's that's the winning move.

Bryce

One thing I have uh I have found tends to help here um at least in my experience is if there is something where I've said it well I feel like I feel like I'm answering the same question multiple times or like I'm I'm explaining something and like people just people are just not hearing the words they're just hearing whatever they want in it. That is often when I realize okay it is now time for me to write this down in some document or put it in slides or something. And and sort of sort of to have some sort of paper trail where the next time that it comes up I can just instead of giving the explanation again, I can just point at I'm not going to get into that right now look here. We've already done that and here's the paper trail and like here's the answer to your question.

Patricia Aas

Yeah I had to do that all the time there's no way for me to come into and that was also when my boss was like yeah why do you always bring a PowerPoint presentation to every meeting and I was like not only do I bring a PowerPoint presentation to the meeting I will send it in the invite you nobody can come and tell me that they did not see it or didn't get it and that it's not documented and time stamped.

Bryce

I've started in every meeting that I run I take detailed minutes and I send them out and I I almost never read the minutes like immediately afterwards. A couple of the people who are on the meeting invites do read them and give feedback so they are useful in that regard but the primary reason that I do this is that three or four or five times a year I get asked for a paper trail on something and I now have this magical power where I can be like that happened on this date on this date on this date and we said you said that that and that and that and it's just like end of discussion.

Patricia Aas

I I I had a wonderful like he he uh two two mentors or bosses I guess uh at some point in my career and they had a very good uh like uh motto they said that the people who write the minutes decide what was said yeah so so they said whenever you are in like a meeting especially if it's antagonistic in some way you make sure you are the ones writing the minutes and this is if you look at the history of the COBOL programming language which was the first language developed by a committee that's one of the in in its it's a COBOL is a very interesting language because it was developed in the 60s and s most of the primary people behind its development were women.

Bryce

Well how did that come to be well two reasons one at that time being an engineer or a programmer was not you know the cool thing it was it was it was all about being a businessman the business logic so most of the technical people involved were women but two who took the minutes in those meetings who was the one that was running the meetings where they were developing COBOL it was always the women the the heads of all of the subgroups of the COBOL committee like I think like 60 or 70% of them were women and like there is an incredible power in being the person that is running the meeting or that takes the minutes. Like you get to literally write history.

Chandler Carruth

So I'm just curious should we try and get back to the actual okay or do you want to just keep going so so so so Mr Cruz.

Conor

We'll pause here and resume part three next week. Thanks for listening. We hope you enjoyed and have a great day.