We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Diversity is Not Just a Checklist

00:00

Formal Metadata

Title
Diversity is Not Just a Checklist
Title of Series
Number of Parts
45
Author
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Many organizations say they want diverse teams. In this talk, I address how, beyond recruitment, individuals and managers can create a culture that sustains a truly diverse environment. Using my own transition, starting out as a functional business analyst, to working as a DBA before becoming a DevOps/Infrastructure Engineer, I discuss how individuals and managers can take specific actions to foster creativity and diversity of thought and empower team members that may be subject to unconscious bias. Culture is a choice, and every team member makes a difference, regardless of their level. Good culture benefits everyone, and communication is key to creating good culture. I will discuss how specific communication choices can help anyone enable their team to create a positive, productive environment.
ChecklistInclusion mapBitIntegrated development environmentInclusion mapChecklistLevel (video gaming)Focus (optics)Staff (military)QuicksortVideo gameData managementJSONXMLUML
TelecommunicationAxiom of choicePresentation of a groupCuboidGenderStaff (military)JSON
RWE DeaDatabaseSystem administratorFunctional (mathematics)Configuration spaceData managementComputer-assisted translationCoefficient of determinationSystem administratorDivisorSpacetimeError messageOperator (mathematics)Traffic reportingGene clusterWordSequelConfiguration managementDatabaseData managementTelecommunicationArithmetic progressionImplementationBoss CorporationFocus (optics)WebsiteConfidence intervalFunctional (mathematics)CASE <Informatik>Stress (mechanics)Expert systemPhysical systemDivision (mathematics)Autonomic computingIntegrated development environmentWave packetPoint (geometry)Stack (abstract data type)Computer animation
ArmCollaborationismCompass (drafting)DemosceneSpacetimeSystems engineeringSet (mathematics)Shared memoryJSON
GenderNormed vector spaceChecklistConfiguration managementMultiplication signCASE <Informatik>Connectivity (graph theory)Boss CorporationVariable (mathematics)Data conversionSlide ruleType theoryExpert systemInformation securitySummierbarkeitDifferent (Kate Ryan album)Speech synthesisGroup actionRight angleOnline helpSingle-precision floating-point formatData managementTraffic reportingComplex (psychology)Degree (graph theory)Information technology consultingProcess (computing)Real numberVideo gamePoint (geometry)Endliche ModelltheoriePhysical systemResonatorMusical ensembleTheory of relativityGenderTask (computing)Wave packetToken ringInheritance (object-oriented programming)Boundary value problemWordOpen sourceMereologyTelecommunicationDependent and independent variablesPressureObservational studyWhiteboardSet (mathematics)Expected valueConfiguration spaceCustomer relationship managementData structureChecklist
Data managementDependent and independent variablesCASE <Informatik>Type theoryWave packet
Speech synthesisIntegrated development environmentProof theoryNormal (geometry)DatabaseMultiplication signGodCollaborationismNumberShared memoryInstance (computer science)Entire functionExecution unitMaxima and minimaScaling (geometry)SpacetimeFormal languageCASE <Informatik>Observational studyComplex (psychology)Open setPosition operatorInsertion lossMathematicsScalar fieldStaff (military)Query languagePhysical systemEqualiser (mathematics)Set (mathematics)CuboidComputer animation
Inclusion mapInclusion mapRevision controlData conversionCollaborationismJSON
Inclusion mapMereologyBitConfiguration spaceDifferent (Kate Ryan album)Multiplication signMedianQuicksortCellular automatonArmGame theoryDependent and independent variablesFlow separationDecision theoryStress (mechanics)Data conversionContext awarenessResultantData managementProcess (computing)View (database)Medical imagingIntegrated development environmentException handlingGenderComputer-assisted translationBit rateFormal languageVideo gameAxiom of choiceEndliche ModelltheorieIdeal (ethics)Contrast (vision)CollaborationismShared memoryFamilyMereologyImperative programmingLevel (video gaming)Representation (politics)Boss CorporationWeightTranslation (relic)Inclusion mapConfiguration managementWechselseitige InformationRight angleFigurate numberComputer animation
Right anglePosition operatorVideo gameFlagMultiplication signWave packetPower (physics)Point (geometry)View (database)Graph coloringNP-hardSet (mathematics)Table (information)Process (computing)Universe (mathematics)Presentation of a groupRoundness (object)Integrated development environmentSound effectMereologyDescriptive statisticsCuboidDirection (geometry)Formal languageChemical equationOpen setShared memoryPerfect groupSoftwareTablet computerSoftware developerMatching (graph theory)Intelligent NetworkLecture/Conference
JSONXML
Transcript: English(auto-generated)
So, diversity is not just a checklist. I feel like companies in HR frequently use diversity as a trendy buzzword that focus on the facts of a person. For example, I'm a queer South Asian Hindu woman. But sometimes what they miss is the story that's told by the
background of their engineers individually and collectively. I'm going to frame this talk on the story of my background and how that influenced the teams that I've worked on. What I want you to get out of this talk are actionable ways that you can support your diverse staff. This talk is not for managers alone. It's meant to be for engineers at
all levels to show support for their diverse teams. In this talk, we'll talk a little bit about who I am. I'm going to define diversity, what it looks like, why you want it and how it plays out in reality. I'm also going to talk a little bit about advocacy,
why it's needed and what it looks like and to dispel the notion that you need to be some sort of superhero or diversity champion to actually make a meaningful impact on a person's life. And I'm also going to talk about inclusion and how an inclusive environment can create a
positive feedback loop that creates a more positive culture to support your diverse teams. So this talk came about because I've been told that I have a unique path by a lot of people. And I've been asked how I got to where I am today. Now, if you had asked me a decade ago if I was going to give a talk about diversity, I would have emphatically
said no because I'm a technologist at a tech conference, so why am I not giving a tech talk? Well, a decade later I have frequently been the only woman, the only brown person, the only gay person, the only gender nonconforming person, the only Hindu on my teams. And therefore
the composition of my teams matters a lot more to me today and the communication choices employed by the engineers that I work with as well as myself matter a lot more to me.
So that's why I'm giving a talk about diversity, to help promote the well-being of your staff and in particular your diverse staff. So as we've discussed, I'm a queer South Asian Hindu. Fun fact, I was born and raised in Texas, in Houston. I have a wife who's over there, two cats, a dog, and I'm an amateur woodworker. I was up until recently
a senior infrastructure engineer at HERE, formerly known as NAPTECH, in their highly autonomous driving division. I'm now the director of site reliability at ActiveCampaign and have been for the past week. As we've already mentioned, I was a high school teacher,
a DBA, a business analyst, a database developer, et cetera. So how did I get here? That I was actually wanting to work on the tech side. But I was told, because I have really
great communication skills, that I would be more successful and I should work on the functional side. And as a young South Asian woman growing up in Texas in the 80s, I was socialized to believe that you shouldn't contradict your elders or superiors, and in this case that was my supervisor. And so I actually started my career in tech
as a functional business analyst. And what I noticed as I was doing this, as I progressed is that I was gravitating more towards the reporting side, working with SQL, writing macros, and just generally getting involved with scripting. And so what happened there
is that eventually I was in a space where I met a DBA that was willing to mentor me. And so through her mentorship, I started to get more and more involved in actual database administration. And there was one particular system where I was the functional expert on it. It was a legacy system. I was the functional expert. And so I started getting
more traction and more involved in the management of this database. And eventually there was a team member of the DBA team that ended up leaving. And so the work on the DBA that I was being mentored by had increased considerably. And so she gave me that database to manage entirely. And so that was my first taste of being in a fully tech role. And it was
really exciting to me. And through that mentorship, it gave me the confidence to go out and find a role as a DBA at a trading firm. And in this role, because of the mentorship that I'd experienced, I ended up expressing interest in NoSQL. And so my boss was super
excited and he was like, great, go to town. You can have it. We're about to implement MongoDB and Elasticsearch. They're yours now. You own it. And then he was like, oh, yeah, by the way, we need three clusters of each. The MongoDBs will be three node
clusters and the Elasticsearch will be seven node clusters. And you just send them up like now. Now, if you're manually doing this, this seems like a lot of work. It seems somewhat brittle and it seems prone to error. But what I had heard some of the infrastructure engineers talking about was this magical thing called configuration management.
Now I'd been working in finance. So unsurprisingly, in 2009, not a lot of financial firms had been using configuration management up until this point. And so this was new to me. And so I'd expressed an interest by telling my boss, I was like, hey, you want me to spin up these environments? I think it might be a little more resilient if I use configuration
management. And he was super excited and was like, great, here's our expert. Please pair with him and solve this problem. And so that's what led me to DevOps. And from there, I ended up becoming the ELK Stack expert and then growing these skills, which
led to my career in infrastructure today. Now, the mentors that I'm talking about enabled me to follow a career path that I love instead of one that I tolerate. And so I want to focus on how we can all be those mentors and facilitate more diverse members of our
community to follow a path that they love as well. So why do I care about diversity? Well, look at me. But also, seriously, my background necessitates it, right? So because I followed a non-traditional path, I didn't follow the systems engineer path to being
a DevOps engineer. So I bring skill sets to my teams that would otherwise not be there. But that also means that I need some compassion and empathy and collaboration to fill in the spaces where I don't know everything. And if we have a collaborative team that enables
knowledge sharing, then our team can be stronger. So what is diversity? Where do I find it and why do I want it? Diversity is not just about race or gender. It's also about the skill sets that people possess. In my case, the fact that I was a young woman with a liberal arts background made it so that my vocational interests were overridden
by the facts of me. And I'm certain that I'm not the only person that this has happened to. Picking up on that example with NoSQL and configuration management, nothing pointed to me to be the person to take this on. Like, there's nothing in my background that made me special. What was special is that I expressed an interest, and my manager
at the time took that interest and turned it into real, concrete skills. And so I'm sure that you've heard the usual advice that if you don't ask for what you want, you're not going to get it. And while that's certainly true, it goes directly counter
to 20 or so years of socialization that I have saying that that would be rude and inappropriate. So while I have been working on asking for things more directly, one of the things that I do and other people who may share my cultural background may do is to use a soft
ask. A soft ask is where I express interest in a skill or a training or something to gauge the interest of the person I'm talking to. Because if they're interested and I get a positive response, then I'll continue that conversation. If they're not interested,
then I know that I'm not going to be supported, and so I abandon this path. What was really remarkable about the situation that I was in is that my boss not only listened to what I was saying, but he did one better. He took what I was saying at face value, and then he extrapolated on it and was like, hey, do you want to do this thing,
or how do I make it easier for you to do this thing? So if we all try and do that, then our teams can actually diversify their skill sets. So why is this useful? So in the case of the trading firm, at the time there was one expert in the
configuration management tool that we were using. But when my boss paired me up with him, I also became another person that was an expert. So you're eliminating single points of failure. Second, the configuration management system that we were using at the time used MongoDB as the backend, and we were having a lot of problems with that. Now, I was the expert in MongoDB, so I actually figured out what the problem was, and by pairing with this guy,
I found out how it was trying to write the returns down, and I fixed that problem. So not only did we make the team more resilient, we also made our tools more resilient. So that's an example where diverse teams can produce better solutions. And then thirdly, what my boss did for me was that he was growing my skill sets so that I was,
I felt more satisfied and happy, and I felt like I was doing something fun at work. So he was buying my loyalty. It took a little effort on his part to listen more closely to his employees, but it ended up with tremendous gain. So there are a lot of studies that show
that diverse teams are more successful. But there are a lot of articles being written right now about diverse candidates fleeing from toxic cultures. So why is it that a checklist is not enough? If you'll humor me, I'm going to use a wood example. So I made this cutting board for my wife as a Christmas present, and I was super stoked about it.
I paid a lot of attention to what it would look like and the appearance. So I put hard maple in the center, and I lined up the grain, and then I bordered it with toasted ash. Six months later, this is my cutting board. What happened? Well, because I was more focused on
appearance than function, the toasted ash has now fallen and blown off the sides. And it's blown off the sides because wood is a living thing. It moves over time, and different types of wood have different types of wood movement. By aligning all of the grain, I just compounded that issue. So I could have avoided this by thinking of the components of my design instead
of just think and how they respond to different variables instead of just the appearance. So we're talking about people and not about wood. So what does that look like in real life? Well, so I'm going to take an example from very early in my career. At my first job,
I was a consultant at a bank as a business analyst. And it was my review time. And so my boss was like, Rhea, you're awesome. I love you. Everything you're doing is great. You have great communication skills. Your client relationship management skills are awesome. But you're really short with this
guy, and everyone's noticed, and you're usually so personable. What's going on? I'm really This is my review. So I feel a little obligated to respond. But up until that point, I hadn't said anything because I grew up in Texas in the 80s. You don't talk about sexual harassment.
You want to know why? Because in my experience, what I've witnessed is that women are A, disbelieved, B, made to repeat that experience, and then disbelieved again, and C, even if they are believed, nothing actually happens. So in this instance, what actually happened
is I said, hey, boss, so I didn't know how to bring this up to you, but I feel really uncomfortable because this guy is staring at me. By staring, I meant undressing you with your eyes, which I'm sure every woman in this conference room has had happen to them. And he stands too close, like if I turn around, I'm touching him, and is
just making me feel really uncomfortable. And of course, what happened is exactly what I'd expected. My boss said to me, well, Rhea, this guy just came over from India. He's really young, and I was hoping that because you're so personable, you could teach him how to treat women. Yeah, for real. So this let me know that this cutting
board valued the comfort of my male coworker and boss more than it valued my safety or security. And shortly thereafter, I blew off the cutting board. So how do I help
diversity thrive? First, I want to dispel the notion that the person I was talking about in the last slide is a bad guy. People are complex, and they're more than the sum of their parts. The people I use in my slides are all people I highly respect and would likely work with again. So in this example, that manager in a really complex
reporting structure where I didn't actually report to him, he fought for me to get a raise in a promotion that he didn't have to. But he's also human, and he made a mistake. In this case, it's a pretty egregious mistake. But I'd also like to remind you that it's been a decade since this happened, and the world has changed, and therefore
our sensibilities have also changed along with it. So it is okay to have empathy for that guy, that new young guy, but the other person in the story also had a point. I had a point that I should not have to feel uncomfortable every day at work. So
in an ideal situation, what I was looking for was not for someone to take action with HR or fire him or anything. What I wanted to happen was to have my manager hear what I was saying and actually say something to this dude like, hey, you're at work. Here
are some boundaries. Don't stare, leer, or stand on top of your coworkers. So that's a highly charged situation, and there are some other situations where you may not find a solution. But there's also other ways to help diversity thrive. For example, in the example with my boss from the trading firm, he was opening up doors
for me. He was using mentoring and pairing to actually diversify my skills, to give me things that I needed, and to actually really help his team be a better, stronger team. And that's a really good way to help diversity thrive.
So in speaking about those examples with my manager from the trading firm, those are all examples of advocacy, and I want to talk about two types of advocacy today. One is self-advocacy and the other one is advocating for others. The examples I've given so far are advocating for others with my manager and the DBA I worked with where they were
opening up doors for me by knowledge sharing, training, and in the case of my manager, actually opening up new responsibilities in my role. But there are other ways that engineers can advocate for each other as well. A very useful way is through amplification.
So there are studies that show that women's voices are not heard as well as men's. Now, the study talks about a lot of complex details around language, and I'm going to let you investigate that yourself. But in the instance where we're talking about women's voices not being heard as well, I've had this happen to me a number of times. And one way to counter that is to amplify other people's voices, which is to repeat their
ideas and give them credit by name. So one of the most frustrating times that this happened to me where I wasn't given credit was when I did a proof of concept as a dev team I was working with and they were having some performance issues. And in these performance issues, what I did is that at the time we had a giant box
for MongoDB and that's not how it scales. You scale it by sharding. So I did a POC and by sharding the database, I saw a 20% performance gain with no other changes to the system. So I reported this back and it never got implemented
anyway. Now, a couple months later, we were talking, my male counterpart and I were talking to this team and they were complaining about query performance. And we both said that you need to shard your database. More than a year later, the idea to shard the database is still credited to the male
DBA, regardless of the fact that I did an entire proof of concept with a 20% performance gain. So it doesn't have to be intentional when this happens. My male coworker wasn't trying to take credit. He was just repeating something that was a fact, which is that to scale MongoDB, you scale horizontally. But even if it's unintentional, it can have negative
impact on the career of the diverse staff that surrounds you. So it's really important to be mindful. Now, a really positive example is that at my team at Here, I never really thought that an individual team member could change the entire culture of a team until I met my coworker, Russ. Now,
Russ does this thing that's really awesome and also sometimes really embarrassing, which is that he credits you with your ideas. And it could be something as simple as when I first joined the team, we moved to another floor and I had suggested the desk layout. And this increased our collaboration. Russ was so excited. He was like, this is the best layout
ever. Oh, my God, look at Rhea. She's awesome. This is so amazing. I love Rhea's idea. And he would say this like a half a dozen times. So I was mortified. But that says a lot more about the environments I've been in than it does about anything else, right? And but what happened is that he would say it at Scrum and stand up too. Like if you helped him with a story,
he'd be like, oh, yeah, I was working on a story, but Rhea had this idea and it fixed all my problems. So great. And so by openly acknowledging each other's accomplishments, what he was doing was that he was amplifying our voices. And he didn't just do it with me. He did it with everyone. And what I noticed is that because he did this consistently, we all started
to do it on our team. So when you all acknowledge each other's accomplishments openly by name, what ends up happening is it's not just amplifying the voices of your team members. It starts amplifying your team. It starts creating this open culture of collaboration where knowledge sharing is the norm, where knowledge sharing is made a
priority, and therefore everyone's skill sets are valued equally. And so that's what that also does is that because knowledge sharing is now the norm and it's considered high value, it empowers your team members to advocate for themselves. Especially as a diverse person coming
from a background where this is not always the case, it's particularly important to have a space where you know that you can advocate for yourself. Because you know that even if you're in a toxic environment, you kind of have to advocate for yourself to get anywhere. That's just reality. But if you're in a positive environment where
knowledge sharing and open collaboration is the norm, this is a great way to be able to advocate for yourself. Because not only are you in an environment where you are comfortable, but by mentoring and pairing with team members, you can grow within the environment
that surrounds you and you can feel out what opportunities are available to you. And so speaking about a culture of collaboration, this brings me to inclusion. So to better support diverse teams, including everyone in the
conversation, is a really crucial step. When I feel included in a conversation, I know people hear what I'm saying and give me credit for the ideas that I have, then I'm more willing to participate fully and give an unchilltered version of my ideas which leads to more creative and better
solutions. Because you have the full participation of your team. So talking about inclusion can be a bit tricky because sometimes not being inclusive is not always deliberate. It's not always a deliberate decision to exclude people from the conversation.
So there was one environment that I was in where there were a bunch of guys that started a private chat channel and it started with sports and gaming, but it didn't really end there. And I was eventually invited to that
channel several months into my job, but what I noticed is that the guys that were junior engineers or interns had been invited quite a while back. And some of the stuff that was going on in this private chat channel is that a lot of the junior guys were asking the senior engineers really simple questions. Now asking questions is good because that's knowledge sharing, right? Except if it's in a private channel, what
does that do to everyone that's not in that channel? It means that when I was not in that channel I didn't know that there was an environment of knowledge sharing. I didn't know that people were receptive to asking and answering questions. I didn't know whether it was safe to ask questions or whether their perception would be that you're
uninformed and that you're not a contributing member of this team. So it creates a culture of fear instead of a culture of collaboration. In contrast with that there was a time at here where I was
talking to my co-workers Russ and Lee about immutable infrastructure and Lee had brought up immutable infrastructure and at the time it had felt a little bit dogmatic to me, which was weird because that's not what he's like and not what our team was like. But what was interesting about this is that Russ and I had just done a lot of work
to make our Chef configurations much more resilient. We had just spent a bunch of time on our recipes and cookbooks because that was integral to our deployment. So then bringing up immutable infrastructure and like using Docker images or AMIs instead was just, you know, felt very invalidating at the time.
But what was really cool about this conversation is that in the middle of the conversation, Lee said, hey I just want to clarify that I'm talking about immutable infrastructure as a philosophical ideal. I don't want to invalidate the work that you just did and I don't want to say that the work that you that you've been doing and
working with configuration management isn't valuable and may not realistically be the right choice for the situation that we're in. I believe that immutable infrastructure is the ideal. What's really rare about this example is that I've very very seldom had a really heated philosophical
technical conversation with someone about best practices where they took the time to stop and check in and validate that they respect your ideas, they respect you as a person, and that they want to bring you into the conversation so that we can come up with the best solution we can really determine what the best practices are
instead of defending an idea and dismissing your idea. Because I know that when my ideas are dismissed I no longer feel safe to bring my unfiltered ideas to work. I use Russ and Lee as examples because in my experience they are
ordinary engineers who are extraordinary because they try to build a collaborative environment by checking in using inclusive language and showing general respect for the people that they work with. You think that these are really simple but it is actually very powerful how you use your language
at work and how well that translates into an inclusive environment. Those examples where Russ was giving us credit that creates a positive feedback loop. It creates a positive culture and a positive feedback loop that builds your team up. Shutting down and dismissing ideas does the exact opposite.
Now being new at work I can tell you that as a new person it can be really anxiety producing and I'm sure that a lot of people when they're first at work suffer from imposter syndrome which I do as well. But one of the things that you may not
realize is that as a member of many underrepresented communities I also feel a weight on my shoulders to be a representative of those communities. I feel like if I don't know what I'm doing and if I fail I have now let down all of my communities and that the door to diversity is closed.
So in those first few days of work what's really helpful and what my boss has helped me with where I'm at currently is something where showing people and using your language to show support for diversity initiatives to show support for not always knowing something and for growing and learning in your
environment. It helps build an inclusive environment and another thing that I've noticed is that you know once you're at work right one of the things that many of my co-workers have said to me is that you know yeah I'm the same guy everywhere you'll find me like home work outside of work wherever I'm just the same guy.
That is not an experience I share. As a member of the queer community I definitely feel out my environment to figure out where it is safe to present my full self. For example I don't bring my whole self to my family. I don't look like this when I go home. I don't look like this when I go
see the community that I was raised in because it is not well received. While my wife has been welcomed with open arms being gender non-conforming is much more challenging. So going back to that soft ask people in your environments may be employing this until they feel safe enough to bring their whole selves to
work. Something that's been incredibly meaningful for me was that my co-workers Russ and Lee showed me that they were listening and hearing my ideas consistently and they would check in if they felt like there was any sort of misunderstanding so that they could clarify that they
respect and care for me as a human being was critical to me realizing that it was important to bring my whole self to work. Understanding that people with different backgrounds may not feel safe to present parts of themselves is not enough. When I was hiding part of myself there's
a low level of stress that I feel because there's a risk that someone might find out something that I don't want them to know and I don't know how they're going to respond. Not being able to gauge that response can feel very personal and very risky. Demonstrating that you're listening and hearing what they say builds that trust to bridge that gap.
Creating an inclusive environment shouldn't be a nice to have it should be something that always exists because that's how diversity thrives that's how we bring our whole selves to work. In review being inclusive helps find and support people from diverse
backgrounds and advocating for their success empowers team members to contribute to their fullest. Remember to listen, hear, and ask your team members what they want and lastly raise your own awareness whenever possible. This talk may be a first step but it should not be the end of the journey.
If there's nothing else you can think of doing simply remembering to name the person when you hear a good idea and give them credit can have a really meaningful impact on that person's life and their career and it's a concrete first step you can
take and because this is a DevOps conference I couldn't resist a cat gift. Cat gifts for everyone and I will open it up questions and leave it on the cat gift. All right let's give it up for Rhea. Awesome job. All right
we'll open it up to questions and just please wait for me to bring the microphone so you can hear your own voice which is fun. Hi a lot of what you said really hit home for me so I just want to say thank you off the bat. Just a quick like I don't know if anybody else has suggestions or something but ways in which we can bring
diverse candidates to the table to begin with especially in tech or what your experience was kind of you know we all have our own stories but so sadly that's a really hard question for me to answer because honestly like I know that there
must be other like lesbians in tech but the only time this has happened to me is once at that trading firm I was talking about and when that happened one of the guys earnestly asked did we know each other because of course there are only two lesbians and lesbians of color in DevOps in the city of Chicago of course.
So it's hard for me because most of my co-workers have been male and unfortunately mostly white too like there are some other ethnicities but part of the myth of the pipeline problem right is that it's not that there's a pipeline problem but who do you know right and if I look at who I know I'm
going to say 90 of the engineers I've worked with are not diverse so I mean I think part of it is just networking right like one of the things I've done in Chicago is to try and network with girl development and like other I think there's a a blacks in tech slack and meet up and like stuff like that so like just try and reach
out to your communities of color because there are tons of candidates everywhere I promise. So I guess to that effect when you evaluate whether you apply for a job or you consider a job what are the things that attract you from your background and your point of view and what are the red flags that make you think this isn't a place that I'd want to work?
So I think that's really hard right it's hard to tell from the outside what it's like what I usually look for is during my interview what are how are people treating me because there are definitely those jerks that you know in an interview that want to like make you feel like you don't know something that's a red flag immediate
red flag and then also just talking about how their teams work together if you start to notice that there's if people talk about their individual accomplishments and never as a team that's also kind of a red flag so I mean but it's it's very personal right like this is my personal style of figuring it out.
So this is mostly a comment on like the first question and just some ideas like one thing that we've done is if we have an open position and it's only white males who are applying to it we're going to keep it open until we find someone else to apply to it at least because the thing is is if you can't get someone who's not a white male to
apply to it something is wrong with yeah you're networking and so you need to fix that and you can't just let it keep perpetuating. It can also be something that's wrong with the language in your job description because I know that for me I'm far less likely to apply to a job if I don't have like 90 to 100 of the skill sets and that is totally not true for my
male counterparts. So thanks for sharing. I really appreciate the your openness and candidacy when you know when you're in your your presentation. I think we all learn a lot from that. So on the diverse bringing diverse candidates to the pool and looking at diverse slates
how much have you seen I guess in your environment in your efforts of reaching out to people with diverse backgrounds utilizing diverse interview slates you know diverse interview panels I mean the people that are actually doing the interviewing making sure that you have women and you know people of color
you know on those panels so that as people come in they're being interviewed by people that look like them or people that that can appreciate you know where they where they come from in that aspect. How much have you seen that change? So I don't I don't know about seeing it change so like so the last place I was
working at it here they actually have a very diverse environment so it was easier for us to actually have a diverse interview panel because of the people that our work environment was composed of. Sometimes that's not possible and so then that's really challenging then you're just trying to figure out who
the best match is to try and make an interview panel but you also don't want to waste someone's time because if the skill sets don't match like if the person that you want in the interview room doesn't have the skill sets that you need for the interview then that can just feel like a waste of time on both people's parts so I don't think it's so I think that it's partially
what's in your environment already and also about respecting the person that you're bringing in's time right so there's a fine balance to that but if we do have someone that is more similar to a diverse candidate with the appropriate skill set I do think it's very useful to have them as part of the interview team regardless of if they're going to
be on that direct team or not. Perfect thank you so much let's give one more round of applause for Rea Ghosh.