Getting Diversity and Inclusion Right, With Jason Wong

jason-wong-diversity-inclusion-software

Jason Wong is an engineering leadership consultant who focuses on Diversity and Inclusion. His past lives include engineering roles with Yahoo! Sports, Etsy, and Blink Health.

In this episode, we talk about the difference between diversity and inclusion, and why that difference is important. We also touch on some of Jason’s favorite management and hiring practices.


Listen to the full episode here


Welcome to Scaling Software Teams, a weekly podcast to help software leaders navigate fast growth without losing the magic that made that growth possible. I'm your host Wes Winham. Today, we're joined by Jason Wong.

Jason is an engineering leadership consultant who focuses on diversity and inclusion. His past lives include engineering leadership roles with Yahoo Sports, Etsy, and Blink Health. In this episode we talk about the difference between diversity, inclusion and belonging, and why that difference is important. We also touch on some of Jason's favorite management and hiring practices.

I got the opportunity to ask Jason pointed questions about what the tech industry gets wrong about diversity, and I hope you learn something from him. I know I did. And now, here's my conversation with Jason Wong.

Jason Wong, thanks so much for joining us today on Scaling Software Teams.

Thanks for having me.

So, you have a pedigree as both VP of engineering and consulting around diversity and inclusion. What do you think tech mostly gets wrong about diversity and inclusion?

Sadly, I think most of the folks I talk to still think of it in terms of a numbers game, right? They're thinking primarily about gender diversity, and they're mostly focused on like the question of how do I hire more women? I think that's... and the conversation I generally have with folks is like you need to be focusing on inclusion first and not just diversity.

Can you define that term for us? What's the difference between diversity and inclusion?

Yeah. So, Brendan Meyers talks about diversity as being asked to the party, and inclusion as being asked to dance. Then, there's the third stage... which is belonging, which is like you're being asked to help plan the party. Really what you want to get to is further down the stage of inclusion, and making sure people can not only just be in the space of the workplace, but also survive [and] thrive, [and] be successful.

So, beyond... so, let's say a company is excited about diversity. They want to move beyond just gender diversity. You've given a talk about bootstrapping diversity. What are things that companies can do to bootstrap their diversity and inclusion focus?

Yeah, I think the biggest thing in that talk that I want folks to understand is (1) there's no easier time than right now. I think a lot of folks think about when you're starting a company you have all sorts of business problems. It's really easier just to sort of defer the diversity and inclusion pieces until later. But, so many of the workplace habits and culture are much easier to influence at the start than further down the line. So, (A) you can avoid a ton of work by getting started on this early. (B) There's all sorts of data out there that we have right now that shows that actually one of the paths to success is to focus on [diversity] and [inclusion], right? It has all these sort of profound, profound business impacts.

Like diverse teams ship, on average, two more products a year. They have far more valuable exists. They are far more likely to be profitable. When I think about my career, you know I've been in tech about 20 years, I don't know if I've ever worked on a product or feature that has had the same impact that these studies are showing that [diversity] and [inclusion] can have for a business. So, if your business is one that relies on profitability and making money, this is actually a pretty savvy move to make early on.

There are other sorts of reasons to do this as well, mainly being that it's the right thing to do. But it never hurts to add on all the extras.

Absolutely. So, instead of shipping that feature that you dreamed up, maybe put in some work towards your diversity and inclusion efforts if you want to maximize for long term. I work with a lot of start-ups that are relatively small teams. So, just by the nature of math, if you have a team of six or seven, or eight people, you probably have a couple "onlys". Like they're the only woman, the only person of color.

If I'm a leader and I have a person like that on my team what are some things I can do to help them?

I think having an awareness of it, right? Like this is something that I think where a lot of people get caught up is they try to boil the ocean in one go. Something that's actually much more useful is understanding what are the set of problems in front of me right now? So, if you have someone who's an "only", get well versed in what the challenges of their particular version of "only" looks like and how they experience it.

Have your eyes and ears open for some of the things that you might hear, right? If it's a woman of color, or a woman, or even an engineer, a black or Latinx engineer. There are a set of stereotypes and tropes out there that you can sort of be aware of. So, if you start hearing one of your fellow engineers complain that so and so is being bossy, or so and so is rubbing you the wrong way, or engineer is being aggressive; you can understand oh, that's like a vague piece of feedback that sort of falls in line with the stereotype threats that we talk about. I can push back on that and say that you're going to do better if you have that kind of problem... We want to get to something that's specific. We want to get to something that's actionable. So, let's think about those types of feedback and the rest of the stuff we can throw away.

So, being on the lookout for feedback that's going in that person's direction, that you know might be falling in line with some of those stereotypes and bias. That sounds like a great way to help. Fighting against that yourself all the time, it seems like a lot of extra work. Take a little bit of it.

Before we started recording you were talking about hiring, and how there's a lot of focus on individual performance. And maybe one piece that's missing is context, and expectations. How do those things impact performance?

It turns out the individual performance is not as individual as we like to think. There's all these studies that show that what a manager thinks of an employee, for instance, has a huge impact on their performance, and what the team thinks of an individual has a huge impact on their performance. So, back in the 60s there's this thing that was researched called Pygmalion Effect. Rosenthal and Jacobson, a psychiatrist and school principal decided to run an experiment on their elementary school.

This is the 60s, I think, before ethics was a thing… There's all sorts of incredibly interesting studies that happen in the 60s, including locking people in the basements of Stanford to pretend they're in jail. But anyways, moving on. Rosenthal and Jacobson, they... administered an IQ test at the beginning of the year. From the results of those IQ tests identified what they called academic bloomers. These were students who were really primed to take advantage of their learnings that year.

So, they told their teachers like, "Be on the lookout for these kids because they're going to do really well this year." Then, the years go by, and they re-administered the test at the end of the year, and sure enough, the people they identified did remarkably better on their IQ test than those who were not academic learners, which you know, on one hand, great. We have this way of identifying really great students. But the "gotcha" was that they just gave teachers random names. So, just the expectation from a teacher that their students would do better actually had a profound impact on their performance.

This study has been reproduced in Israeli Army boot-camps. It even works with mice running mazes. So, it turns out, if you believe that your mouse is a smart mouse, it will actually run the maze faster than if you believe your mouse is not a smart mouse. So, there's this degree to which your individual performance is impacted by what your manager thinks. There's a degree to which your individual performance is affected by the team around you.

I want to stay on the Pygmalion Effect just a little bit. How do we think that might impact the hiring process? So, how might our beliefs impact how we evaluate folks?

What it leads me to [ask] is, what is the purpose of the interview? And, basically the purpose of the interview is partly, for me as a hiring manager, to gain confidence. That can be independent of what the actual data says. If I am confident in this candidates success there's a high likelihood that this person will be successful. Like I have the impact just by my belief.

You saw a white dove on your way to work, and you knew, of course, that means that you're going to have a great interview that day.

Right. Exactly. So, I think you know, a lot of our interview process today is based on survivorship bias. I ask the questions I ask in the interview because those are the questions that I was asked in all the interviews that I got a job offer for. Therefore, it must be a good interview question. That could be something that's just completely off base and way off.

But, because it gives me confidence that's why it works. So, when you have that information you can start experimenting a little bit more, right? And start understanding what you're getting at. What are different ways that I can build confidence around someone? In fact, if I build an interview process that is more about building a confidence case, a yes case rather than a no case, I would actually do a lot better in the long run with my hiring than not, right?

So, if I have an interview process that reveals someone's positives, that might be better than hiring a candidate where through an interview process that has been designed to highlight someone's negatives.

I just interviewed a guest a few episodes ago and, she asked the question, "What could we do to see you at your best?" That's one of her standard questions. Then, they try to sometimes you know, not a take home, but it's a whiteboard. Sometimes it's not a whiteboard, but it's code quiz. That's one challenge I've seen is, no matter what you pick in an interview, someone on Twitter hates it. I've struggled to figure it out, but of course, we're all individuals. We all have our strengths. So, how can we hire for strengths, not lack of weaknesses.

So, our expectations affect our importance. What we think is going to be good is going to be good. We've got this survivorship bias questions. How does context play into performance?

Yeah. So, we have this model of knowledge workers. And the things about knowledge workers in our model is that they are self-contained automatons. So, the idea is that we can... any knowledge worker can up and leave and, go to another place and be just as successful. It turns out that's not quite true. There's a study around cardiac surgeons.

Cardiac surgeons are in high demand, and so they generally work in a hospital of residency. Then, they travel to other hospitals to do surgeries. You would think that because they too are knowledge workers, and they're getting all of this experience doing surgeries that their outcomes would improve over time. It turns out they only improve actually in the hospital of residency, and in these satellite hospitals the outcomes or probabilities are as if they were doing their first surgery.

One of the theories behind why that is, is because at the hospital of residency they have an established team. It's a set of folks who have learned to work well together. They have norms to cover for one another. And, they know where their strengths and weaknesses are. So, that team specific context is what leads to better results.

And actually, there's another one that involves financial analyst as well. Like a financial analyst who moved from one company to another, actually under-performed most of the time. Unless they move with their team. Moving with their team they can actually maintain their level of performance.

So, we should all just be Stripe and have the option to hire entire teams, is that it?

[Laughs] That is definitely it.

That would be nice. What do you think we can do when we're building an interview process? Like if we believe that context matters, that team matters, how can we take that information and turn it into our process to make it better?

That's where we use this term called mapping the potato, which is... I don't know if it was coined by Moisha, or Tim Calzone, but anyways. This idea that we all have our knowledge boundaries, right? We are an indimensional space, our knowledge boundaries are represented in this space, and depending on what they are it leads to a shape that looks roughly like a potato, right? An indimensional space potato.

And like the point of an interview process is to explore the boundaries, right? What are the boundaries in communication? What are the boundaries in some sort of technical specialization, or the boundaries in whatever other dimensions are important to you? And what happens when you go one step beyond that boundary? Like testing sort of how this person deals with uncertainty in those ways, sorts and forms. And at the end of the process you do have this model or this person. Then, the question is, "Well, what can this team support, and what does this team need in terms of new strengths that need to be added? What can this team support?" For instance, if this team is really good at fixing operational issues in production... they could bolster someone who's not as good in this skill for instance.

Then, what does a manager need to build confidence that this person would be successful? Then, when you make a hiring decision it's a compact. It's a compact between the manager, the candidate and the team. That you are all equally invested in the mutual success of everyone on this team. So, the team understands that this is not a person that's going to fall out of the sky and fix all of our problems. This is a person that we get to work with, and will influence us as well as us influencing them. If they're struggling, like we are, we see where they might struggle and we have agreed that we're going to help this person succeed, right?

Same way from the management perspective, the same thing. Like, here's where we understand this person to have strengths. Here's where we understand this person to have weaknesses. I believe this person could be successful here. So, let's put this together and commit to this as a team.

So, people aren't lines, they're potatoes - and our job is to agree to make this a successful potato. I think it makes perfect sense. I love this potato analogy. I can imagine like a mushy weird shape... Sounds great.

I think though, the Spotify model of cross functional teams that are matrixed across the other organization is gaining a lot of traction. I think you've seen that in action a few times. Could you explain what that model is, and what the problems are that folks might hit when they transition into that model?

The Spotify model is this sort of matrixed model, right? Where you have these skills and specializations to report into. Then, you have these sort of squads or pods of, I guess we'll call them "execution pods", right? So, you build these pods out of members from each of these cross functional groups, whether it be design, front end, mobile, backend product, etc. You come together for a short amount of time you build the part that you need to build, and then you disband and go off.

The idea is your manager belongs to your guild... I think I'm describing this accurately. Let me know if this is not the case.

I think so. The only thing I've heard is... sometimes squads are long lived. Sometimes they go in ang disband. I think those are both options.

Right, true. So, the idea is that your manager is in the guild... that's aligned with your specialization and your team lead is, I guess, some other external body or person. Yeah, I feel like... even Spotify doesn't follow this model anymore, if I remember correctly, because it just turned into a whole bunch of not good outcomes.

Where I've seen this at work, what I've noticed is overall a lower quality of management. I would say, and while I would say you do not need... as a manager, I don't need to have the same amount of expertise in the given person's specialization to help me. But there is something about locality to work that can result in better outcomes. So, what I found is like, you know, if someone from the front end guild is on my team. That manager doesn't have as good of a grasp what's going on with that individual and their work as the team lead does.

So, the way to get around this is the team lead, who is probably also a manager in many setups, is having one-on-ones with all of their reports, and also, all of the people on their team. That just, I think, overstretches the manager's ability to actually do quality management. So, I'd much prefer a setup where teams are aligned to their managers.

And the benefit of the Spotify model in theory is that you have a consistent manager over time. I don't think that benefit out weighs the locality to work, and the quality of management that you get while you're reporting to a given manager in a more traditional setup.

Let me see if I can articulate the trade offs as you kind of laid it out. Make sure I understand. So, in the Spotify model, I'm trading off a consistent manager that understands my domain, and my team lead might change. In the more traditional model, or you know, some riff on the traditional model, I might have a manager who is not an expert in my domain, but at least they're a manager that's close to seeing the work that I'm doing day to day. Is that the trade off?

You prefer a manager that really understands the day to day? You think that generally leads to better outcomes than doubling the one-on-ones - that sounds horrible... I love one on ones. They're great, but… there are diminishing returns.

Totally, totally. Yes, I do. But if we met also, I think if you're being evaluated on your work output, right, as an employee; you want someone who is close to your work output... to have that say.

That makes sense. So, in a world where we have more cross-functional teams, we have fewer detailed written specs, and we have more narrative arcs, and contextualized problem statements. How does accountability work in this world?

Yeah, I think it depends on what you mean by accountability. Often times I think we're talking about accountability as a bludgent on folks. It's more about... leaders not getting what they want and, trying to find a way to prove that their engineers are at fault. So, I really believe that you can get a very long ways by aligning people with a vision, and mission, and strategy. And talking about the motivations for what they're doing, and why it's important to the business, right?

So, if my engineers don't understand why their working is urgent, if I can't explain why their work is urgent, then I'm going to be in trouble, right? That's on me and not my engineers. So, usually when we get into a situation where someone is failing to deliver there's a system at play. There's a piece of that system that may or may not be on those given engineers, but by and large, as a leader I'm in charge of that system. So, usually it's lack of goal clarity that I find. Or, the goal... rapidly changing goals, or just some flavor of uncertainty and lack of clarity that's being put out there. Where there is not enough credibility for the engineers perspective to know that if they really sort of went all in on this project that they've been assigned that it'll actually see the light of day, and/or have a lasting impact.

So, that makes perfect sense. I love the first path should be "was l clear", and maybe the second path should also be "was I clear", and maybe the third path also be "was I clear". After we get down that level, what are some signals that we can kind of help us think through the corner cases? What are some signs that actually this is a problem with a person's fit for a specific task? Not a problem with that person. Problem with the job they have, and what needs to be done?

If you have done the work of creating the narrative about why the work is important, why it's pertinent to the business, and at the end of the day, there's a disagreement about that. Then, you have that conversation of can we disagree and [inaudible 00:21:10], right? This is something that we... you know, hopefully is written into your career ladder, it's a point of performance. Like how do we show support for things even, you know, once a decision has been ratified.

And if that still doesn't happen, then maybe it is time you have those difficult conversations, right? It's really... difficult conversations are much easier to have once it's made clear what the expectations are, and the motivations are, right? You can't walk into a conversation and say, "Hey, I think you're not doing your job", when I haven't properly described what the job is that needs to get done and why we're doing it, right?

But if I've given you every single piece of data that I have that shows why I believe this project is important and, we still disagree; then yeah. That's going to be a... that's a conversation that we can talk about in terms of you know, maybe this isn't the right place for an engineer.

And given that estimating is really hard - so, let's say that... I know this is tough because it's abstract... maybe we can get new role play, get more concrete if you prefer. So, let's say that we agree on the goals and urgency, and given that estimating is really hard. And I'm kind of like team "no estimates". What are some signs that things aren't happening at the rate that they need to happen for the team to be successful from an individual's perspective?

Oh, that is a hard one. I'm with you, I'm with team "no estimates".

Go team!

Yeah. It is like, where do you want to put your effort? You put your effort in those directions. Then, it's an OODA, right? It's observe, orient, decide and then act, right? So, I view much more as where do I want to place my bets. Then, you roll the dice. It may pan out, it may not pan out. But, a lot of that is going to be in hindsight and you learned moving forward.

There are occasions... I mean, I think there are businesses where deadlines do matter, right? In terms of, I worked for Yahoo Sports for four years. Those specific deadlines, they're not going to delay the season for you because you didn't get your work ready in time. That's a different kind of management. That is a work by attrition. You shoot for the stars, and then you have outs. You have your escape routes along the way so that you can ship something in time.

But in general... going back to the question of how do we know things are shipping at the right pace? I think that's a wrong way to thing about it. You will ship at a pace, and you should use that pace to understand your capacity. There are things you can do in the long run to maybe affect that if you want a faster pace, right? That's a blend between how do we develop this capability and invest in our engineers to achieve that?

But also understanding [that] you've got to know the signal from the noise, right? Like if I have this rush project that everyone really believes in, and we go into crunch time, we shouldn't be expecting that crunch time output to be our new normal. We are going to regress back to our mean... The question is how do you affect the mean or the long term?

I like that framing. You're going to ship at a rate, how can we move that rate up? Asking whether it's the wrong rate or the right rate, it's a very hard question in a no estimates world. Even in an estimates world, which you know, there are reasons to do estimates.

So, I'd like to go back to our potato world. We've got this indimensional space, and we've got a person. Let's talk about a person's team skills, like catalytic skills, soft skills, those sort of things... How do you assess those skills? Maybe an interview, or maybe a career ladder sense.

So, I'm a big believer in building an interview process that's around your values. So, if you have a strong value around collaboration, like I want to know sort of how well this person collaborates, right? Or some effect there of. I think a lot of those things, there's a lot of research about the effectiveness of behavioral interview questions. I think interesting about this is, for me... if I need to find something around a value, like it takes me just a modicum thought to think of what are the type of questions that I would ask to suss this out?

So if we're about collaboration, let's talk about what's a positive team experience that you've had? What made that positive? How do I get as much information out of this candidate as possible? How did you contribute to this positive situation? What were the things that you think led to this being the case? So... we'll talk about that. We'll talk about a bad team experience. Why was it bad for you? Were you in a position to make it better? If you were, what did you try to do? Those types of things.

And you actually have really deep and thoughtful, insightful conversations with people around those things. If we want to talk about integrity, right? Let's talk about what are some of the values that you hold dear? What are some of your philosophies? When have you had to do things that went against those values, and philosophies? How did you handle it? Those types of things. And you know... asking those questions but there are no wrong or right answers. It's just an exploration. It's just about being curious, and getting folks to open up.

If you can have those types of conversations, I think it serves two purposes. (1) I think the candidate has a great experience. They don't feel like they're being grilled. They feel like you are there to listen and process, and it's a good healthy back and forth. (2) You just get a wealth of information from that candidate. And with that, that can help you inform your decisions.

I really liked the way that this person sort of had a rough go, and sort of recommitted to the team and tried to improve themselves. Or I really liked how this person identified that they were way beyond way their depth, and how they sort of identified it and was able to work through it.

Would those type of heuristics go in a rubric for you? So... someone says, "I was way over my head and someone helped me." You would put a rubric that says identified that they were having a problem? How do you kind of operationalize that path from had this conversation, I got some information, and now I need to make a decision from this information?

So, I think about for the collaboration piece, what are the models of collaboration that we have currently in our work system? Did this person describe a collaboration model that was interesting to me that I think would be a good addition to our repertoire, right? Did this person feel like they were sort of very much married to a collaboration model that I don't think is successful here? That's another interesting thing.

Did this person demonstrate an ability to adapt to a situation, is another thing that I might evaluate in that situation, right? How does this person repair misunderstandings? You know, going back to the diversity and inclusion bit, one of the things that I find working in an inclusive workspace is the ability to repair misunderstandings is much, much greater than in places that don't have that diversity and inclusion; where two people can have a different perspective and it ends up in open questions and not open arguments.

If you're used to agreeing all the time because people are like you, you probably don't work that muscle.

Right, right. Oh, that's curious, I didn't see that. Tell me a little bit more about this, versus this means X? No, you're wrong. You're a terrible person and I'll prove it by whatever means necessary.

See this proof on the whiteboard of why you are... not the most conducive to good decision making. My guest today has been Jason Wong. Jason, thanks for being on Scaling Software Teams.

Thanks for having me.

Thanks again to Jason for sharing his experience with us. Here are a few takeaways I have from our chat.

Number one, focus less on diversity and inclusion, and more on belonging. First some definitions. Diversity is being invited to the party. Inclusion is being asked to dance. And belonging is actually being part of the planning committee; the folks that made the party happen. One of the ways we can create belonging is by protecting our teammates from stereotypes. This is really common human behavior. We should look for feedback that goes to our underrepresented colleagues, that matches stereotypes. That's the feedback that's most likely to not actually be valid, and instead be kind of lazy human thinking. And we can actually detect that, and then talk to our colleagues about providing better feedback.

Number two, performance is a function of context and expectations. The Pygmalion Effect is a famous study in psychology where students were randomly selected but, teachers were told that those students had been kind of magically identified to have great potential. As a result, later those students had done better. So, that expectation became reality. Just want to make a note that this specific study is subject to the replication crisis. There's some doubts about the IQ impact, but the general impact of expectations mattering holds up.

Another great example is stock pickers. Top stock pickers were not transferred to be the top stock pickers in other context. Now how this works in knowledge work, and development is that our context really matters for our success. The type of work we're doing, the support we have. Do you have a designer? Do you have a product manager? What's your Dev-Op system? So, whenever we plop someone into a new context it's important that we have expectations that we're going to support them, and we don't just look for opportunities to say, "Well, they succeeded in the other place. Why aren't they succeeding here? They must be flawed."

How can we operationalize that as hiring managers and leaders? When a new teammate starts it's important that we create confidence, we create support. And we ask about the context where they've been most successful. That's a simple question you can ask on day one. What can I do to help you be successful? What types of work have you been most successful on in the past? What sort of feedback do you like? What type of time blocks do you need? Asking those questions gives us the information we need to provide the appropriate context and expectations.

Number three, map your knowledge potato before hiring. We can visualize our skills, abilities, capabilities, [and] predilections as a potato in multi dimensional space. We're not a line. We're not a square. There are so many dimensions, and before we go to hire, if we want to hire well, we need to map the potato that's missing on our team. We need to explore the boundaries in communication, tech specialization, design ability, documentation. What does our team need? What can our team support? And what do I need as a manager to gain confidence in this candidate's ability to fill that potato shaped hole?

Thanks again to Jason for coming on the show. Now, I want to hear from you. Please leave us a review on iTunes, Google Play, or wherever you get your podcast. This will help others find our community. Thanks, and I'll talk to you next week.

Scaling Software Teams is brought to you by my start-up Woven. This conversation was extremely important to me because I care deeply about reducing bias in software hiring. That's why I started my company Woven. Woven is a developer screening platform that reduces bias and noise in software hiring. We empower hiring managers with a detailed assessment of every candidate based on an hour long work simulation. Our clients make decisions about who they spend time with based on ability to do the job, not just a resume. If you want to learn more about how Woven can help you scale your software team check us out WovenTeams.com.

Tim Hickle