Greater Than Code

01:03 - Not Giving Into Peer Pressure

02:31 - Reaching Outside of the Accessibility World (Demystifying Accessibility)

12:37 - The Real Work of Accessibility: Organizational Change

17:52 - Avoiding Dysfunctional Ways of Working

26:46 - Moral Obligations and Social Norms: Top Down

31:20 - Personas: Translating Ideas and Principles Into Action

37:04 - Putting Accessibility Into Action

51:06 - “Disability Dongles” – Liz Jackson

Reflections:

Michele: Finding room for everyone to provide their perspective.

John: The real solutions are infrastructural.

Rein: Accessibility has to be built-in throughout the process of building and designing software.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

REIN: Hello and welcome to Episode 257 of Greater Than Code. I'm your co-host, Rein Henrichs, and I'm here with my friend, John Sawers.

JOHN: Thank you, Rein, and I'm here with our guest, Michele A. Williams.

She's the owner of M.A.W. Consulting (Making Accessibility Work). Her 16 years of experience include influencing top tech companies as a Senior User Experience Researcher and Accessibility Consultant, and obtaining a PhD in Human-Centered Computing focused on accessibility. A W3C-WAI Invited Expert, international speaker, published academic author, and patented inventor, she is passionate about educating and advising on technology that does not exclude disabled users.

Welcome to the show, Michele.

MICHELE: Thank you so much, John and Rein. Thanks for having me.

JOHN: You are very welcome and we'll start the show as we always do by asking our standard question, which is what is your superpower and how did you acquire it?

MICHELE: I don't think I have the most creative answer to this. [laughs] I kind of hate those, “Oh, tell us something fun about yourself.” But the thing I thought about that came to mind was my ability to not give into peer pressure. [chuckles] And some ways that manifests for instance, I have a technology background and yet I'm almost the least technical person like I was probably one of the last people to get a smartphone. I love my flip phone and you couldn't take it from me.

So this idea that everyone's doing this social media, all of that, I just joined Twitter last year. So I do things dagnabbit; when I need it, not necessarily just because there's groundswell. So I would say that's pretty good superpower.

JOHN: All right. So you gave some examples there in your personal life with technology and social media. I assume that that's also a fairly powerful capability in a business context as well.

MICHELE: I think so. Particularly when you're advocating for say, disabled people who aren't necessarily always advocated for, it definitely helps to have a more strong will and the ability to take a stance that turns others rather than consistently feeling like you're being turned around about what others want you to do. So I agree with that, thanks.

JOHN: [chuckles] Excellent. And so it looks like you've been involved in the accessibility world on a number of different angles and capabilities and so, what have you found to be the most impactful of those?

MICHELE: I tend to want to reach people who are outside of the accessibility world. Unfortunately, I think sometimes accessibility people can tend to talk to other accessibility people a little bit too much. I tend to like to recognize that it is something that everyone in the world should know a little something about. It is an expertise, but there are some ways that everyone can do it. I just recently wrote an article for A11Y Project called Everyday Accessibility. That's when you're making a Word document, for instance, using the Ribbon, using headings, and buttons, or bulleted lists.

So I tend to want to bring everyone on board, and demystify accessibility and make it more attainable and easier to grasp and that feels so much like this expert field that takes years to break it down to those tangible pieces that still make a big difference.

REIN: One of the things that I hear a lot when abled people are advocating for accessibility is, “Sure, this helps disabled people, but you should care about it because it helps abled people, too.” How do you feel about that?

MICHELE: So that's a conversation that's been coming up a lot, too and I have a particular colleague that sent me their response, for instance and it's a stance that I don't particularly align with because the problem with that stance is you end up keeping the status quo. So there are real consequences to being in a society that does not value disability and you, as someone who doesn't have a disability, do not feel those effects. So until we are a more equitable society, we do have to call out the characteristics that make someone have negative effects.

So the reality is yes, there are things like situational impairments, which is when the situation you're in mirrors the impact of a disability such as walking and texting—you're not seeing out of your periphery—or there's temporary disabilities, like you've broken your arm, and then there's just the natural process of aging. All of that is true and you can also figure designing for your future self for that last part. But again, I think that we have to be very mindful that right now we need to overemphasize and think about disability until it is our normal way of thinking.

REIN: It also seems like it's conceding the ground that doing what's right for disabled people is enough of a justification.

MICHELE: Explain that a little bit more, what you mean by that.

REIN: So when you say it helps disabled people, but it also helps abled people, it seems to me like you're saying it's not enough for me to just say that this helps disabled people. I have to give you another reason.

MICHELE: Absolutely, absolutely, and that ties back into ableism and the invisibility of disability and the devaluing of disability. Like you said, it's like a disabled person is not enough. It has to also include absolutely right with that way of thinking and that's another reason not to go that route of segmenting it in that way.

JOHN: I think this ties into something that you had mentioned earlier that I find really interesting, this idea that able people are doing something for disabled people.

MICHELE: Yes, and that's the big thing. When you say like, “What's been on your mind lately?” That's the one that comes to mind and it comes to mind for a couple of different reasons. None of them new, none of them – I did not discover any of this; people have been saying this for decades upon decades.

But for me, my personal experience, I will give a talk, an accessibility talk, I might explain something about say, screen readers, or some other technology, or a particular disability and then the response is, “Well, it should work this way,” or “We should do this.” There's a lot of solutioning around what I've just presented without any context of ever having met say, a disabled person, or particularly a person in the disability community that has been talked about and that comes, I think from this idea, a couple of things.

One, again, this idea of a power structure where, “Well, I'm doing this for you, disabled person.” Not understanding the empowerment that the disabled person has, or this misunderstanding and again, invisibility of disability in spaces like tech innovation and not understanding, okay, that touch screen you're using, that text-to-speech you love, those captions that you use at the bar; all of these things [chuckles] came from disability. We erased the innovation that came from someone designing for themselves and designing for their ability and it's assisted technology and therefore, it's an add-on when it's for disabled folks, but it's innovation when it's for people who don't have disabilities.

I think we need to have a lot more discussion about this, particularly in spaces like user experience, where we're supposed to be all inclusive and all about the user. There's some ways that we really are reinforcing this mindset and this power structure, for sure.

JOHN: So I want to check my understanding of what you're saying, just to make sure. Are you saying that when you present a problem, accessibility problem, the abled people, the other UX designers, the other people who want to be helpful jump in with, “Oh, we can do this, we can do that, or that” rather than saying, “Well, let's go talk to some disabled people and find out what they need and let that guide how we solve this problem rather than us just being like, ‘Oh, it would be great if dah, dah, dah, dah, dah.’”

MICHELE: So to two stages to that. For the first one yes, that's the first thing that happens. In the assistive technology, broad accessibility world, this manifests in some very familiar ways. The first is the blind navigation. Every year, some engineer thinks they've solved blind navigation, pedestrian navigation. Meaning they’ve created a belt with vibrations on the left and right with an Arduino, or something and they go, “You don't need a cane anymore because it's going to vibrate left when you need to turn left and right when you need to turn right, and you can walk like a sighted person,” or some variation of that—robot guide dogs, smart cane, something like that, or the sign language gloves, or the stair climbing wheelchair. There's these sort of assistive technologies that always come out with very little context around whether it's actually happening, whether it's actually needed.

But then there's something John, about what you said, too about let's see what people need and we'll build it. We have to be careful even with that, too because that assumes that I can't build for myself and that's not true either. [chuckles] Disabled folks are the most innovative people because the world is not accessible.

There is a such thing as a specialty. Like I have an accessibility specialty, I have a design specialty, but I think we often think that’s someone without a disability. No, a disabled person can also have these specialties, or they can be someone who has the idea of what they need and you're partnering with them with your specialty in say, design to create those solutions. So again, I think we have to be very careful about our wording and our viewpoints of what's actually happening.

REIN: There's a framework that I've been using for this that actually comes from aviation safety and there's a European aviation safety magazine where Cormac Russell published an op-ed called Four Modes of Change: To, For, With, By. The idea is that change to is the mode where change has done to us without us. So this is a sort of authoritarian top-down thing. We’ve got no say in the matter. It's not even necessarily for our benefit. Then change for is a benevolent top-down approach. “I'm trying to help you, but I'm the one who decides what to change.” Change with is a participatory co-creating the change. And then change by is change done by us for us where if I'm, for example, a manager, my role would be find out what support you need so you can make the changes you want to make.

MICHELE: Absolutely. Perfect. Thank you. I knew there was some reference. This appears in disability justice spaces, in any kind of space where you're talking about inclusion, we know that sometimes inclusion can be code for do things the way that the current power structure does it. Do things the way that the current people in charge of comfortable and assimilate rather than no, we're actually going to allow you to be your authentic self and come into these spaces.

Part of the reason this has also been on my mind is because I fit into some of these other spaces as a woman and as a Black person. I think that sometimes my cohorts think well, because we have experienced some of that in our lives, we are immune to them giving that out to others.

So as a Black person, a woman, even someone with intersectionality, I can't possibly do that to do was done to me to someone else. But we don't realize how much ableism is steeped into our society, such that it is very easy to do that with disability and not even realize it and not even realize you have the mentality that someone is inferior to you, incapable, and particularly when the disability has to do with neurological, or anything that we really don't understand. But even still, even that kind of categorization can go away because the idea is that any sort of disability triggers usually some sort of ableist response and these things can happen even if you've experienced it yourself.

JOHN: So like so many of the other things we discussed on this podcast, it sounds like the real work of accessibility is organizational change. It's getting the power structures to change to allow these things to come into being rather than forcing them in there, or trying to – like you were saying, not forcing the change on the disabled people to fit in.

MICHELE: I've been thinking about the roots of this, for sure. And thank you for that. Unfortunately, capitalism drives a lot of this and again, if we're talking specifically more to tech worlds and say, including accessibility into your tech, part of that is just because the buy-in sometimes comes from the internal stakeholders, not the end customer. Again, if you're not mindful, not careful, and don't have leadership that are careful.

So the dirty little secret is for instance internally yes, you may be making education software for students, but you're really marketing to the teachers who are going to buy it, and you're then even more so really marketing to whoever the management structure is internally who's going to approve it to even be on the market. So you get further and further away from actually helping a student because you have all these other checks that it needs to impress, or you need to make the case for similar to what we were saying earlier, you have to make the case for disability. For instance, you have to say, “Well, blind people to do this.” You get this pushback of, “Well, blind people don't do that so we don't have to worry about it and you keep moving on.”

So there is a shift that is hard, but I do think it goes back to what I was saying earlier about taking a stance. I think that people do need to individually start to take the stance that that may be how we do things now, or how it may even need to be done. But we do want to be careful buying into that completely because it's going to perpetuate the same. We know that that power dynamic internally of who the stakeholders are, again, also sometimes doesn't reflect the diversity of who we are designing for.

We're going to keep getting the same result if we're not super mindful and super careful to take the stance that we are going to care about the diversity of the end users, the people that ultimately will have their hands on what we're making and celebrate that oftentimes those best solutions, again, come from the community who are doing the work.

So celebrating the innovation that comes from being tied back to those end users rather than thinking the solution has to come from within. So changing that mindset around this difficult, but it takes taking a stand and recognizing it, too.

JOHN: So it's trying to change my thinking around to the by style change around accessibility and my context is on the team of web developers who develop apps that are eventually used by some disabled people. So I'm trying to think about obviously, we need buy-in from the power structures as a company and to spend time on the work, but deciding what work gets done needs to be – that's where the inclusion comes in and I'm curious about what the steps are there that helped me get to that point where those people are included

MICHELE: So here’s a few ways that that comes about. One of it could just be, okay, this is the feature we're doing and we're going to make sure that this feature that we're doing—however that came about—is assessable. That can come from anything from how you're going to code, like making the decision to use standardized elements that come with accessibility built-in, or whatever knowledge building you can do internally to just bake it into how you are creating that feature.

Then there is what is the feature and making sure that that, if nothing else, is as inclusive as possible, or at least not exclusionary. You're not making a feature that will exclude people. Again, that comes from an understanding of who is the audience and making sure everyone understands that. No one, I don't think has fully solved for how to make accessibility the thing that everyone knows does – it's difficult. It takes time. It takes training. It takes science from top down as well as then knowledge from the bottom up. It's a journey.

But I think that there are places where decisions are made, that you know you're going one way, or the other, whether it's, I'm using a div, or a button, [chuckles] whether it's we're going to wait to put captions, or we're going to go ahead and build in time to do that, whether it's, again, we're going to put in this very visual feature, or we're going to take a little bit more time to understand how to have an alternative to that feature. So there's lots of places where you can be very intentional, that you are going to take the steps to learn about accessibility from your point of view and then incorporate it.

REIN: So let's say that your VP of engineering mandates that every project has to meet a certain accessibility score, or something like that, but you don't train the developers. So you were saying top down and bottom up have to come together. I have seen things like that lead to some pretty dysfunctional ways of working.

MICHELE: I can see that [laughs] and I think part of that comes from a misunderstanding that accessibility is not just something you say we're going to do. Like, it's not like we didn't do it because we just simply forgot, or we didn't do it just for reasons that can then you can flip a switch and turn it on. People aren't doing it because they weren't taught it, they aren't fully aware of the diversity of it, they aren't aware of what's required, and then leadership isn't aware. Therefore, that steps have to be taken.

So there's a lot of rally around let's be inclusive, let's be assessable, but then there's less so when you learn oh, that means we have to maybe take half of the time to train and disrupt our workflow, or we have to do our workflow differently, or we have to go back to the code we’ve already written and been using for years and fix it. Those are some real decisions and those are some real consequences sometimes to that, too when you're a business that is expected to constantly move forward, but they are decisions that have to be made in order to actually put it in place, not just say you are for it.

REIN: Todd Conklin has a book, The 5 Principles of Human Performance, and there are two that I think are especially relevant here. One is that context drives behavior. So if you want to know why someone is behaving the way they do, the thing to look at is the context that they're operating in, and the other is that how leaders respond to matters.

When I think about this, I think if you have a design systems team, is that design system built to be accessible from first principles? Is the easy thing to do grab a component that's already designed to be accessible, or is the easy thing to do is throw a div on the page?

MICHELE: Yeah, and there are, I think that the number one takeaway is none of it is easy because all of it is late. So there are initiatives like teachaccess.org; we really need to be embedding it in how we even learn the things that we learned, because then it does feel like we're almost disrupting industry to do this. When in reality, we just learned it wrong. [chuckles] We learn to cheat and to make it look and feel the way I want it to look rather than learning that there was a reason there's this thing called a button versus this thing called a div.

Now, recognizing, too, though that standards come after innovation. So you can't standardize something that hasn't really even been explored, or even invented yet. So we understand that as you want technology to advance, it's more difficult to then say, “Okay, there's a standard for this and that will guarantee us accessibility.” So for instance, using native HTML elements isn't all, or when we look at mobile, native mobile elements is more difficult to do. This is still a new space, a growing space and so, sometimes we don't often know what that looks like.

But that then requires again, that awareness piece of what disability looks like and this is where they're trying to catch augmented reality and virtual reality with XR Access and accessibility initiatives. Because if you're at least aware of the diversity of disability, you can catch it early enough so that when the standards come out again, we're making it less hard.

Someone on a panel I was on last week, talked about like tech debt and this idea of well, it can be overwhelming. Well, if you have less things you need to maintain, it's less overwhelming and that comes from using standards and being aware of standards. You lessen your tech debt; that becomes part of the overall responsibility of standards bodies, for instance. So there are some again, tangible steps that I think just need more awareness and talking about over and over again until we get it right, that can be put in place, should be put in place. Hopefully, it will be put in place to make this less daunting over time.

REIN: Yeah, and then on the how leaders respond thing. If someone builds something that's not accessible to you, do you punish them to just drive that behavior underground, or do you say, “Why weren't they able to do it? Do they not have the right expertise? Were they under too much time pressure?” How can I make the context better so that people are more likely to do the behaviors that we're trying to lead them towards?

MICHELE: Yeah. Thinking a lot about that, too. So I tend to have two ways. I guess, it's sort of the carrot stick kind of thing, or maybe some other dynamic like that, but we know some people are going to get the altruistic side. Again, awareness. They just weren't thinking about disability. It's not something that's in their life. It's not something that was exposed to them. Once someone is exposed and understands a little bit of the work that needs to be done, they're bought in and they go for it.

There are other folks that just are ablest. They just will not care. If it has not affected them personally in their lives, they are going to look – maybe like you said, maybe their motivations are something like money, even though they don't realize they're excluding more consumers. Whatever those things are, they're just not going to buy in. That's when unfortunately things like the threat of lawsuits, or bad publicity has to be the way that you get those folks to turn around, or again, you just do it. [chuckles]

So that's when maybe the folks on the ground can just do it regardless and the one thing, I think about is this video that went around with this little baby and there was a parent and a teacher aide. I presume the baby was supposed to be doing their sound it out cards, flashcards, but didn't feel like doing it. The little baby sitting on the floor back turned, the mom and the teachers, they did it. They did the sound out cards. The baby's looking back still playing, but keeps looking back and eventually, the baby goes, “Wait a minute, that's my game,” and next thing you know, they're playing the game.

So there is something also, too to like you said, maybe it's just a peer pressure thing. No one else seems to be doing accessibility so why do we have to be the ones to do it? But if the cool kids start doing it, if the company start exposing that they are doing it, if there's enough groundswell, people will just get on board with the thing that everyone is doing, too.

So I think maybe there are three ways now—maybe I've added a third in my mind. There are ways – as a user experience person, I say user experience the person that you're dealing with. Like you said, get in their head, what are they thinking? What do you think they would want? But ultimately, understand that it isn't always going to be because it's the right thing and the faster you learn that, the more you might be able to actually get some results, too.

JOHN: Yeah. I like what you said there, Rein about set up the system so that the right thing is easy and I think obviously, there's a lot of work to get to that point where you have the whole system built around that. But once you can get there, that's great because then, like you were saying, Michele, there's so much less effort involved in getting the thing to happen because that's just how everyone does it and you're just pulling the components are, or copy pasting from the other parts of the code that are already accessible so that it that stuff is already built into the process. And then it doesn't have to be quite so much of an uphill. Like even just uphill thinking process where you have to think differently than you used to in order to get the thing done in an accessible manner.

MICHELE: Yeah. Again, unfortunately it's not embedded within us to do this, but maybe the next generation will, maybe the next couple of generations If we keep talking about it and we take the effort to start to shift ourselves, maybe it will be the thing that people can't even remember when they didn't do it. I do feel like we're in a cool moment right now where that might be possible. I'm hearing it more and more. I didn't learn it in school when I was doing computer science and software engineering, but I know some students now that are coming out that are. So I'm kind of hopeful, but the conversations really need to be said aloud and often in order for it to happen, for sure.

REIN: You mentioned the larger structural problem here, which is that designing accessible software is a moral obligation and we work in an economic system that's not optimized around moral obligations. Let's put it that way.

MICHELE: Yeah. [laughs] That will dollar. [laughs] I think again, there's that school, are we changing that, or we're going to work within it. I think you can do both. Some people should – we should really be tackling both, any kind of inclusion efforts, same thing. Do you do it from within, or outside? Do you work within the structure, or do you dismantle it? I think there's benefits to both. I think there's benefit to basically editing what isn't working about what we're currently doing. There's always an improvement and I tend to look at it that way.

It's not so much as it’s down with this and up with that. I think we just need to recognize, as human beings who can evolve and do things different, learn, grow, and get wiser, let's just do that. Let's do what we're doing better and when we recognize that we have a negative effect, let's solution something that is going to work better and just recognize that and do better. It's okay to edit.

So I don't think we have to toss our hands up and say, “Oh, we'll never get there because of how this is.” That was invented, too. All of these things are constructs. At some point, the way we do things wasn’t the way we did things; we did things completely differently. Empires can fall and rise and be redone. So we don't have to stay stagnant, but we can, again, start to make these changes.

REIN: I think that even within a capitalist system, there's still a place for social norms. There's still a place for deciding which behaviors we're going to accept and which behaviors we're not going to accept and what we're going to do about those. I just wouldn't expect that to be the CEO's job. I would expect that to be the entire community of the company.

MICHELE: The entire community with the CEOs. So the two companies that are the pillars, for instance, of accessibility, Microsoft and Apple, you hear their CEOs say, “We do things accessibly.” So it's not necessarily on them to forego stakeholders and stock prices and all of that. Certainly, you can't do too much if you don't have a company, so they have to do what they have to do, but there is still an okay from that and that's part of that top-down. Again, we need training. Is there money in the budget for training? That has to come from management.

So there is still a recognition and it's just always beneficial when everyone is on the same page that this is how we operate; the message then doesn't ever get disconnected. It just shifts to the role of a person and they put it into practice in their own particular way.

REIN: Martha Acosta, who is one of the few original women in safety science, she says that there are four things that leaders can control, or have leverage over—there’s roles, there's processes and practices, there's values, or norms, and there's incentives. So I think this ties in with what you're saying about what the CEO's job could be.

MICHELE: Versus stock prices? Yeah. [laughs] Versus yeah. Which unfortunately is, again, I think it's even upon the CEO to take a stance on what they are going to do with their company and their time. Because certainly, the pressures are coming to them sometimes not necessarily emanating from them.

So I think there is opportunity, this is why there's opportunity for everyone to evaluate what are we doing. Like you said, we can decide what is important, how are we going to go about this? And if enough people start to be even more mindful than they were yesterday, shifts are going to inevitably happen. And people who disregard others, discriminate all of these other negative effects that we've seen will inevitably have less effects because the norm will be these other ways that we're trying to include and get better as a society.

REIN: So one of the things I like to think about when we have guests, or ask guests to think about, is to think about this challenge from the perspective of a few different people. A few different personas. So I'm a manager, I'm a line level manager and the people that report to me are engineers. What can I do? Or I am a mid-level engineer, what can I do? How do we translate these ideas and principles into action?

MICHELE: So what is to understand that there are, for instance, guidelines like there are web accessibility, web content, accessibility guidelines, or author and tool guidelines, because we do need to define what it means. At some point, there needs to be metrics and there needs to be measures that need to be placed to understand, did we do this? One way to do that is to translate those into those various roles. Some of that work has happened and some of it needs to happen.

So there's understanding the tangible actions that can and should happen. But I think also, it's simply a matter of deciding that accessibility and inclusion and particularly in my world, disability is just going to be a part of everything. Every check that you make for whatever your role is. You were talking about different frameworks for different levels. Certainly, that's true. I think that we tend to separate out disability from those kinds of conversations as if it's different. It's not different.

Making decisions for how you're going to manage your employees should be inclusive of disabled employees. The tools that you want them to use, the ways you want them to work, how “productive” you want them to be, how you're going to measure that. All of that should be mindful of the variety of people that you are supporting. Same with I am a developer so that means that I am writing code on behalf of a group of other people and that means I need to know who these people are.

It's funny you say personas because—I know that's not probably what you meant, but in my role, obviously that triggers the user experience personas, which I'm not a fan of. That's all another podcast. [chuckles] But when we're talking about that so in user experience we’re saying, “Oh, we're designing for these people, these target audience per se.” It'll be John who's the manager and he does this on his way to work and then there's Mary. Maybe she's a stay-at-home mom, but uses it this way. Dah, dah, dah, all these other characteristics. And then we'll go so now we need disability personas. No. [chuckles] John can also be quadriplegic. Mary can also have multiple sclerosis.

So again, it goes back to the idea that we have separated out and made invisible disability. Oh, taboo. Even the word oh, it’s taboo. Can't talk about disability.

REIN: Yeah. Like imagine having a separate persona for a woman, or a Black person.

MICHELE: Thank you. We don't do it. We don't do the whites only school and we'll get to the Black people later. We know that intrinsically, but we do it in everything. So same thing particularly when we're talking about inclusion of disability in all of these phases of say, an organization, we go, “And disability.” No, no, no. If we really want to think about it, disability is the equalizer. Anyone can become disabled at any moment at any time, it does not discriminate. It is the one thing that any human being can become at any time and yet we still separate it out as if it's this taboo, or a terrible thing.

Now, again, there are negative outcomes of disability. Not saying that, but we have this tendency to segment it in ways that just absolutely don't make sense and aren't necessary and are detrimental and make it more work, so.

REIN: There's a book called Software Security by McGraw. It's kind of old now, but the premise is still very relevant, which is that to make software secure, you have to build security in at the beginning, and you have to keep constructing and repairing it throughout the software development life cycle. So it starts with design, but it includes, you talked about different touchpoints in the life cycle, where you want to sort of check in on whether you still are as secure as you think you are. So that includes design. It includes code review. It includes testing. I wonder if this sort of an approach works for accessibility, too; we just sort of bake it into the fabric of how you design soft.

MICHELE: It should be how it works. The moniker is shift left. That's absolutely what has to happen to do it well. You have to be thinking about it all the time. Everything that you do. So that's how my mind works now. It took a long time to do that. But now when I'm sending an email and I put a picture in, “Okay, let me put the alternative text.” I'm making a spreadsheet, “Okay, let me do the heading.” Like, I'm always constantly checking myself as I'm doing anything. “Okay, if I'm doing a podcast like this, is there a transcript, or are there captions?”

I'm just constantly doing these checks. That takes time to build up, but it is the way you have to do it to make sure nothing slips through the cracks so that all the hard work that say, the design team, or the dev team did, and then QA comes in and doesn't know how to test it. We're all interdependent so it has to be everyone all the time, all throughout the process in order to get it from end to end to work; the weak link in the chain will break that. So very much how it has to go.

REIN: It also seems like this there are small, actionable things that you could do to move in this direction. So for example, when you do code review, ask some accessibility questions. Maybe build yourself an accessibility checklist. Now I don't like checklists, but that's a whole other podcast, but it's better than not thinking about it.

MICHELE: Yeah. As you're learning something, sometimes the checklist is helpful because you don't yet have it in your own mind and you don't want to forget. Now you don't want to – I'm sure what you're saying is you don't want to tie yourself to the checklist, too.

REIN: Yeah.

MICHELE: But as you're building up knowledge, yes, there are so many just tangible did I do this things that you might as well just keep a sticky at your desk, or however you want to do it and just start doing those things. Again, we don't have to keep talking about it. It doesn't have to be this revelation of inclusive buy-in in order to put captions on your videos. [chuckles] These things, you know.

REIN: Yeah. This also seems like an opportunity for tech leads to do leadership to say, “Hey, so I looked at this and the contrast ratio is a little bit low. Do you think we could punch this up in a code review?”

MICHELE: Yeah. The only thing, though is back to the beginning—being careful about these directives, making sure you understand the directives that you're doing because again, a lot of times, particularly when people are new to accessibility, they overdo it. So they hear a screen reader and they think it needs to read like a novel so they want to add in a summary of the page in the beginning, a summary of this section, and they want to overly describe the alternative text, the image down to the pixels.

There's some give and take there, too. There's some learning you want to do, but you can iterate. You can learn one piece, get comfortable with it. Okay, now that this next piece. Knowledge building it's just what it is, is what it is. So there's absolutely knowledge building that you can do to get more comfortable and we need everyone to do this. There's certain parts that should be specialty, but unfortunately, the specialists are doing what everyone else should be doing the basics and so, we've got to shift that so that the specialists can do the specialty stuff, the harder stuff that may not quite get – [overtalk]

REIN: That's exactly the same problem is having a security person on your team.

MICHELE: Absolutely. So it sounds like you all have a focus on implementation. Like you're implementing and you want to know how best to make – I'm turning it on [inaudible]. [laughs] So you want to know how best to make it work for you, or is that what I'm hearing?

REIN: I guess, I lean towards practice. I want to understand the theory, but then if I can't put that theory into practice, the theory is not very useful to me. If that makes sense.

MICHELE: Absolutely makes sense. My company name is Making Accessibility Work and a lot of what I say is put accessibility into action, because I am very much tied to this idea that you can be absolutely on board with accessibility and not have any clue how to do it. [chuckles] And then the inverse can be true, too. You can absolutely do not care, but because you care about semantic HTML, you're doing more accessibility than the person who cares.

There are these places that people can be in their understanding that neither one is actually, or you think one is helping, but the other actually is. I think people think you have to care. You have to want to Sometimes, you know what, you don't. Sometimes I just need you to fix the color contrast, [laughs] or yes, it's great that you care, but in doing so, you're actually, co-opting a message. You care a little too much and you are actually not letting disabled people speak for themselves because you've now discovered accessibility and now, you're all about it.

So I think we’ve got to meet in the middle, folks. Let's care, let's do, let's demystify, but also understand there are some harder problems to solve, but understand where those are. Putting headings on the page is not the hard problem we need to solve. Just put the headings, making math and science more accessible, particularly when we've made it so visualization heavy. Yeah, let's go over there. Let's tinker with that, folks and that's where we need to be putting all this massive brain power.

We've had Web Content Accessibility Guidelines for 20 years. HTML5, which addressed a lot of semantics for accessibility, has been out a decade. Y'all, hurry up and learn that and let's get that going so we can get over to this harder stuff. Get this brain power over to these more complex issues and newer innovations.

JOHN: Yeah. I think if you're one of those people that cares, like you were saying, a little too much, or perhaps just a lot, you can end up with option lock because you want to solve all the problems and then you're just like, “But what do we do? What are we doing here?” Like, I'll just put the headings in, put the alt texts in, we'll start there. You’ve got to get moving. And that's partly where I'm coming from with some of the questions I'm asking is that process of just getting that boulder rolling a little bit so that it takes a little bit less effort to keep going in the future.

MICHELE: Yeah, and there's no perfect way to do it. I think everyone's looking for okay, well, how do we do it? You're going to spend a year on how and again, miss the year of what and doing it. It is messy because you're hiring people, you've got people working who don't know how to do it; it's going to be disruptive. We didn't come in with this knowledge. I know you didn't hire people to then train them up and send them to school but unfortunately, you’ve got to do that. People need to know what to do differently, what they're doing wrong.

So some of it is going to be experimental, iterative, and messy, but in the end, start giving access. We talk about language even. Do we say disability? Do we say people with? Or do we say disabled people? And do we say differently abled? Even these – okay you know what, the reality is you do all of that and still don't get access. What would be better is if you have a person with a disability at the table to tell you themselves, but you're worried about language and yet can't even hire someone with a disability.

So again, it's getting out of these little zones that we sometimes get in and recognizing the real work that needs to be done and can get done today.

REIN: I think there's a real temptation to fixate on the hard, or interesting problems in the tech world that might be wanting to build this distributed database with five nines of durability. But your API server has a bug where 1% of the requests are an error. So if you don't fix that, your five nines over here are useless.

MICHELE: The flashy thing, yes. [laughs] The shiny thing, we want to gravitate. Oftentimes, there's no glory in what was considered the grunt work, the foundational work. But I think that's where leadership could come in.

I heard someone say years ago, “Appreciate the bunts” in baseball that oh, chicks dig the home run. We love the home run, but sometimes, that bunt wins the game. But that's where a leadership can come in and appreciate laying found a scalable foundation of code that does not add to tech debt, or the diminishing of the bugs that you've kept rolling year after year after year, you close 50 of them. That's where, again, a change in mentality of what we value.

Sometimes again, accessibility is not put at the front because sometimes it's just code changes that aren't visible to users. So users are going to think you spent a year and didn't do anything to your code, or some of them will. But again, I think that's a messaging and that's an appreciation of really trying to do, and that's even appreciating software engineering versus just COVID.

I have a software engineering degree and that's when I realized, “Oh, we're not just supposed to sit down and start hacking away and make sure it runs for the teacher to check it and we're done.” There's an engineering to this, but you have to value that.

But also, I think there needs to be clearer consequences like speaking of engineering. If it’s a building, we know the building can collapse. I don't think sometimes we appreciate what can happen if we don't do that foundational work and I think that's a shift overall and then technology and appreciation of that work.

REIN: And I appreciate what you did there, which was to subtly redirect me back to the context and to how leaders respond. Because if building that five nines database gets you promoted and fixing that bug doesn't, what are people going to do?

MICHELE: Yeah. So what's valued and that's set. Someone sets that. That's made up. You can value whatever you want to value. You can praise whatever you want to praise.

Complete tangent, but that takes me to my high school where they were intentional that the students who performed well were going to be recognized by the principal because oftentimes, it was the misbehaving students that went to the principal's office. So the principal knows all the misbehaving students, but doesn't know any of the students that are doing the actual work that the school is asking of them to do. Not trying to get too much into school systems but again, it's an intention that you will honor the work, the unseen work. We do these in other spaces; the behind-the-scenes work, the unsung heroes. That's an intentional step that you can take as well to celebrate that, too.

REIN: We have an older episode on glue work and how valuable glue work is, but how rarely it's acknowledged, or appreciated, especially by leadership and also, how it has a gender characteristic, for example. It seems to me like it might be easy to put accessibility in the category of glue work rather than in the category of like you were saying, foundational things that make us have a reliable product and a product that works for everyone.

MICHELE: And I don't know if how we've presented technology to consumers plays into that as well. Again, the new flashy wow.

The other day, I just looked down at my keyboard on my computer and I just thought about we just take such advantage of the fact that I'm just sitting here typing on the keyboard. Someone had to decide what the material would be that doesn't scratch my fingertips. Someone had to decide how to make the letters so that they don't rub off, or how they light up in the back.

There's so much detail that goes into almost everything that we use and we just get so dismissive of some of it. “What's next? Eh, that's okay.” So I think, again, it's a human condition. It’s the human condition to appreciate what people are doing for one another in front and behind the scenes and absolutely.

But I think that also ties into, again, ableism, too. We see in assistive technology, or an adjustment because of disability as okay, that thing we can do later. But then when it becomes Alexa, when it becomes the vacuuming robot, when it becomes the new latest and greatest thing, then it's front and center and everyone wants to work on it. But it's the same technology. [chuckles] It's the same reasons that you should do it. It just happens to benefit everyone. It came out of disability, but you didn't want to think about it until you’ve found a benefit for all the “others.” Again, I think that's a human condition we have to correct.

REIN: There's a thing that happens once a month on Twitter, which is someone will post an image of pre-sliced vegetables and they'll say, “What kind of a lazy loser needs pre-sliced vegetables?” And then someone will respond, “Disabled people need pre-sliced vegetables.” And then the response to that will either be blocking them, or saying, “Oh my God, I'm so sorry. I had no idea.” I think that there's maybe that dynamic going on here as well.

MICHELE: Absolutely what I was thinking about, too, like Nike's shoes recently that you don't have to tie. Well, who doesn't want to sit down and tie their shoes? People who can't sit down and tie their shoes, but that was also a marketing issue. They refused to market it for disability. Like where were the disabled people? Where were the people with chronic illness, or chronic pain, or body size that just does not lend itself to bending over and tying your shoes? Why did it have to be marketed in that other way that then took away the messaging that this is a useful piece of equipment?

REIN: Yeah. Like why is this fit model not able to tie their shoes?

MICHELE: Exactly. Rather than take the angle that – again, they're all made up. Someone just happened to decide laces. We could have very easily decided this other way at the beginning. We could have very easily decided Velcro was the way. We just, I don't know, somewhere along the way, came up with laces.

I think people in general have to go through their own journey of recognizing that what they were told was fact, truth, and stance just with someone's made up thing. Even these companies that we've just hold as pillars started in garages. They may have started in garages a 100 years ago, rather than just 50, or 20 years ago. But these things are just built. So we can build them differently. We can say them differently. It's okay. So taking away that stigma that things have to go a certain way and the way that they've been going, or at least perceived to have been going. We have got to start dismantling that.

JOHN: Harking back here, a point earlier about the new shiny is always held up as always better. I read an article recently about prosthetic arms and how everyone's always really interested in building new robotic prosthetic arms. They're the new shiny, they're the cool thing to work on, and people feel good about working on them because they feel like they're helping people who need them. But that in a lot of cases, they're not better than the one that was designed 30 years ago that doesn't do a lot, but has at least a functional hook.

They were following one woman through the article who had gotten one of these new ones, but it actually wasn't any better and she ended up switching back to the old one because she could get it to do the things that got her through the day and – [overtalk]

REIN: Made with titanium.

[laughter]

JOHN: And you can clearly see that probably the people that are designing these probably weren't working with people bringing that feedback into the process enough and it was designed for rather than designed by.

MICHELE: Absolutely. So Liz Jackson coined the phrase “Disability Dongle.” That's another one that comes up. The prosthetic, the exoskeleton, absolutely. The thing that non-disabled people look at and awe and look at what technology is doing, disabled people are over in the corner going, “That ain't going to help us.” [laughs] If you had asked, we would have told you we don't need that.

I think we've also reached a point where we're at the harder stuff and no one's willing to tackle, I don't think always the harder stuff. So for instance, going back to blind navigation, one of the things that makes navigating difficult as a blind person—and I learned this because I talked and worked with like 80 blind people. [laughs]

So one of the conclusions that came to with that infrastructure disables blind navigation, you don't need a smart – a lot of people espouse a smart cane. Well, they had this white cane, but it needs an infrared and it needs buzzers and it needs – okay, you're going to give people carpal tunnel. The battery on that is going to die. It's not going to be reliable. And in the meantime, the thing you could have done is educate people on putting stuff at head level.

So the way that we design our street signs, for instance, we do everything very car minded. We do a lot of things for cars and we forget people also have to walk and so you put obstacles, or you can educate people about trimming your trees, for instance so people aren't running into them, or how they park their cars so that they're not in the way.

Some of it is also just not a technology solution. It may be more an environmental and human education solution, but you can't tell people, who have signed up to work in technology, that they must find a technology solution. So they end up solutioning amongst themselves in ways that actually aren't helpful, but they make themselves, like you said, feel better and they promote within themselves. It's difficult to get people to undo that.

JOHN: Yeah, it strikes me like you were talking about the wheelchairs that can go ramps, the exoskeletons, and there are certainly use cases for those sorts of things. But I think the distinction there is those are a solution to make the disabled people more abled rather than making the world more accessible. Like what they need is lower countertop so that in the wheelchair, they can still cook. That's what they need. Not the ability to walk upstairs, or have like you said, this awe-inspiring exoskeleton that just draws more attention to them and probably doesn't even solve most of the problems.

MICHELE: I'm just going to say amen. [laughs] That is it. That is the thing we need people to get. So you'll hear about the models of disability, too. Sometimes you'll hear about – you should hear about the models of disability and when people extract that and summarize that, they usually pull out two, which is the medical model, which is generally what we've been under, which is the effects of disability and how that affects the person. Therefore, these things need to happen to overcome and this sort of again, hospital, kind of what the body's doing, or what the mind is doing mindset, which is opposite of one that people often quote, which is the social model. The social model says, “No, no society, the world, my environment is disabling me. If you would just give me something more adaptive, more inclusive, I’d be good.”

So a lot of examples of that, I recently read a Kia Brown's book with a book club and you'll have to insert [chuckles] the link. The Pretty One is what it's called. Kia has cerebral palsy and one of the things that was a feat for her was putting her hair in a ponytail and it made you think about scrunchies and the makeup of that. What if we just made the mechanism to have maybe a little bit more to it to grab your hair and put it in the ponytail rather than relying on the fact that you have two hands that you can do that with?

So those are the differences in the mindsets of our views of disability that we need people to shift and even go sometimes again, deeper into what it is you're really doing when it comes to inclusion. Are you really being inclusive, or are you saying, “Hey person, come on to what I believe is the way of life”?

JOHN: So reflections, then.

MICHELE: My reflection, or takeaway would be that my hope is that we can find room for everyone. Everyone who wants to create great tech, everyone who has an idea, everyone who has a contribution. I hope that that doesn't continue to need to filter through say, a non-disabled person, or a certain status of job title. My hope is that we're starting to recognize that there's room for everyone to provide their perspective and it can be valued and it can be included in the ways that we operate at equal opportunity. So that's hopefully, my reflection and my takeaway.

JOHN: All right, I can go next.

I think really actually the point that that's really sitting with me is what I had just said, which dawned on me as I was saying it, as we were talking in the last minute there about how the real solutions are, like you said, infrastructural. They're changing the form of society to make the disabled person able to do what they need to do rather than bringing them up to the level of whatever was currently built, or whatever that – and even there's a weird value judgment in saying, bringing them up to the level. I'm uncomfortable saying it that way.

So just changing the thinking, like you said, the social model is, I think a powerful change and thought process around this, and I'm going to keep turning that one around in my head.

REIN: I think for me, I'm coming back to the idea that just like security, accessibility has to be built in throughout the process of designing and building software. You can't have a part of your software delivery life cycle where that’s the only place where you think about accessibility. You can't just think about it during design, for example, and you can't just have a team of accessibility experts that you go to sometimes when you need help with accessibility. It's really everyone's job and it's everyone's job all the time.

MICHELE: I love it. I'm going to change the world. [laughs]

Special Guest: Dr. Michele A. Williams.

Support Greater Than Code

Greater Than Code Episode #170: The Case for Vanilla JavaScript with Chris Ferdinandi

02:50 - Project Gemini and Text Protocols

07:05 - Overusing Analytics & Tracking Scripts

12:18 - Innovations: Making Accessibility The Default

14:48 - Ad-Tech and Tooling

32:08 - HTMX

46:30 - Frontend Development is Hard

Reflections:

Rein: Vanilla JavaScript + Privacy.

Jacob: The web piqued at LiveJournal. Also, encouraging devs to think about what tool would be best for different jobs.

Sign up for Chris’s newsletter at gomakethings.com!

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

PRE-ROLL: Software is broken, but it can be fixed. Test Double’s superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater.

REIN: Hello and welcome to Episode 256 of Greater Than Code, a nice round number. I’m your co-host, Rein Henrichs, and I’m here with my friend, Jacob Stoebel.

JACOB: Thank you so much! I'm joined with this week's guest, Chris Ferdinandi.

Chris helps people learn vanilla JavaScript. He believes that there is a simpler, more resilient way to make things for the web. His Developer Tips newsletter is read by thousands of developers each day. Learn more at gomakethings.com.

Welcome to the show. Welcome back to the show, I should say. We had you on just before COVID, we were saying before the show started, so it's been quite a while.

CHRIS: Yeah, yeah. Thanks for having me back. It's been kind of a wild 18 months.

Last time I was on the show, I think we spent a lot of time talking about how modern development best practices might be ruining the web and this time, I was hoping we might have a little bit of chat about how that's still kind of the case, but there's also a whole ton of new things that have happened in the last 18 months that maybe swinging the pendulum back in the other direction, creating a web that's faster, little bit more resilient, and works better for everybody.

REIN: That sounds great. But first, has your superpower changed? Do you still have the same superpower?

CHRIS: I don't remember exactly what I said last time, but assuming it's derailing conversations, then the answer is absolutely yes. [laughs] That has always been and always will be my superpower. I am great at tangents.

REIN: Well, this podcast is just a series of tangents stitched together, so.

CHRIS: Excellent. Always makes for a fun conversation.

JACOB: Yeah. Very true.

REIN: Have you heard about this new internet protocol, Gemini?

CHRIS: No, I have not.

REIN: So it's like somewhere between Gopher and HTTP and so, it's a plain text protocol with no mark, no markup, no XML, no HTML and you can have links, but they have to be on a separate line. So you basically are sharing these plain text documents and there's no JavaScript, there's no CSS and people are seeing it as a revitalization of what the web used to be about. No click tracking. No injected advertisements.

CHRIS: Yeah. This is weird. So there's a few years ago where I've been like, “Yes, that's what the web needs.” I feel like I'm a little bit more pragmatic now as I have less hair and more white in the beard. Like that seems really cool in some ways and a huge step back in others. I have very mixed feelings about that as a gut reaction; knowing nothing else about it other than what you just told me.

REIN: What do you think is the happy medium between where we are now and 1990’s text protocols?

CHRIS: Yeah. So in some ways, I feel like the web maybe peaked with LiveJournal, or maybe Myspace. Myspace made it really easy to hack on the web and that was really cool. But the text-only web, I don't necessarily think I'd like to go back to.

I think I'm actually not even really opposed to commercialization on the web in large part because I'm only able to do what I can do professionally because of that. But I would love something that really curtails all the spyware for profit stuff over tracking. I have none of that on any of my websites. I removed all of my analytics, all of my – I don't even track opens on my newsletter and so, I really like the interactive and immersive nature of the web. I don't mind the commerce side of the web. I really hate the whole Big Brother-esque “we’re always watching you” nature of the web. I think that's really awkward and creepy.

Also, I feel like sometimes we try to run before we can walk on the web and so, we end up throwing a boatload of JavaScript at the frontend to make up for limitations in the platform and we have a tendency to create experiences that are really slow, brittle, and super prone to breaking. I think about how the web has gotten, or the internet as a whole has gotten four to five times faster in the last decade, but the average webpage still loads at about the same speed as it did a decade ago.

[chuckles] The original Space Jam website loaded in about the same amount of time that the new Space Jam website loaded, even though the internet [chuckles] has gotten so much faster in that time and a large part of that has to do with the way we build and the tooling that we use.

JACOB: Just consuming that extra capacity that we get through faster connections, et cetera. More people.

CHRIS: Yeah, for every extra megabit of internet speed that we get, we throw a bunch more JavaScript on the frontend and we have a tendency—it's really weird for me to, as someone who teaches JavaScript for a living, tell people to use less JavaScript. But the web keeps moving to a more JavaScript driven future and JavaScript is the most fragile and bad for performance part of the frontend stack. I feel like in the last maybe 5 years, or so, we saw the pendulum swing really far in the JavaScript end of things.

I still think the phrase, “Always bet on JavaScript” is a good one. I don't think JavaScript is going anywhere. I don't, in abstract, hate it. The interactivity that it brings is good. I think the challenge is around how we lean on it heavily for things that it's not necessarily the best tool for the job for. I'm starting to see a new slate of tools that take advantage of some of the things that's great at in a way that doesn't punish the users for those decisions so that's pretty cool.

We can dig into that if you both want to. There's a lot of new stuff in the works that I think has the ability to maybe fix some of the challenges that we've been facing up to this point.

REIN: What would you say are some of the low-hanging fruit in terms of implementations, design that people could take that would just make their app a little bit better, play a little bit more nicely, be a little less extractive in terms of tracking everything the user does?

CHRIS: Yeah. So one of the weirdest things that I've just encountered on the web, there's a certain subset—a lot of times it's e-commerce vendors, sometimes it's SAAS—but they're loading eight different tracking and analytics scripts on a single page through all sorts of different vendors. So they'll load Google Analytics, Salesforce, and three, or four other vendors that I'll do some version of the same thing—racking what you click on and where you go next. The impression I've gotten from talking to folks is that this is a byproduct of having a bunch of different internal departments that all want access to data and no one wanting to be like, “This is the tool we're using,” [chuckles] and so, they all just chuck it in there.

So that's probably a really big offender there and there's a couple things that you can do about that. First is I feel like a lot of developers and a lot of designers have this; I don't know how to describe it. I don't want to – I'm trying to think of the right phrase here, but it's almost like your job is to an advocate for the user. So just because your manager, or executive is saying, “We need this” doesn't necessarily mean your job is to just be like, “Okay, let me throw that in there.” I liken it to if you were building a house and a customer told you they wanted you to install a hair dryer in the bathtub. You could do that for them because they ask, but it's a really bad idea and maybe it's your professional responsibility to tell them that.

REIN: Yeah. That is the thing that distinguishes a profession is that you have ethical obligations to uphold,

CHRIS: And this is where I think you get into the pro and con of the web being an industry that you can get into without professional certifications and trainings. It's like anybody can do it, but there's also not necessarily that same level of there's no certification board that's like, “You're going to lose your certification if you do these things that are harmful.”

For most of us, for a lot of what we do, the side effect of having eight tracking scripts on a website is not life-threatening, but depending on the type of site that you offer and the services that you provide, it can be. Like I think a lot of people get taken a little aback by that, but I've heard multiple stories in the last few years about utility companies—electricity, gas, whatever—where utilities get knocked out in a really bad storm. So people are relying on their smartphones on 3G and they live in areas where connectivity is not particularly great and their Wi-Fi's down because their power is out and trying to connect to the electric company website to be able to file a claim like, “My electricity's out,” or even just find the contact number to call them, the site just keeps crashing, reloading, and they can't open it.

Not having access to your utility company because somebody was irresponsible with how they built the website really sucks. And depending on what the weather is like, like I live in a very cold climate up in the US in the Northeast and if the temperatures drop below freezing and there's a down tree blocking your ability to get in and out of the area and you don't have electricity, or heat, that can be a really serious thing.

I think a lot of times we just think about like, “I'm just building websites.” But it can be so much more than that depending on the industry you work in and the type of work that you do.

So the whole there's no equivalent of you're going to get disbarred if you do these bad things, there just isn't that for a profession, which can be a good thing, but is also – [crosstalk]

REIN: There's no equivalent of the city code that's 2,000 pages long, but also means that you can't build a bathroom that electrocutes people and you can't put asbestos in the walls. The counterargument is that regulations are onerous and they stifle innovation, but – [crosstalk]

CHRIS: And they can.

REIN: Do you want innovation in less safe ways to build houses? Like, is that what we're looking for?

CHRIS: Right. Yeah. I had a similar argument once with someone about accessibility on the web and how it shouldn't be legally required for sites to build themselves accessibly because it stifles innovation for one person shops who are just trying to throw something up quickly. I don't know, at some point it just boils down to a moral argument and it's really hard to have an objective conversation about should you care about other people and doing the right thing? Like, I don't really know how to have that kind of conversation in a logical kind of way.

JACOB: And I'm thinking about where the innovation can happen is the big platforms—your WordPresses, your Wixes, Squarespaces. What innovations can they think of that can make accessibility the default? Like help people fall into the pit of success? What are the new innovations that they haven't come up with yet that just make accessibility just happen magically for someone who is –?

CHRIS: Yeah. I also sometimes feel like it's a little bit of a – well, so there's two aspects here. I feel like the you can have innovation, or regulation, but not both thing is a bit of a false dichotomy. I think one of the things we've seen in—my liberalness is going to show a little bit here—but one of the things we've seen in unregulated capitalism is that it doesn't necessarily drive innovation. It just drives more ways to squeeze profit out of people. I think you see that on the web with the current state of internet surveillance and ad tech. Do you, as a consumer, feel like you’ve got a lot of innovation out of all the new ways that large companies have figured out how to track what you do on the web so they can sell more toothpaste to you? Because I certainly don't.

So that's one aspect of it and the other is, I feel like sometimes we're overly obsessed with innovation for innovation's sake and there's something to be for the boring, predictable web. Websites that try to be different just for the sake of being different often just end up being confusing and unusable and I don't necessarily want that in my web experience. I find that particularly frustrating. I'm a really big advocate of “the boring web.” I like when I show up on a website and I know exactly how to use it, I know how to move around, and I don't have to follow a whole bunch of popup tutorials just to figure out how to achieve the task I'm there to achieve.

REIN: And if you look at the context that's driving, some of this behavior from startups, from UX engineers at startups, it's often that their business model depends on being able to sell customer data. There are a lot of mobile apps that if they lost the ability to sell their customer's data would cease to exist and so I guess, the question is, is it justified? Should they exist if that's the only way they can exist?

CHRIS: I struggle with this a fair bit because I use and have benefited from free sell customer data services in the past. I'm of the mind that I personally would pay for –like, let's just use Twitter as an example. If I had the ability to pay to use Twitter and they would stop recommending all these completely irrelevant ads to me in my timeline all the time, I would probably pay a not insignificant amount of money for that. But I know there's a lot of people who either wouldn't, or couldn't afford to and the value of Twitter to me would go down substantially if a bunch of people dropped off the service.

So that's a really good question that I don't have a great answer for. I feel like there's a balance somewhere between where we are today and this ideal, you're never tracked ever state. I don't know what it is, but I know there is one.

One just related things, since we're talking about ad tech, is a lot of these third-party scripts are some of the biggest offenders when it comes to slowing down performance on the web. They add a lot latency into sites. I just saw this interesting project this morning from a guy by the name of Adam Bradley called Partytown. I don't know if either of you have heard of this yet, but it's essentially a lightweight interface that allows you to load and run your third-party scripts from a web worker instead of on the main thread.

One of the biggest challenges with a lot of these scripts in JavaScript is that JavaScript is single threaded and so, all of these things block other stuff from happening because they're on the one main, I shouldn't say single threads. Single thread within the browser, but service workers and other web workers run on the separate thread in the background but don't have access to the DOM.

So Adam Bradley created this really interesting, that I haven't had time to properly play around with yet, library that allows you to bridge that gap. So you can run these scripts off that main thread, but still give them those hooks into the DOM where they're needed with ideally the potential of reducing the overall load on the main thread and the latency and performance issues that come from that.

The other thing that I think a lot of – I guess, another angle you could pull out here is the fact that tracking and analytics don't have to be as privacy invasive as they are. I think you see this in things like Paul Jarvis's analytics platform, Fathom, which is so privacy minded that it doesn't require a GDPR notification on your website to use. So it's not doing this really invasive follow you all over the internet kind of tracking.

Naturally doing that dramatically reduces that data's value for advertisers. But if you're looking to use that data for you as a business, it still gets you the information you need without sacrificing your user's privacy. So it'll tell you things like what pages people are looking at and how frequently certain things on your site convert without you needing to know that after leaving your site, John Smith went to Colgate and bought a tube of toothpaste and then went to Amazon and bought a new kayak and all that kind of stuff.

There's a balance somewhere. I'm not a 100% sure where it is, but I'm seeing a lot of interesting ways of coming at this problem.

JACOB: Yeah. I'm going to be very speculative here because I can't claim to know about all this stuff, but I would guess that a lot of users that are just plugging Google Analytics just drop it into their site. They have no personal interest in all that advanced stuff. Like, they're not going to use it. They do want to know about convergence and that simple stuff anyway and really, they're just [chuckles] funneling more data to Google [chuckles] in the first place.

CHRIS: Yeah. Honestly, a big part of the reason why I pulled Analytics from all of my stuff is it just wasn't giving me that much value. I was tracking all this data that I wasn't actually using. Well, not even track, I was basically giving Google all this data about my users for free that I wasn't really taking meaningful action on anyways. I'd imagine for a lot of, like you've said, folks who are using these scripts, they're not really doing much with them and probably don't need nearly as much information as they're sucking up.

So ad tech is a big, a big part of the challenge with the modern web. But actually, I think one of the other kind of related problems is the fact that we're using JavaScript for all the things. The entire frontend is being powered and generated with JavaScript and that just creates not just performance issues, but extreme fragility in the things that we build just because as a scripting language, JavaScript is so unforgiving when it runs into errors, or when things go wrong. It's never fun when you click a navigation element, or click a button, or try to load a page and nothing happens and that just happens so often because of JavaScript.

So for the last 3 years, I've been on this tirade about how JavaScript is ruining the frontend. We're starting to see a bunch of new tools now that take some of the best parts of all of the JavaScript we've been shipping to the frontend and get rid of all the stuff that makes it so terrible, or at least minimize it as much as possible. That's been really interesting to see. To the bigger trends I've seen here are around micro libraries and precompilers.

If you're both interested, I'd love to dig into that a little bit. If you have another way, you'd like to take this conversation, that's totally fine, too.

JACOB: It sounds good to me.

REIN: Sounds interesting.

CHRIS: Yeah. So just to set the scene here. I have lost track of the number of times in the last few years that I've heard people say, “You need to use a JavaScript framework in your app because it's better for performance.” “The real DOM is slow; React uses a virtual DOM so it's faster.” Or “If you write vanilla JavaScript, you're just building your own framework.” I hear stuff like this all the time and it drives me nuts because it's not true.

But the thing I think people don't always realize is that can potentially be true depending on how your UI is structured. So if you ever view source on Twitter, their Like button is nested within 13 other divs and is itself a div and so, doing the div thing whenever you update the UI with an absurdly nested structure like that is going to be costly. But I think you could also argue that that's just bad HTML and you could probably structure that differently and better.

React itself is 30 kilobytes of JavaScript minified and gzipped that unpacks in the browser into, I think it's like a megabyte, or two of JavaScript when it's all done. It's huge and all that abstraction is really, really costly.

So on one end of the spectrum, I've seen the rise of micro libraries, which take some of the best concepts of libraries like React and Vue—state-based UI, DOM diffing where when you make an update, you only change the stuff that needs changing—and then they provide it in a much smaller package that gets you closer to the metal is maybe the best phrase here. They remove as many abstractions as possible and in doing so, they mean you have to load less JavaScript, which is an instant win on initial page load time, and then by removing abstractions, the actual interactions are faster themselves as well.

So for example, a state change in Preact, which is a 3-kilobyte alternative to React that uses the same API is four times faster than that same state change in React. Even though you're using the same patterns, you're just loading a much smaller footprint. You’ve shed some features, but not all and you end up with that same kind of user experience, or developer experience if you like the React developer experience, but with a much smaller footprint and a much friendlier experience for the people who ultimately use the thing you build.

Similarly, for a while, Alpine.js was gaining some traction. It was another small library built based on the way view works. Evan You, who built Vue was so inspired by it that he just recently released Petite-vue, which is a small subset of Vue built for progressive enhancement. It's a fraction of the size.

So I find those really, really intriguing because they take some of the best parts and then they get rid of all the cruft.

On the other end of the spectrum though, are folks who have started to realize that you can get some of those same developer benefits without passing on any of that cost to the user and to be honest, I'm finding that aspect of things a lot more intriguing. This takes the form of proper frameworks, or compilers where rather than authoring your JavaScript, shipping it to the browser, and then having the browser generate the HTML from it at runtime in the browser, or in the client, you still author your content in JavaScript, but then a compiler builds that into HTML, converts your library-based code into plain old vanilla JavaScript without the abstractions and that's what's get ships to the browser.

So Rich Harris, a couple years ago, built Svelte and it was, as far as I know, the first of these tools. I'm sure there have probably been others before it, but Rich’s is the one that got most popular. It's just really, really interesting because you write with a similar pattern that you might in React, but then it spits out just HTML files in old-school like DOM manipulation, interactions. It's doing all of the heavy lifting before the code gets shipped to the browser and the user gets a really nice, lightweight experience. He is in the process of building out this new tool called SvelteKit that gives you really, really awesome stuff like routing and built-in progressive enhancement.

Actually, he just recently gave a talk and a demo on this at Jamstack Conf last week at time of recording. I'll make sure I get you both a link to that if you want to drop it in the show notes for this one.

But in it, he gave this demo about how you can author this page with an interactive form and if JavaScript is supported and loads in the browser, it does Ajax form handling. And if for some reason that JavaScript fails, it does an old-school HTTP form submit and then manually reloads the page and gives you the same exact experience. But you, as an author, don't have to write two different applications, like your client-side code and then your server fallback. SvelteKit just takes care of all that for you.

I think this is one of the biggest reasons why people like JavaScript libraries is they have a single codebase to manage and these compilers are allowing you to get those same benefits without punishing the user for that developer experience.

There's another tool that came out. I forget if it's called Atomic, or Astro. Astro, yeah. Similar kind of thing, slightly different angle. This one allows you to take all of your favorite client-side library components, mash them together, and then it spits out prerendered HTML and remove as much of the JavaScript as possible. So like you could use a dropdown menu component from React, a card component from Vue, and some Svelte files that you started working on and this will mash them all up together for you and spit out a ton of really small code.

Jason Lengstorf—whose name I almost certainly butchered and Jason, I'm very sorry—over at Netlify recently tried this on a next JS project of his and the resulting build actually had 90%, less client-side JavaScript in it and decreased the page load time by 30%, even though it used almost all of the same project code. It just produced a much smaller, faster kind of frontend thing with the same am developer experience.

So these are the kinds of things that I get really excited about because I'm seeing us taking everything that we've learned from the last 5, or 10 years and finally starting to swing in the other direction with tooling that doesn't harm the users and we'll hopefully, start to unbreak the web a little bit.

REIN: So the analogy I use to try to understand this is basically frameworks like React install a runtime into your browser. Just like Ruby installs a runtime, you're not just compiling down to C calls. You're compiling to C calls, but those C calls are a framework of runtime that is quite large and quite future rich. Maybe the most direct example is in Rust, if you compile with no standard and you don't have a runtime, you're somewhat limited in what you can do, but you're getting as close to the metal as possible.

CHRIS: Yeah. That's a good analogy. I like that. That's a good way to describe it.

JACOB: Safely.

CHRIS: You really are. Yeah, I like that.

JACOB: I think the analogy goes further and correct me if I'm wrong, but Rust gives you all of that memory safety you wouldn't get with C. Svelte is doing the same thing with, can we call it DOM safety? [chuckles] That it's going to help you not make the common errors that you would often get with state manipulation.

CHRIS: Yeah, for sure and really, it has the potential to just save you from this situation that happens where the JavaScript breaks and then the whole app falls apart. The less you can rely on that, the better. It's not that you can't still ship that nice, enhanced experience to your users if they can tolerate it, but you end up with something that's a lot more resilient, which is not just better for them, but it's better for you.

I've just lost track of how many things I haven't purchased because I couldn't get the site to work in these JavaScript heavy apps, or even there's been one, or two occasions where my wife has run into an issue on a web app she's been trying to use. I've opened up dev tools, found the error, gone into the JavaScript code, fixed to the error live, and then she's been able to continue and like, should I file that with their dev team and send them a bill for fixing it? It's just, JavaScript is so unforgiving in the browser and having tools that provide more fallbacks and safety nets around that is definitely a good thing.

REIN: Maybe the other thing is that the runtime starts take on a whole bunch of responsibilities like you just start to pack it full of features. So in Rust, the runtime does everything from a stack overflow of protection to processing command line arguments.

CHRIS: I don't know Rust that well so I don't have a really good comment on that, but, [laughs] or I can't necessarily make an analogy between that and JavaScript, but that sounds like a good thing.

I guess, the related thing here is we also have a bad habit, as developers—just not necessarily you guys personally, but just as a community—we have a bad habit of doing our work on really high-end machines and testing our work on really high-end machines and good internet connections, and then assuming that the majority of our user base is like that.

I think React works perfectly fine on modern smartphone, or modern computer and a really good internet connection. But so many of the people who use the things we build don't have either of those things, or have one but not the other and the house of cards really starts to fall apart in those situations. Things become really slow, really buggy really fast and this is again where we get into the whole there's no professional standards board that says your site has to load this fast on this type of internet connection. There's no threshold mandating, or fault tolerance testing, or anything like that like you might have with the electrical in your house, or anything like that and maybe there should be, I don't know.

MID-ROLL: And now we want to take a quick time out to recognize one of our sponsors, Kaspersky Labs.

Rarely does a day pass where a ransomware attack, data breach or state sponsored espionage hits the news. It's hard to keep up or know if you're protected. Don't worry, Kaspersky’s got you covered. Each week their team discusses the latest news and trends that you may have missed during the week on the Transatlantic Cable Podcast mixing in humor, facts and experts from around the world. The Transatlantic Cable Podcast can be found on Apple Podcasts and Spotify, go check it out!

JACOB: I was reading something interesting. So I haven't tried it, but I guess, it's called HTMX, which are you familiar with it?

CHRIS: You are the second person to mention that to me. I have not played around with it myself, but I heard just a little bit about it. So I'd love to hear your take on it.

JACOB: We might know about the same, but what it looks like is it's coming from the other side, which is saying you as a developer should really, you're just going to author markup and from your perspective, you don't know if the browser's native capability is going to handle it, or if there's going to be JavaScript that's going to look at a certain attribute and handle it for you. You just want to handle markup and I just think that's a really interesting take because it gets developers back into the mindset of markup first.

CHRIS: You brought up another good point that I totally forgot to mention. So one of the things that I think we're starting to see is—and we saw this with jQuery, too—I call it paving of the cow path and I, by no means coined that term. I'm sure you're both heard it before, but.

So when jQuery came about, there was no good way to get elements by classes, looping through things was really hard. Like everything about JavaScript kind of sucked and jQuery really showed the developer community what a good API around working with the DOM could look like. It took a long time, but eventually, the browsers standards’ bodies incorporated a lot of that into what we get out of the platform. So the reason query selector and query selector all exist today, and the array for each method, and all of these awesome ways for interacting with the DOM, the class list API, the only reason any of that stuff exists is because John Resig and the jQuery team showed us a better way and paved those cow paths.

As much as the massive popularity of state-based UI libraries bugs me because I think they're overused, just like jQuery was probably overused in its day, they have really in many ways, paved the cow path for what a better browser native system could be.

One of the trends I'd like to see more of is, to what you were just talking about, Jacob, HTML doing more of the work and JavaScript doing less of it. I think a really good model for this is in the details and summary elements, which allow you to create a browser native, show and hide disclosure component without any JavaScript at all. It's just entirely HTML. You can click it, it shows the thing, you click it again, it hides the thing. It's accessible out of the box. If the browser doesn't support it, it's progressively enhanced; you get the full text. Beautiful.

I want that for everything. I want that for tabs. I want that for carousels. I want that for image galleries and just any sort of interactive component. Like I want that and the really nice thing about details and summary where I feel they really nailed it is its styleable. So if you want it to look different, if you want the expand and collapse icon to be styled differently, you can do that. If you want to animate it in, you can do that. Like you can add CSS to make it look the way you want. And if you want to enhance it with some JavaScript, it also is a custom JavaScript event that you can hook into and build on top of, but you don't need to.

One of, I think the biggest boons of JavaScript libraries is the ability to add interactive components, complex interactive components with ease. I feel like for a lot of developer teams, that's a real draw for them. They don't have to figure out how to redesign an accordion, because there's a component for that and that has the real benefit of adding more accessibility to the web, too. But it would be really cool if the platform just did that for you and we didn't have to reinvent the wheel, but this is where I feel like a lot of a lot of these libraries are paving the cow paths and hopefully, at some point, the platform will catch up and we'll have some of this stuff just baked right in.

I think the HTML enhanced thing you just referenced is another example of what that could look like. I think from what I've gathered from it, it's still a runs in the browser type tool, but it allows you to just focus on running HTML. I could be wrong. It could be a compiler, but I just really want that stuff out of the box in the browser, without me having to think about it. I'm also a lazy developer, though so that's [laughs] part of it.

JACOB: [chuckles] Me too.

REIN: I feel like the $2 trillion elephant in the room here is that the browser everyone's using is made by Google.

CHRIS: Yeah, and that used to not be the case, right? We've lost a lot of rendering engines in the last 3, or 4 years. You can do your part by not using Chrome. I'm not saying you should use Firefox. I'm on Edge. A lot of people like Brave. I have very mixed feelings about that one for a variety of reasons. But yeah, no, that is true. Chrome is like what, 70, or 80% of the market at this point? So that, just from a tracking and data absorption perspective, is not great.

One interesting argument I've heard in the past is that it's not necessarily bad if there's only one rendering engine on the web and browsers are competing on different features. Like, imagine a world where you didn't have to worry about which APIs are supported by which browser; we're pretty close at this point. [chuckles] But I'm thinking back to when Firefox had more popularity and Edge was still running on its own operating system and they were always just a little bit out of sync.

It would be awesome if the entire web ran on a single rendering engine and features were layered on top of that. Like, I think there is potentially an argument for that being a good thing. I think the real problem is that that rendering engine is controlled by Google and so, even if you're using a chromium-based browser that's not Chrome, it's still very much subject to the whims of what Google wants from the web. And you see that in a lot of the way things get prioritized, and what makes it into the platform and what doesn't. They have a nasty habit of if they can't get the rest of the folks in the standards board on board, they just plow ahead with it anyways and then users start using it and then everybody either follow suit, or riots happen. So that is an elephant in the room and I don't really have a good way to reconcile. That kind of sucks.

REIN: Have you heard about the new idle tracking API fiasco with Google Chrome?

CHRIS: No, I haven't, but I'd love to learn more.

REIN: This was in the news a couple weeks ago, so this is pretty fresh, but Google is basically introducing a new API to Chrome that detects when the users are idle and – [crosstalk]

CHRIS: That's gross.

REIN: Every other browser manufacturer is like, “This is an invasion of privacy and you should stop doing it.” Meanwhile, Google is also like, “Web tracking is out of control and has resulted in an erosion of trust,” and they say that out one side of their mouth. Now to the other side, they introduce this tracking API that for example, malicious sites could use to determine when it's okay to use your CPU to mine Bitcoin.

CHRIS: I'm thinking about how they recently insisted that alert had to be deprecated because it's bad for user security and now I'm hearing about this and it just really doesn't – like, I have a tough time consigning that what we say, what we do kind of aspect. Yeah, that's gross and that really sucks. I wish Firefox had maintained more of its market dominance, that would've been nice. Or if the W3C managed the rendering engine so that browser vendors weren't controlling that. This is all really, it's a little bit disheartening.

I don't have a really great solution for this kind of stuff. I'm by no means smart enough for that. But for some reason, it seems really, really hard to get a new browser engine in the market as evidenced by the fact that even big corporations who have tried it, eventually just give up and fold and switch over to chromium. I'm not enough of a computer science expert to really understand why that is, but I can imagine it's very hard, especially as the platform gets more complicated.

REIN: Yeah. I mean and there's also a vendor lock-in. So on iOS, every browser is secretly WebKit under the hood.

[laughter]

Because they literally aren't allowed to ship their own browser implementations.

CHRIS: Right, yeah. That one's always really fun. That one catches people by surprise; you're running Chrome, but you're actually running Safari under the hood.

JACOB: I think for a while, Mozilla wouldn't make an iOS app because they didn't want people to think that they were getting everything you associate with Mozilla's values when you download it. I think they have one now and it's because they are able to do certain privacy features, even if they can't do all of them but yeah, that's an interesting debate.

CHRIS: Yeah.

REIN: S you could imagine a version of HTML that remove moves a whole bunch of features that makes it harder to track people, that makes it harder to implement extractive, hidden stuff. The problem is there's no way to enforce that a certain site is using that subset. That would have to be done at the browser level and Google has no incentive to ever make that possible

CHRIS: [laughs] Oh man, I'm thinking now about the web we lost.

REIN: Yeah. That was actually one of the motivations for Jim and I to not try to mess with HTML is oh look, we can specify this restrictive subset of HTML that meets our needs, but there's no way to guarantee that any particular site you access is actually well-behaving. So they came up with an entirely new protocol so that they could enforce very strict rules about what a site can do.

JACOB: Would that mean end users have to type in Gemini:// explicitly?

REIN: Yeah. So there is a – is that called the protocol call part of the URL?

JACOB: I think so.

REIN: So there is a Gemini:// protocol. Is it scheme? Anyway, there is that and it has its own protocol definition. One of the goals of the protocol is to be civil enough that you could implement it in about a hundred lines and keep it all in your head.

CHRIS: [chuckles] That's pretty wild. I'm on the Project Gemini website right now and this is very old-school. Ooh, and it uses the details and summary element.

REIN: That's basically an HTML proxy for an actual Gemini page.

CHRIS: Huh.

REIN: But there was no CSA. There's no JavaScript. There are no headers. Aside from the one header that you use to make the request, there are no headers so you can't insert anything in headers. There's no user agent.

CHRIS: See if this loads. No, this doesn't load. I wonder if there's any browsers that have actually incorporated this, or that allow you to – [crosstalk]

REIN: No, but there are like a hundred different clients that have been implemented in every language imaginable.

M: Ooh. I am noticing that it uses like a markdown-esque syntax. I'm looking at the advanced line types here where you use hashes for headings and asterisks for bulleted lists.

REIN: Yeah, but it doesn't allow inline links for example.

CHRIS: So you can always see what the actual URL that you're going to follow is? That's cool. Yeah, I – [crosstalk]

REIN: So there is this movement tool people are interested in moving away from the huge mess that is HTML, CSS, and JavaScript. Some people, I think are interested in this for privacy reasons. Some people, I think are interested in this for the same, I think motivation that brought you towards vanilla JavaScript, which is can't we just build sites that work better by not doing all this extra stuff?

CHRIS: Yeah, and they're separate, but they're also very tightly linked, I think where a lot of the privacy stuff is what causes a lot of the issues that bother me about the way that the web works today.

This is an interesting project. Candidly, I'm not entirely sure this will ever really catch on in a mainstream fashion. I think the genie is just way too far into the bottle, but it is interesting to think about a way the web could be different.

REIN: Yeah. It's interesting because this is definitely fringe, but fringes are where the interesting stuff happens.

CHRIS: Yeah. I could see parts of this informing what happens on the platform itself. The flipside here is I also do like some of the interactivity. I hate parallax and animation effects and all that, but I like being able to watch a video in a browser. I think that's pretty cool.

REIN: There are advantages to single-page applications to have – that user experience has some, I think real advantages over traditional hypermedia making a bunch of requests to new pages stateless. Basically, we’ve you figured out how to reimplement a stateful thick client right on top of HTTP.

CHRIS: Yeah like, being able to keep media playing as you navigate around those near instant page loads, that’s pretty sweet. Man, you're making me really sad about [laughs] just where the web is today. I hadn't really sat on just how pervasive ad tech and web surveillance are until this conversation.

REIN: Yeah, and it's also, React is almost a declaration that the REST manifesto was wrong.

CHRIS: [laughs] It's a bold claim.

REIN: I mean, React is – the original REST documentation basically would make React style SPAs impossible.

CHRIS: Yeah. Just one of the things in that talk Rich Harris from Svelte gave at Jamstack Conf talked about how there's this battle on the internet between the single-page apps are awesome people and the no, multi-page apps are better. They're way less complicated, better for accessibility, et cetera and admittedly, I tend to fall into that camp more often than not. He likened it to almost a bit of a false dichotomy where they both have really good points and they both serve important functions. Sometimes one is the right tool for the job over the other. So I absolutely have historically maybe come down a little bit too hard on the SPAs are always terrible, never use [chuckles] camp when they do sometimes have good uses.

But so, his whole talk was about this new term that he was trying to get going called transitional apps, #transitionalapps, that [chuckles] took the best of both worlds and allowed you to seamlessly move from one to the other, when appropriate, without having to just choose out of the box like, I'm going to build this, or I'm going to build that. I thought that was a really interesting approach that I hope we see mature a little bit more over the next year, or two because I think it has a lot of teeth and could do a lot of good for the web.

REIN: Yeah. Once again, it's the boundary zone between these two things where the interesting stuff happens, right? So HTMX, I think of it as federated multi-page apps so you might make multiple requests, but this one's just for this part of the page and this one's just for this part of page.

JACOB: It’s called micro frontends is a term I've heard.

REIN: Ooh. So the main difference is the micro frontends are an SPA thing and so, you have different subsites rendering different parts of the page, but they each render their own SPA type thing. But what you have with HTMX, or GitHub, this for a long time was GitHub’s style is I want to click this button and when I click this button, it's going to make a request for a new HTML fragment, and then it's going to put this HTML fragment on the page.

JACOB: Tight coupling has its value sometimes.

REIN: And then you also have things like Phoenix LiveView, the Elixir framework, where it looks a lot like a single-page app, but is actually making tons of server push updates.

CHRIS: This might be a little bit of – I know they call it HTML Over the Wire, that Hotwire thing that Basecamp came out with a year, or two ago and it's also interesting, Basecamp politics aside, where you build your old-school monolithic multi-page app, and then you layer a light JavaScript client on top of it that simulates a single-page app, or progressively enhances in some ways into one. I was really, really intrigued by the idea, but the more I played around with it, the more it pulled in some of the best aspects of both, but also some of the worst aspects of both and ended up being in my opinion, this weird Franklin project that did neither one particularly well. It just didn't work for me. I'm sure for certain types of types of projects, it can be really useful.

But I think the takeaway for the show is that frontend engineering is hard and there's a lot of trade-offs you have to make no matter what. I love to sit in my ivory tower and postulate about this stuff. We’re building really simple and really narrow apps that get by just fine as a multi-page vanilla JavaScript thing because they're not doing that much.

REIN: So speaking of frontend development is hard. There is a particular way in which frontend development is becoming incredibly complex and it is this movement away from client server models, away from Shannon communication style, I make a request. You give me a response. I make a request. You give me a response. This sort of a serial communication to a form of communication that's called joint activity, which is where just everything's happening all at once. I'm not making a request and waiting for a whole new page back. This part of the page is updating. This part of the page is updating. I'm typing over here, just a whole bunch of stuff happening at the same time and this is a paradigmatically different form of communication than request and response.

CHRIS: Do you have an example of that? I'm having a really tough time picturing what that looks like in my head.

REIN: So there's a book called Joint Cognitive Systems introduces this stuff if folks are interested, but think about incident response. During an incident, you're not synchronously causing things to happen and then getting the response. You have this person looking at this dashboard and you have this person on this machine doing this. It's all just happening all at once and you're not blocking waving on every next piece of information. The information arises in the environment whenever it does and you have to react to it in real time. There's no guarantee that only one thing will be happening at a time; any number of things can happen at the same time.

JACOB: Yeah.

REIN: It's basically non-blocking – [crosstalk]

JACOB: Several people are typing.

REIN: Yeah, several people are typing is actually a really good example. It's you no longer have an expectation that you're in this synchronous serial mode of communication with a single other entity. The entire environment is changing it in whatever ways it needs to and you have to respond to all of it. So React apps are starting to become more like this where the dashboards that you build today that you use to respond to incidents are like this. You've got 16 little widgets and they're all updating at the same time. Well, which one am I supposed to look at? Is that the one that shows me where the problem is, or is it this one?

CHRIS: Ah, this also kind of makes me wonder, not wonder, just think out loud. It sometimes feels like the things we build—and I'm admitting right up front, this is dumb. But it sometimes feels like the things we build are potentially more complicated than they need to be and I don't mean from the engineering under the hood, but there's a tendency to kitchen sink all the things like, if one is good, five is better and that's not always the case.

I think about, for example, Facebook, which has eight different things built into it and would each of those things be better if it was his own standalone application that had a very narrow focus potentially? That's just a really high-level throwaway comment that I think someone could very easily pick apart and point out all these examples of why it's stupid and wrong. But it also feels like if we didn't try and do this with everything we built, it would potentially alleviate a lot of the problems and challenges we have with all these moving parts and complexity. Admittedly, just a random thought that popped into my head so, not very well-developed in the slightest.

REIN: So it seems like we've organically moved into reflections, which is right on time.

CHRIS: Yes, indeed.

REIN: I think my reflection is, I don't think it's a coincidence, Chris, that you're, like you said, interested in both vanilla JavaScript and in privacy. We talked about it a little bit, but there are some deep connections between these two things, I think.

CHRIS: Yeah, absolutely.

REIN: And I think that the solution to one might be found in the other one and potentially vice versa. I think if we design – moving in the direction of vanilla JavaScript, I also think naturally moves us in the direction of increased privacy and maybe – [crosstalk]

CHRIS: Yes, potentially.

REIN: So the thing that I struggle with is how to motivate people to move in this direction because a lot of people have a lot of different conflicting goals. They may be in contexts that make it difficult for them to move in that direction. They work at a startup where selling user data is part of the business model and you're not going to get a product person on the same page with you on removing this tracker. It's not going to happen. Where are the actual levers that allow us to make progress in these directions?

CHRIS: Yeah. For me, because I've been thinking about this a lot, I think this is one of the reasons why I'm particularly excited about this new bit of tooling that I'm seeing come out. Because I am not personally big on lots of tooling for the things that I built, but I noticed that a large chunk of the community is and I think tools that make it easier to build things, but also keep the cost to the user down, whether it's privacy, or just the amount of shipped code are a very good thing. So when I look at compilers like Astro and Svelte, or I look at that tool we were talking about earlier, Partytown, that keeps those third-party tracking scripts off the main thread, that's great.

I think the other lever here is browsers themselves and the platform itself and what gets baked in. I think we already talked a little bit about how I think as long as Google is the dominant player in the browser market, there's only so much we can really do there because it is very much against their corporate interest to do that. But having platform native ways to do the things we want to do in a way that's easy and painless, like that path of least friction is in my opinion, probably one of the more powerful paths forward.

JACOB: I have two reflections. The first is, I think the web did peak at LiveJournal [laughs] for lots of reasons.

[laughter]

Yeah. The second is I'm thinking a lot about the software education industry and the whole space of just new developers generally and there is a lot of pressure in that spot that [inaudible]. It's all about single-page apps and showing that you can use “modern tooling,” which means React and probably lots of other complicated things that change every six months. I can't help but think about how that's actively shaping the web and it's making me wonder what would be different if we were encouraging developers to think about what would be best for what job and how React isn't the right tool for many jobs. So, yeah.

CHRIS: Yeah. I strongly agree. Strongly agree. There's definitely this kind of perception that if you're not using React, you're not serious about what you're building and I think the education market plays a big role in that.

On my end, I think one of the big things that came out of this talk, that I was not actually expecting to go in that direction so it was really interesting, was just around the whole privacy angle and how difficult it really is to maintain that privacy on the web. Even with tools like VPNs and adblockers and stuff, like the platform itself keeps making it harder and harder and I just really wish that weren't the case.

REIN: I really enjoyed this episode.

CHRIS: Yeah, no, I guess the only other thing I would add is if people enjoy having these conversations, or just want to tell me how wrong I was about something, I have a Daily Newsletter over at gomakethings.com that may, or may not be of interest to you.

REIN: Awesome. Well, thank you so much for joining us again.

CHRIS: Thanks for having me. This was a lot of fun. I appreciate it.

Special Guest: Chris Ferdinandi.

Sponsored By:

• Test Double: Software is broken, but it can be fixed. Test Double’s superpower is improving how the world builds software by building *both* great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater.
• Kaspersky Labs: Rarely does a day pass where a ransomware attack, data breach or state sponsored espionage hits the news. It's hard to keep up or know if you're protected. Don't worry Kaspersky’s got you covered. Each week their team discusses the latest news and trends that you may have missed during the week on the Transatlantic Cable Podcast mixing in humour, facts and experts from around the world. The Transatlantic Cable Podcast can be found on apple podcasts & spotify, go check it out!

Support Greater Than Code

02:47 - Anne’s Superpower: Empathy & Collaboration

17:45 - Framing and Shaping Relationships + Communication

29:47 - Helping People Learn – Work Therapists: Should/Could They Exist?

38:18 - Having Support Outside of Work: Networking

48:20 - Overcoming Job Responsibility Misperceptions

Reflections:

Arty: Being able to find strength and solidity within yourself so you can be someone that helps to contribute to moving things in a positive direction.

Casey: Coaching men on DEI. How could it be successful?

Anne: The future of where we need to go as a society, especially a tech-driven society, is to ask yourself how do you bring what you love to the table and to do it with love.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams and you can help. Test Double is hiring empathetic senior software engineers and dev ops engineers. We work in JavaScript, Ruby, Elixir, and a lot more. Test Double trusts developers with autonomy and flexibility at a remote 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater.

JACOB: Hello and welcome to Episode 255 of the Greater Than Code podcast. My name is Jacob Stoebel. I'm joined by my co-panelist, Casey Watts.

CASEY: Hi, I'm Casey. I'm here with our other co-panelist, Arty Starr.

ARTY: And I'm here with our guest today, Anne Griffin.

Anne is a product leader, a startup advisor, and subject matter expert in AI, blockchain, tech ethics, and inclusivity. She is the owner of Griffin Product & Growth, a product consulting and advising firm. Her workshop, Human First, Product Second, teaches organizations and professionals how to think about building more human, inclusive, and ethical tech products. She has lectured at prestigious universities across North America such as Columbia University and West Point, spoken at major events such as SXSW, and created courses for O’Reilly Media.

Outside of her work, she loves rest, barbecue, and beaches.

Welcome to the show, Anne.

ANNE: Thank you so much. I am absolutely thrilled to be here today. It's a gorgeous day in New York.

Arty, I know I've had a couple conversations with you. Jacob, we'll talk about this in a little bit, but we've had a conversation before and I just really love you guys. You guys are great. And Casey, I'm super excited to meet you.

ARTY: Yeah, the last time we were recording, we had some challenges with audio issues and so, we weren't able to get the podcast together, which is really unfortunate because we had an amazing conversation. But we're all back here together and I'm sure we're going to have a really awesome conversation this time and it's probably going to be even better than before.

So I'm excited to ask you our first question, Anne is what is your superpower and how did you acquire it?

ANNE: I would say one of my best superpowers is, maybe this counts as two separate things, but it's a combination of empathy and also collaboration, which I think empathy definitely helps make for a good collaborator.

And where I got it, I think it’s a combination of places as well is really growing up, I was never the popular kid. I was always the kid that was picked last in the gym. I had some friends, but I was really – again, I was unpopular; I didn't really have that many friends. I was picked on a bit.

So for me, I was in this position where I was always super conscious, or tried to be of how the things that I was doing was making other people feel. Because being in a position where I think some people thought like, “Ha ha ha, that's funny,” and don't think anything much further than that for me made me feel not very great. So I think some of that started from there and not to say I didn't have places where I was like, “Oh, I could improve in terms of empathy,” but I really think that's really where it came from.

Also, in terms of my working style, I've always worked best being in a collaborative environment. I'm not super happy when I have to work completely solo and there's zero collaboration going on. Not saying there aren't things in product management where you are working solo, but one of the things I love about product management is by nature, it is a super collaborative role.

And really, you have to have empathy to be a good collaborator because I would rather have somebody doing really amazing and creative work because they feel inspired to, they feel like they can be themselves and bring them their best selves into the workplace, and that there is trust. That is the thing that makes me feel the best about anything I do honestly. And obviously, launching new things. That's great. I love that. Obviously, it's a big part of product management. I wouldn't be in it if that wasn’t important.

But honestly, I think I get equal amounts, or possibly more fuel from knowing that my team feels empowered, knowing that my team actually loves being on the team, and is really just excited to be together and be able to just do their best work and not out of like a, “Oh man, I'm going to get in trouble by someone,” or “Oh, I have to be super scared of political stuff,” but really being like, “I got to show up as me today and that empowered me to be my most creative and best self.”

ARTY: Wow. The story you were talking about at the beginning with how you were feeling growing, never the popular kid and how that made you kind of hyper aware of how your actions and the things that you did ended up influencing the people around you and just developing this hyperawareness that gave you this empathy and how you were thinking about things.

I'm curious, did you also have environments and context where you were accepted and well left?

ANNE: Growing up, obviously, I'll say I was very fortunate that my family has always been very loving and accepting. So I'll say one of the most critical environments I had that I went to daycare for a really long time and I felt like there wasn't really this I was an outsider there, but in terms of school environments, and I'm not really sure what it was, pretty much from grade school all the way through high school, I was an outsider.

So I think it's also having have been in certain other critical environments where I was loved and accepted and I think I met one of my then best friends in 5th grade, which then she eventually changed schools, all this other stuff. But having certain people, even if there wasn't a lot, and then having those critical environments where I was accepted. Knowing what it feels like when you are accepted and contrast to this whole thing of feeling like people don't really care you're there, or they don't really want you to like join them at lunch, or other things like that.

CASEY: Yeah, that contrast sounds really powerful.

This is kind of random, but it's reminding me of, I went to physical therapy last week because my posture is bad. My hands went numb 2 years ago. It's recovering. I'm pretty good now. But they were teaching me how to do a squat with good posture and they said, “Here's the right way to do it. Bend your back here, do this, make sure your shoulders aren’t tense,” and then they had me do it wrong. So I got to do it the right way and the wrong way and that helped so much. I've had like 4, or 5 PT people. This was the first one that showed me the wrong way for contrast. It's powerful.

ANNE: Absolutely. I agree that it's so powerful and I think for me, that's part of where I originally fostered like here are the feelings I know I want to have and that I can have and how do I create that sense of safety in being one's self outside of these environment? I really felt like once I got to college and especially once I was working in environments that were healthy enough and safe enough for me to be able to create this is the right type of environment where there's trust and collaboration, I was able to do that because I had experienced the wrong way of—I'll say, the wrong way as in being excluded from things, people not really caring about how you feel based on comments, but had also, this area where I had learned also the right way.

Actually, one person who was very, I think, fundamental in helping me translate that into the work world is one of my mentors Dana. Actually, she used to work at Microsoft. She actually early retired from Microsoft. So she was at Microsoft while I interned there and she really taught me that well, it shouldn't be on you to solve all your workplace's problems because they're not paying you to solve a culture problem that they should be handling. But you should really act at work in terms of implementing the type of culture that you would want to work in. Don't just be, “Oh, I'm just upset because all this bad stuff's happening,” and that kind of stuff. You have the right to be upset if bad things are happening in your workplace.

But if there are certain things that you can foster that you have control over in terms of the attitude on your team and how you empower other people to be able to talk about what are the problems, what is going well, what don't we like, how can we change it, what are little things that can nudge the atmosphere and really foster that? Because there's some places, they're going to be toxic; [chuckles] they're not going to be big impact there.

But there's also a lot that can be done in places where you are empowered to do that. Especially as a product manager on your own pod, or your own team, so that it is a happy place to be, that people do feel included. People don't feel like people can just jump into your Slack channel, say a bunch of trash, and then leave and it's completely fine. I think that's that contrast there is learning what is the right way, the right posture, I guess, for that type of environment really helped me and especially from my mentor Dana at Microsoft.

CASEY: Anne, I feel like you are saying so many things I say all the time and I’d love to hear it from another person's voice. I believe strongly that you can make a small bubble that you're in. Like a happy and effective environment, a team that you're on. Even if it's a toxic culture overall, you can have your own happy bubble, but I don't know. A lot of people don't value that, or they don't celebrate it when they manage to get even one bubble and that can be frustrating. That’s why it's so cool to hear that you have felt like you've made some bubbles happy before.

ANNE: Yeah. When I say empathy and collaboration are my superpowers, I would say also creating bubbles are one of my superpowers, even in remote environments. Even before the pandemic, one of the places I worked was a remote first company. It's always really interesting because I think because again, empathy and collaboration are my superpowers, I crave that a lot and I'm going to be working for 8 hours a day so I try to create that everywhere I go.

Not saying I'm trying to exclude people from the bubble, but anybody who wants to be a part of that type of culture, I welcome them into that and it's amazing because I'll go into places and even that small startup people are like, “Whoa, when you started, I noticed this big culture shift.” It was really small so it was much easier to make that kind of impact, but people started feeling a lot more connected to each other, especially we were remote first.

We weren't really centralized in New York, or in the United States. So there were people who were either based in Nepal, or Mumbai where they said because of the time zone differences, people didn't really think about okay, is that person getting the support they need when there's hours where people are not up and if we have more people in other time zones, how do we make sure those people feel included? Because there's a lot of ways you can actually make people feel excluded, even if it's unintentional and people may still resent that, or still may feel bad and even if they don't resent you, or blame you, those are things where I think a lot of people just say, “Well, it's not really my problem,” or organizations say, “Well, if they want to get a paycheck and they want to work remotely from that region, they're just going to have to deal with it.”

I also think I'm like, “But if you don't care, why are you hiring people in that region if you're not going to foster a culture and just an overall company bubble of making people feel like they matter, that they're included, that they're getting support and being creative with how you also support people asynchronously?”

JACOB: I think like in addition to that often is the case, the geographical differences, there's other differences at play that are specifically about power, or just in terms of country of origin. You might have a lot of circumstances where you've got people on salary in the States and everyone is a contractor in India, or something. I think there's a lot of intersecting issues that can come up with people working internationally.

ANNE: I would say, I completely agree. At that startup, everyone was an employee, but I definitely think there was a difference because people are used to, “Oh, those people in that time zone are usually a contractor.”

I've worked at plenty of companies where if somebody was remote, it was because they were contractor and they usually were from a country of a lot of brown people and how people treated them was different. It's very fascinating because consistently I see in cultures where there is not conscious messaging from the leadership about “Yes, these people are contractors.” Yes, we've outsourced this work to this place.” Conscious culture shaping and messaging from the leadership. “Hey, they are part of our team. We're working on the same goal. This is how we treat each other in this environment.”

You get very inconsistent results in how people choose to treat those people and I've seen it where I've worked with a team and it was like, “Oh wow. This was such an amazing project. We work really, really well together.” And then that same team gets passed to another person next project, that sort of thing and I talk to the contractors and they're like, “Yeah, no, that person just yells at us and tells us every time we do something wrong and they don't ever bother setting up time to discuss requirements in more detail.” They just feel like, ‘Oh, you should get it.’

You have to think about okay well, why would you not have these conversations with somebody who's based in India, or Columbia, or Brazil, but you're having these conversations at the coffee cooler in-person and you expect them to pick up the same amount of information, to understand the same amount of context?

It was just confusing to me because for me, I felt I would be very stressed out and have tons of anxiety if I feel like I'm missing lots of information, lots of context and my team is just telling me, “No, no, no, no. We gave you everything you should to just understand it. I don't think we really need a meeting because I sent you everything.” And me feeling like I still have questions and there is either this resistance to making time to talk to me about it, or this sense of I should already know this, which I think some of us have all experienced that at some point in our career like, “Oh my God, I'm scared people are going to think I already know this,” but when you're in that also power dynamic and you're on the side of less power, I know I would feel hyper anxious about the perception is that I'm not doing a good job when I'm really trying my best.

So those are things that also really bother me when it comes to people decide we're going to have a team that's going to be based in this different time zone, or this is going to be the only team that's not based in the US and there's not thoughtfulness from leadership. How do we create a culture that everybody feels included and everybody is set up for success ultimately?

Because people really liked the idea of remote work when it was like, “Oh, I can move to Ohio and get a really nice house and have a place in the suburbs.” But then there is all this stuff where people like that idea. But before it was like if you have someone who was based somewhere else, there was a lot of stuff where people are like, “I don't think we need to really do anything extra for them. They got it.”

And then people who are now experiencing remote work for the first time, they're like, wait, there are actually certain things that are pretty hard. Especially if certain people are centralized around certain time zones, or certain locations. That is just not something that is, I think well-thought-out and especially when we start talking about contractors. Even if a company decides these are going to be full-time employees in other countries, depending on how long a company has existed in a centralized location, there's sometimes resentment and fear that oh, they're just going to hire all these cheap people from this country and that seeps through in how people choose to communicate with those people.

I know I'm saying a lot, but I'm also super – I've been technically working with remote teams since I was in college and the first full-time job I ever had, my team was based in Belarus. I've worked with so many remote teams over the years and I have so many opinions [chuckles] about it. I just see again and again, and again that all it really takes is okay, if I would say something like this to someone at the coffee cooler about, oh, this project's happening, da, da, da, da and that little extra context, which sometimes seems insignificant. I need to make sure that there is some Slack message, email, how do they work best like some sort of thing so that they are getting an equivalent experience in a remote world.

ARTY: Wow. One of the things I'm thinking about now is just how much very few words, very few communications that we might have with someone has in terms of impact and shaping that relationship, and impact and shaping all communication that cascades from that relationship. Like you were talking about this example where you had one experience with a team and then there's another relationship that takes place.

The view, the perception of how they see these other people and this other team out there versus your experience—just the variance in the relationship and how it evolved the perception of the team and their capabilities and everything else—can just snowball from there, from the seed of a few conversations and the importance and the responsibility of leadership to frame that relationship, to frame it in a way that is supportive, and seeing of the humans and the challenges, and the power of going, “You know what, we're all on the same team.”

CASEY: I'm thinking back to the small bubble thing we touched on before. It sounds like if you were on a small bubble team with these remote people, you could fill them in. You're on it, you got this. But then if they're on another team, a small bubble that's not as remote aware and thoughtful, then they're not going to do as well. So I'm always thinking about this. I'm so confident I can get any small team to be a happy bubble if I'm in there long enough and I put my mind to it. But then the level up, it's not necessarily within my power as a PM to make a change above my level.

What experience have you had around trying to do that, whether it went well, or it didn't go well, or you made some amount of progress toward changing the company culture? I want to hear that.

ANNE: Yeah. So one of the companies I was at, they opened up a new office that was many time zones away from the centralized time zone. This was a thing where the centralized office was in-person and they created another in-person office in this other time zone, full-time employees. There were just things that people would say that were so small, but it was driving me absolutely nuts. Because I was like, “I know you guys wouldn't say that in front of the people from that other office.” It would be things like, “We don't know what hours they work,” and this was after a whole quarter – I think that office had been open for at least a year and the people who were saying this, “We don't know what hours they work” had been in a meeting actually that I set up that was once a week with those specific developers.

I talked to my boss about this because I said, “Okay, so usually if I have a question about, ‘Hey, what hours are you working whether it's like, you're in my same time zone and you drop your daughter off every day at 3:00, or whether you're in some very remote time zone from where I am.’” I'm like, “Just ask them.” I'm like, “They're right there.” Like, how is their confusion? Why is it that you can talk to the people that you know in the US, but you can't talk to the people that are outside the US that also happen to be brown people?

There were other little – and that's why they sound really small, but I was thinking, I was like, “But literally, we've been working with them.” [chuckles] like, directly with this specific team for now three whole months, how are we saying I spent three whole months in meetings with them and I never asked them this question? Google Calendar also has working hours, which our company utilizes. So I was like, “If you have a question about are their Google Calendar working hours up to date? That's a very simple question.”

The fact that it was like, these were questions that were being asked to a broader group where people from this other office were not included and they were like, “I think we need to better understand ways of working,” which I agree. You want to understand what helps people work their best. But these were things where it was just like, this is hard working with them and I was thinking to myself, I was like, “This whole quarter, this team has actually been ahead of schedule and you've been in meetings where if you had questions, you could ask them directly. So why is this a organizational concern now?” It was something where I don't think anybody intentionally meant harm, but I thought to myself, I was like, “I would be mortified if any of this got back to anyone in that office.” Number one.

Number two, I was like, “This doesn't have a place in our company, but I am not at a level where from a political standpoint, I can confront some of the people who said those things.” So it's something I had to go through my boss and say, “Here are my concerns. I don't think this was intentional. But the fact that these concerns only popped up with these specific people in the specific office that also happen to be in a country where realistically, they're getting paid less than us.” It's an office where there's only going to be brown people in there—and I don't say Black and brown because it's a place where it's like, there's definitely only brown people in that office.

But I had to address it with my boss and my boss had a conversation and some of that stuff reduced, but it's the kind of thing where running into those things and running into people where I'll say a lot of times, it's not even direct, but it's things where I'm like, “They know what those things mean when they hear them and I know what those things mean when I hear them.” I just think people don't consider how does me thinking – even once the thought and gets in your head, you have to stop and think like, “Does this thought even make sense? Why should I be concerned about this? Maybe I should stop myself and be like, ‘What can I do to [chuckles] make sure that my questions don't make people feel excluded in this environment, especially because they work here?’” Contractor, or full-time. These are our full-time people. But even if they're contractors, they work here. We share the same goals. We are on the same team. We are part of the same culture.

I don't believe in having second class citizen people in a company. I don't believe in second class employees. So I'm like, either the way we ask questions about anything about them, or the way we think about them is not going to be different than how we're going to think about everybody else who's US based and also in a primarily white environment.

I'll say it did get better after that addressing with my boss. But it is something where it's a lot easier to handle when it's on your team and with people you have a lot more influence over. It gets harder when there are sometimes people above you, or are in other circles where you're like, “Those people did come to my meetings, but they were technically out of my bubble in a way and I had to kind of go a level above me and voice my concerns because if I don't voice those concerns, no one else is going to voice those concerns.”

Also, I don't know if those people are necessarily empowered. If they had overheard those things, are they going to feel empowered enough to say the truth? Are they going to be afraid for their jobs if they speak the truth about how that type of thing makes them feel? So oftentimes, there's this thing that happens at companies where people feel, “Oh, well no one said anything so it must not be a problem.”

ARTY: Yeah. The silence is a response. It's a thing that we feel and experience, too. When we say something and the response is silence, when something happens and the response is silence, it's a response. It's not an absence of response; that is a response.

CASEY: Yeah. This sounds like a stark example of a power dynamic. So it's the main office/remote office. It's the culture and ethnicity, both. I'm wondering if the people on the more powerful side of the group, the main office, are they aware of this dynamic? If they're aware, are they interested in doing anything about it? If they're interested, are they committed to doing things?

I can tell, Anne you are committed to doing things, but of your peers. I wonder where they are in the spectrum of being aware. If they're not aware, it's hard to blame them. If they're completely unaware and no one's offered the ability to become aware like DEI workshops, I don't know, then nothing is a silver bullet.

ANNE: Yeah.

CASEY: But there's a whole path that people go on to become such strong allies like you are.

ANNE: I think it can be hard though, because in several companies, I've had trainings about unconscious bias, harassment, things you don't say about team members, things you don't do to exclude team members, how to create an inclusive environment. But then once you get into reality, things that people start thinking, for them maybe are in a gray area, or maybe a specific thing that wasn't covered by that training. There's a lot in which people are like, “I could never harm someone in that way because I'm not racist. I'm not sexist. I'm not homophobic. I'm not ableist.” I think that's one of the problems we have as a society, even bigger outside of the workplace, is this perception that I who took the DEI training, or I took the whatever training could not be racist. I'm married to somebody who is of this background. I have a friend that is this. I have friends who are gay. I can't be this.

There's this whole thing where I think that's one of the harder things to learn that even someone like me where I'm like, “Yes, I'm committed to changing this,” and da, da, da, da. I can still harm people, I can still mess up and hurt people, and I don't get to just say, “I had good intentions so you should just be grateful for that,” or “I had good intentions. Therefore, it doesn't count as this.”

That's something that I think we need to learn more that even if you have the best intentions, you can still hurt someone and it still counts as hurting someone. [chuckles] Doesn't mean it doesn't count because you had good intentions and sometimes you just have to say, “Oh my gosh, I did say that. That was this. I need to work on this area. I'm sorry.”

I think our reaction to society is we meet the reality of ourselves in ways and times that we don't expect and it can be a shock and out of fear of like, “Oh my God, if people think I'm racist, am I going to lose my job?” Or da, da, da, da. I'll say, if you're very racist, I do have opinions on that. [chuckles] But if it's like you made one comment, I’m like, “Apologize.” Realize you're like, “Yeah, me being concerned about how these people work maybe didn't make a lot of sense.” “Yeah, my best friend is this, or this, but for some reason, I still thought that thought,” and that's something where it's like we don't really teach people how to confront that, or that it's okay to be like, “Well, crap, I messed up here. Let me apologize.” Instead of putting out five non-apologies before I put out an apology later where nobody really believes and it's not sincere.

JACOB: Or how can we have an environment where that feedback loop related to microaggressions is just normal and low friction?

ANNE: Yeah.

JACOB: And then certainly, people will should obviously make amends for it, but it doesn't have to have more drama than necessary.

ARTY: I think those kind of conversations are always uncomfortable, but that doesn't mean we can't have uncomfortable conversations and learn how to be resilient working through challenging conversations. Like I don't think – it's not that it doesn't get easier with practice and things.

CASEY: For my work with my consulting group, I like to focus on people who are interested in learning and then how they just need practice. They need to know those tools and the techniques and they can practice it. I'm personally not interested in people who are totally unaware and disinterested. That is a harder battle and I want to get better at this middle step first before I would focus up stream, up the funnel. But there are a lot of people who are just oblivious and they would love to learn and have space to practice this and that's its own problem, its own difficult challenge.

ANNE: Yeah. I agree in terms of giving people a place, who actually want to learn and I would say also are doing the work to learn because – [overtalk]

CASEY: Yeah.

ANNE: And I'm not saying, okay, if somebody is on the receiving end, that they should be that person to have to put up with this, but it sounds like you have a consultancy where you're able to work with those people. People can pay money. So obviously, somebody is interested in being there to actually have that space and learn because some people, they would otherwise learn more, but there's certain things where it's nuanced.

Also, I think there's a piece about in practice because there's one thing where you can read something like White Fragility, you can read all the books you want, you can find that article on the web, and still have things that come out of your mouth where you're like, “No, don't say that, don't do that,” or “In this situation, just your specific action even if it's not words was not great,” and teaching people the tools of recognizing for themselves because it's also reading self-help books.

CASEY: Yeah.

ANNE: But then thinking, because you read the self-help books, that all your inner actions in real life are perfect and fine. That's why we also have therapists because therapists tell you – you're talking about your day and they can help you unpack well, why did you think that? Why was that your reaction? What were you thinking? What were you feeling? Because you can read all the self-help books and think you're doing these things and there could actually be all these layers under it that you're realizing, “Oh, in practice, I think I'm doing this, but here are the actual outcomes of what I thought I was achieving.”

JACOB: Because there's a feedback loop where you get to, for lack of a better word, experiment with what you learned and find out if you understand it correctly. I don't really like that word experiment—I can't think of a better way to put it. But it's like, I can learn a foreign language all I want by studying in a book, but it really cements when I go and have a conversation with a person that speaks that language.

CASEY: I like the parallel to therapy. You just inspired a new idea I never had before. What if there were some people who would coach others one-on-one like a therapist, like a session. I do more workshops where I end up having people in breakout groups and they talk to one, or two other coworkers about things. It's hard to make that safe space where they're comfortable and they'll make progress, but I'm pretty proud of that I can do that in a lot of the time, but then there is no expert involved. There's nobody who really knows; it's just peer feedback.

So what if there was a coach for one-on-one training on how to be a better ally? I think that would be really powerful. And my question is how do we get companies to pay for it for their employees? That's its own problem because workshops scale better.

ANNE: Yeah, and honestly, I really feel like they should just have that type of person on retainer for especially the leadership. Not saying individuals on teams don't need it because I think that's another thing where it's like I'm not saying, “Oh, reserve some of the most expensive resources for leadership and lock it away.”

But also, we're talking about how do we teach people to recognize what they're doing and also, how that impacts the teams that they're responsible for managing and how that impacts the company culture. Because I think that's how we end up seeing a lot of these things keep repeating themselves in company culture again and again and again and again. Even the things that are perfectly legal, but are actually still harmful in some way, shape, or form to different underestimated and underrepresented groups and I think that would have a massive impact.

JACOB: This is a great idea because I feel like I've wanted to work out questions I've had about work with my therapist and there's so much I have to bring her up to speed on just in terms of she doesn't work in tech, she's a therapist [chuckles] and doesn't understand the company at all because again, she doesn't work there. I feel like that would be so helpful; just someone who understands generally what this company is working on and what my job is, but doesn't have an active day-to-day involvement in what I do and can give hopefully, a less biased perspective. I love it.

CASEY: I hear that from a lot of people. People want a work therapist.

ANNE: Yeah.

CASEY: Or whatever you call it.

JACOB: Yeah.

ANNE: I think they exist a bit. I don't know specifically how you find them, but I will say so, it’s not a therapist and there's different types of career coaches. I have a career coach that I've been working with since I think 2015 and she's not a therapist, first and foremost and also, she is not this type of role that is helping me be less any of the things that potentially anyone could do to harm another group. She's not there to be like, “I heard you mention this. That sounds ableist.” She's not doing that.

But one thing that has really helped me in my career is having somebody who actually knows what I do. She is not someone who is in tech. She is a third-party person and she actually knows the different problems I've had in different companies, where the themes are, what has been unique to different companies, and also asking questions to unpack things to help me also understand am I the asshole in this situation, or was something else going on that was completely out of my control?

That has given me really good perspective in my career in where am I owning something that's happened versus this is out of your control. Maybe there's some things you could have done better, but also, don't beat yourself up over this thing when your leadership team should have been doing this. She also knows my habit. She also knows that hey, it feels like you're slipping back into this habit at work.

There's different types of career coaches. There are different ones where they're like, “I am focused on product management thing, XYZ and this is what's going to get you specifically this promotion because I'm going to have you work on this specific product skill.” This one is, she's more of a generalist.

I actually started seeing her more for career influence product coaching, where I was much more junior at the time and really struggling to understand where the disconnect was in my career, where my actual project teams were saying things like, “Wow,” “You do such a great job. You're amazing,” da, da, da, da, and have very senior people I worked with that would say, “When are they going to promote you?”

And then when I would speak to my manager and my manager's manager, it felt like I was treated very junior, I didn't really know how to talk to them. So the things that I was updating them on, I thought were very important, which then I then learned oh, it really just made me sound like I don't know how to focus and I was just pouring information at them and they were like, “Oh, she doesn't know what to focus on and she doesn't know this.” I thought I was impressing them. [chuckles] It's one of those things where having somebody with that third-party perspective and also someone where they can help you work on specific things that are, I think more general also is very helpful.

She's not a work therapist. She's not helping me unpack how my childhood experiences impacted how I reacted in the work situation. But she is someone who knows a lot of my work history because we've been working together for so long and I'm able to talk to her about when things are going really, really well. She's talked to me when I'm like, “I started looking for a new job because I can't take it here anymore.” So that's been something I really value.

CASEY: That's so cool. I love hearing it. You have support. Your support doesn't have to exclusively come from your manager and your current job. You hear that, everyone listening? You can have other support. It could be friends, too.

ANNE: Highly recommend support outside of your manager and your current job.

JACOB: Not easy in a remote workplace, or maybe it is, I don't know, but I would think it

ANNE: Networking is really big and I know people always are like, “Networking”! But to be specific about networking, because there's different types of networking, networking in a way where you are finding the online communities of people who value the same things as you and possibly even going through similar things, but not resorting to toxic ways of dealing with those things has been one of the biggest career hacks in terms of finding people that also understand outside of my career coach. Sometimes I can even ask them very specific questions to being in tech, or very specific questions to being a PM, or being a PM as a Black woman in tech.

Those type of things have made a big difference for me because there's a lot of things where you start seeing patterns and oh, other people are experiencing this. This is how other people are dealing with it and ways it didn't work out and the ways it did work out. That's something where just sending LinkedIn messages off to people who just seem like very successful. While I know that is a thing, I've really found the things that have made the biggest difference for me is finding these groups, whether they're private Facebook groups, or they're LinkedIn groups, or they’re private Slack groups for women in tech. Really, that is where I've been able to find additional support.

Also, there's people where even they're my peers and I'm like, “Whoa, we're now collaborators on something that we both really value a lot, that my day job would never give me a project like this and now I'm getting to collaborate with somebody outside of my day job to work on this thing because I met somebody else who fits in turn of values, what they're interested in.”

I think that's one of the biggest things of networking is finding the communities first before you find the individuals because in those communities, you're going to start noticing who are the individuals I tend to align with and maybe I shoot them a message, or maybe they need help with interviews and I can do a mock interview and then that starts we reach out to help each other, that sort of thing. Those are all things where I highly recommend and I think are much more effective than just being like, “That person looks like they probably make a lot of money at that company,” that has always been the most helpful for me.

CASEY: So I'm wondering, how do you find these communities? One trick I love is to tell people you're looking for those communities, they might know. I don't know, why this is so far into a lot of people. You should tell people your goals publicly. Did you do any of that? How did you find yours?

ANNE: Absolutely. Some of it is telling people, “I'm looking for these communities,” and some of it is people I've worked with in the past who have been part of my bubble, understanding those are the communities I would want to be in and saying, “Hey, are you in this Facebook group?” and me being like, “No, I've never heard of it,” and then they just add me.

There's one that is for Black women in tech and it has been one of the most valuable online communities I've been in long before the pandemic because somebody just added me because they know my values align and also, being a Black woman in tech and having to experience certain things.

In addition to everything else I do, I also run a small group coaching program called Attract Your Dream Job where basically, I teach people how to get companies to come to them, or if you do apply making it so that you have a better likelihood of them actually responding to you instead of applying to a hundred companies, just what I call spray and pray. So how do you avoid that?

One of the things I always tell people is actually the thing you just said first step is number one, tell people that if you're looking for a job, don't blast it out on LinkedIn. If you have a current job, you don't want to get fired. But tell your inner network, get their email, send them a DM on LinkedIn something and if you're also looking for those groups because we actually have an assignment that is you actually need to find three groups like this for your job search and telling them reach out to people saying, “Do you know a group for people who are really into art and backend development?” I've made that up, but those things where it's not just like, “Here's just a generalist tech group, tell them what you're looking for.”

And then the other piece I always tell them is go to LinkedIn, go to Facebook, go to even just Twitter. Well, you could start with really LinkedIn and Facebook, you actually can search for such and such group in and then whatever your industry is and that's one way it's actually very easy to find people to connect with, or those communities. And then also on Twitter, starting to browse around, I'm looking at hashtags there's #BlackTechTwitter, which is like, I really love that and there's a lot.

Actually, we did a whole barbecue here in New York in 2019 because of #BlackTechTwitter because I was like, “I have this idea that we're going to have a Black Tech New York cookout,” because I was like I never see other Black people in tech, unless this is a hiring event by this company for DEI stuff and I was like, “I’ve never see an event that you just get to hang out and talk and while we might talk tech, this is really just an opportunity to meet other people in the industry who are like you.” That really was all organized off of a thread on Twitter.

So there's lots of places you should go, but you should always let people know what you're looking for, what type of community you're looking for, because people don't know. They don't know.

The other thing I always tell people a lot. You'd be surprised how many people who have no idea what industry you're in, or what you do. You think your friends know. You might even think people you used to work with know. But one example I give a lot is one of the jobs I used to work at, I had a coworker who got peer feedback. He was a product manager. He got peer feedback from someone else that his wireframes were terrible and my coworker doesn't make wireframes. [chuckles] We have a whole UX designer on that team that was responsible for wireframes. But the peer feedback was like, “This person's wireframes aren't very good. This person's very nice, but the wireframes are bad.”

You realize while this is not necessarily the most common thing, if somebody on your team that worked with you for a whole project can misunderstand what your role was in the project and what you actually produced, people who haven't talked to you in a year, or two can easily misunderstand what you are doing, or if you’ve changed industries. There are a lot of things that people can get confused about. They saw you post something on your Instagram once and now they think that you work there. So there's just a lot of ways in which people actually have no idea how they would even stay hard to help you if you don't tell them.

CASEY: Yeah. People don't know. I got an award for the last company I worked at a year after and I was hesitant to post it because I'm like, “I don't work there. I've been gone a long time. I don't want to confuse everyone.” I did anyway, but I don't work there. Surprise! [chuckles] Yeah, people don't know unless you tell them, unless you talk to them about it and even then, they might not remember. That's normal human behavior, too. Especially in tech. What's a product manager anyway? [laughs] That's the question. I don’t.

ANNE: That is the question and the reality is that while product management as a discipline has been around for a while, there are a lot of companies who did not have product managers, really, or a product manager discipline until the last 5 years. That's just the reality. We like to think, “Oh man, this has been around for a really long time.” It has, but there are a lot of companies where they were like, “We have a project manager and we have a BA,” and there's no one who's a product manager.

While some of those skills overlap, a product manager has also a lot more of this undercovering the why piece that technically isn't a solid responsibility of a project manager and a BA. Those people can do that type of thing, but they're technically not accountable in their career for those things. So if you want to make sure you hire someone who is going to be accountable for that, has a track record, and is much more focused on moving metrics than just, “Hey, the project is done,” you would want that separate discipline.

But you have actually certain developers where oh, this discipline is really recent at this company and that developer has been there 10 years and they're like, “I only know the product managers I work with,” and half of them were basically just project managers where the title changed and – [overtalk]

CASEY: Ah, I hate that.

ANNE: Yeah, which some of those companies do stuff to upskill those people, but there's a lot of people out there who've never worked with a product manager and don't really understand well, what is the difference between that and a product manager?

I actually had someone at my current job, who actually is my best work friend, who didn't understand the differences between a project manager and a product manager. She thought it was a matter of semantics. She's not someone that I necessarily get to work with frequently so it's not like she's viewing my work and she's like, “It's the same,” but it's something where people even you work with, it's not even guaranteed that they understand what you're supposed to be doing and after you stopped working with them, they probably have no idea what you were [chuckles] supposed to be doing. They forgot. They were like, “Yeah, they did good things,” and like, “That person was a good project manager,” and you’re like, “No.” [chuckles]

But it's the kind of thing where you have no idea what people's perception of what you're supposed to be doing at your job, where you could be a frontend developer and somebody saying, “That person was not very good at updating things from the database,” and they're like, “Yeah, because they're a frontend developer.” There's a lot of stuff where people don't necessarily know, or understand based on the industry and company they're coming from.

JACOB: Where do you think those misperceptions come from? You touched on a little bit, but why? Is it just that our brains are so full that we see one tweet from somebody and we just attach that to that person because we don't have enough energy to learn more, or?

ANNE: I think there's some of that. I think there's also, some of it is how the human brain works and it tries to oversimplify things. I also think it also comes from there is often a fear of asking too many questions. Especially if you're not in an environment that fosters a culture of trust and safety and there can be a fear of asking, “I forgot. Can you please just explain to me what it is your responsibilities are and what it is you do?”

It also gets really tricky when, because every organization does this to at least a few people, somebody starts filling gaps for things that they see missing in the organization. That's not their job, but they start doing it and then that person becomes auto-enrolled and being the person responsible for that thing. They might be, “Oh, that person's a frontend.” Their title might be frontend developer, or frontend engineer, but let's say that person started doing wireframes because they couldn't get enough of a UX designer’s time. So they started doing that and started getting really good at. The company started saying like, “Okay, well that person's on the project so that they could handle wireframes,” and then it becomes a thing where that person does talk about UX things. But the perception is that person's not a developer, that person's a UX person and people not actually ask them questions.

Sometimes organizations not doing the right thing, sometimes it's because organizations can't afford to hire somebody, especially when you're talking about startups. Especially once you get into bigger organizations, sometimes they choose not to hire somebody else. Somebody starts trying to fill the gaps because they are the type of person where they cannot stand to see, “Okay. So we're just going to sit here and be blocked, or be yelled at, or something because nobody wanted to even just do a simple mockup in PowerPoint?”

Those are things where organizations also allowing for ill-defined roles and letting people be a catchall also creates that problem where people perceive you as one thing and in reality, well technically, this is your role and now people are saying, “Well, that person is not involved, but when I worked with them, they were doing wireframes.”

It’s really a little bit organizational problem, also how our brains work, and also just the nature of people actually [chuckles] trying to be proactive and that sort of thing. Also, we said that lack of safety for people to just clarify what it is people do. Especially if you're working with a lot of different teams within your organization constantly, you might be dealing with a lot of people where you're like, “I know this person is on that team and that they're responsible for getting this from me, but I actually have no idea what the context of their role is outside of my relationship with them.”

CASEY: Sometimes I end up making a spreadsheet where I put it all the responsibilities and rows and we see which ones are filled, or not and who's doing all of the stuff in the middle. That's the best visualization I've seen is a spreadsheet for it. I wish there were more, or easier ways that more people could do that because it's really powerful. Once you see it, it's glaringly obvious it's happening.

ANNE: Yeah, absolutely. And I also think one of the dangers, though is people assuming, “Oh, well, because we're just adding copy to this design, that doesn't count as design work,” or we're assuming the PM, or the frontend person can handle that design work. But when we look at all of this persons over allocated, are they really going to do the best job to make sure that yes, this is the right place for the copy, this is how it works? Because even if we're talking like, “Oh, we just need to add one line of copy.” Okay. Cognitively, what does that do to the customer? Is somebody looking at the page holistically and thinking about it? And if you have somebody else, even if it's a small ask, who has a bazillion other things on their plate covering it, we can say, “Yeah, this is under this person.” But I think also, leadership needs to think about, “Okay, how have we resourced that person? Is that person really going to even be able to do that small task that we perceived because we don't need to fill in that design part of the sheet because it's something so small?” But I think that also comes from people not understanding the full value that some of these roles really provide outside of they produce a deliverable.

There's a lot of stuff where I'm like, “You really need somebody’s time for them to even consult on your team and not even bringing in an outside consultant, just somebody who maybe isn't allocated to your team.” So you would just come in and consult and be like, “Yeah, that's great,” or “Wow! You added that line. Your page was already – now it’s the cognitive load on that person is going to be this.” They're not going to read any of this and you're going to have a bunch of customers calling you, complaining. When you have somebody who basically has to do a drive by, yes, or no, that looks okay. You're not going to get the same service.

JACOB: On the other end of that, I'm a backend engineer and I think in a lot of places, I don't think in my company, but I think in a lot of companies, there's been an overcompensation of saying, “We have to really protect engineer's time. We have to really protect their focus. We shouldn't have any too many meetings.” I've never liked that, the typical engineer that they get a ticket and there's something that's not completely clear about what they're supposed to do and they just throw it back to the PM immediately.

That sort of culture has always just drove me nuts where it's like, “Sure, maybe we traditionally think of the PM's job maybe convene people, perform glue work.” If it's just this small, or medium question, why don't I do that?” Why don't I open a conversation and include my PM, but also talk to the other people that we need to get a question answered from so then I can unblock myself? I think there are some roles that necessarily have to protect “this is what I do.” I think there's other roles that are too protective of I only do this and could maybe stand to go outside their boundaries a little bit.

ANNE: I agree.

[laughter]

So much and I am very much a supporter of everybody owns the product. Yes, you have a product manager. Do they have certain expectations with their role about how they manage that ownership? Yes. Does that mean that your developers are just there to do a bunch of tickets and never provide product type of feedback? No. I really think you get better results, better products when everybody is able to have ownership over it. I think it sometimes gets into this Steve Jobs syndrome where you're like, “I am the genius of the team. I was hired to be the Steve Jobs of the team and I just tell everybody what to do.” Oftentimes, that results in a lot of crap and also it creates a lot of inefficiencies; the PM becomes the bottleneck, other things.

If you're really empowering your team and you're saying, “I led a testing and experimentation team for over a year and every Friday, we would go through the data.” My team would go through the data of all the experiments together because I'm like, ‘What is the point of them doing all this work to code up this experiment and then they just find out did it win, or lose?” They don't actually learn anything about what about the customer's behavior changed? Why do we think it changed? What problems do we think were in this? What do we iterate on this? And it really helps them not only have more ownership over the work that they did, it helped them be able to say, “Actually, I have this idea to iterate on this. I am not the person that wants to do everyone's job. I cannot come up with all the ideas in the universe.”

People come up with things where I'm like, “Wow, I really didn't think about we could iterate it on this way because of this information.” I really think that's also a big responsibility of PMs and other collaborative roles is to empower people to actually also have product ownership and I think there were days where the developer just does work and that's it, and don't ask questions you don't understand like what's going on.

But one of the jobs I joined years and years ago, a relationship that was between the development team and the design team was incredibly toxic, which actually coincidentally enough was also a thing where it was like a team based in New York with a team that was based outside the US. They would basically do a bunch of designs and send over a big Adobe file, I think an email with no layers, or anything in it to this development team and say, “Cool. Let us know if you have questions,” and the development team would work on it and then say, “Hey, we finished building it.” And then design would say, “Holy crap, this is terrible.” Like, “What is this?”

When I first joined, I was like – they really don't get along, first and foremost and number two, why are these things happening? I started talking to different members of each team to understand what's going on here and a lot of it was, there was literally no process for collaboration. It was no one talked to the developers during the requirements gathering, or during the design phase. So designers would just design whatever, without anybody there to give feedback to like, “If you do this, it's actually going to make us, have to do this call and it's going to add this many seconds onto the page and you're probably going to have a lot of people leave.” There was none of that kind of feedback loop.

The assumption was whatever we design can be done and the developers had feedback where they said, “We have tried to ask questions in the past upfront when somebody finally hands this off.” Oftentimes, it feels like people are speeding through trying to answer the questions, that people don't understand the question, or don't think it's not obvious what this is and they'll ask questions and they're like, “We sometimes get answers back that don't make sense to us and when we try to ask more clarifying questions, there's annoyance, dismissal.” So they basically said it is actually faster for us to just not ask any questions, build what we think needs to be built, and then just get all the feedback at the end than it is to try to ask questions throughout.

The fascinating thing about this organization, it wasn't the developers and it wasn't the designers, but it was like, leadership was definitely scared of Agile for some reason. I suggested maybe we should use some Agile methodologies and I got a massive amount of pushback [chuckles] that said, “We don't do Agile here.” I was like, “Okay,” and I instead decided to make some suggestions.

I was like, “Would people be okay if maybe three times a week, we just had a 15-minute meeting where we talk about what's going on in design and development and anybody else who needs to be involved can just join for 15 minutes.” And people said, “Well, yeah. That sounds like it's okay. No problem,” and I was like, “Okay, cool,” and I was like, “And maybe we could plan out the work that we intend to do in two-week increments and we could have a meeting towards the beginning of that two-week thing where we plan out together what's going to happen,” and people were like, “That sounds good. I like that. That sounds nice.” I was like, “As needed, at the end of these two-week things, we could talk about what went well, what didn't go well,” and people said, “Yeah, that sounds fine. Cool. We'll do that.”

The first time I implemented this on a project at that company, the designer at the end came to me and said, “This is the first time I've been able to use anything we built in my portfolio” because what actually got built was actually what the designers intended.

The thing is that there were things that the client said, “I want to change this in design,” and then the developers were like, “Actually, here's a problem and we could do this, but this is what's going to happen,” and the designer was like, “My special animation is not going to work. That was the whole point.” Like, “Why can't we do this? It should be super simple,” and they were like, “Well, you have to use this weird, special technology for this specific type of animation you want to do,” but having that conversation in the moment.

And I think they also needed to facilitate and maybe understood tech a little bit more than in that specific design team—there's some design teams that are much more tech savvy. Help them understand you can have something that looks like animation that doesn't use any special technologies other than what we would use for a standard website here and that you're not going to have to worry about knowledge transfer if somebody leaves, you're not going to have to worry about does anybody else other than this one developer know how any of this works, and also, it's going to be really easy to update every time there's a content change, which we know happens for this client pretty much every three to four months.

And that was something where it was like the designer was like, “I'm sad that some of the beautiful sparkles and things around the soap and stuff aren't going to be as flowing as I had anticipated,” but she was a lot happier than had the development team just decided well, we can't do that so now it's a static image. We basically implemented something where it ended up being this carousel and we're just like, “Just give us these images so that when they go through the carousel, it looks like this animation is happening.” Pretty much like when you could draw things in a flipbook and make it look like something's moving. Basically, the website version of that, which is much easier to maintain, much easier to update the content. It was just really fascinating because there was such this animosity and almost hate between the design and the development teams, but it was also like your bridges of communication are completely broken and nobody wants to change.

One team is like, “It's all this team's fault.” Other team is like, “It's all this other team's fault.” But also from a company level, they also previously didn't actually have someone in that role to help facilitate either and they were also definitely scared of trying a different process. They were scared of Agile when in reality, they actually had no problem with Agile. I think they just were scared that I don't know what was going to change their whole company process and I was like, “Just because somebody uses it one bubble isn't going to bring the whole company down,” and in fact, it worked out really well.

CASEY: I love that story. Yeah, small steps forward. You can make this incremental change to your team you're on. Anyone can do this on any level. You just might have to disguise it and do it very small. One step at a time.

ANNE: Sneaky Agile. Secret Agile.

CASEY: Yeah, secret Agile

ANNE: I’m going to brand it. I guess, I can't brand it because Agile is already trademarked. [chuckles] There'll be like an off-brand secret Agile.

CASEY: Early in my career as a frontend developer, I suggested we could do a design this way in one day, or this way that you want in one month and after I talked to everyone involved, they agreed two developers times four weeks times 40 hours was worth it for this. But I absolutely don't think it was. I think the designer didn't have 30 minutes to talk to us. That's a different cause here. But that happens, too. 30 minutes of a designer's time could have saved. Imagine the amount of money that was. Ooh. [chuckles]

ANNE: Yeah, and I think it goes back to what we were saying where it's like allowing everyone to have product ownership and if you're gatekeeping like, “Oh, we can't afford to have 30 minutes of that person's time,” or “We don't want the developer thinking about those things.” It actually takes longer and it actually results in less good product.

CASEY: Yeah. I visualized turbulence like if there's stuff going smoothly, it's just going. Otherwise, it's looping around, bubbling, and oh, all that wasted energy.

JACOB: I'm not a manager, but I've always felt like it would be better to, like you said, empower people to do what they need to get things done, even if they don't do so in the most efficient way, because then they at least know that they're empowered to do it. People are going to figure out and iterate on those fluid ways of navigating the organization to get what they need and you have to experiment to do that.

ANNE: Yeah. I think that's really a part of a culture of learning. People say they want a culture of learning and they're like, “Oh, here's a stipend. Go take this class.” But if you don't get a chance to learn it in your organization and try to practice it, it's all theoretical. Not saying theory isn't good, but it's the difference between, I don't know, I'll just say, I studied engineering in college. It's the difference between when you're studying engineering versus when you actually get out into the real world and work in a real environment. It's very different. You learn things, but there's things you have to adjust based on what is reality. Everything in theory tends to work, but that's in theory. Once you hit the real world, there are certain things where you have to adjust based on the situation and the context.

CASEY: Totally. They apply it. It’s like theoretical versus applied and you need to apply it. Hands-on workshops! But even better than that, having people on the team able to help support and coach each other.

ANNE: Yeah. I love that. I think that's something that doesn't happen enough is connecting people where it's like you want so-and-so to get stronger at this, this other person's really good at that, and that person needs to get better than this. Like, those are things where I don't think that happens enough.

I actually had a thing that worked today where somebody on our data team was like, “I was told to learn more things about product management” because they're like, “That's where a lot of this –” not that there's trying to become a product manager, but they're like, “It's going to help.” They're like, “It's supposed to help my career long-term to really be able to think about some of this data that I'm using, manipulate” I don’t want to say manipulating, but working with and thinking about it in a, I would say more so like customer way. I'll say more customer way because product can mean a lot of things.

My thing is unlike I'm a product manager, I've taken data science classes, I know just enough SQL to be, I want to say dangerous, but whatever the level below dangerous is and that's the thing is that there's things where I'm like, “Do I do those things day-to-day?” No, I don't. I look at some Google Analytics reports, I look at Tableau, I use a number of things, but talking to someone who actually knows how this works and does the work in this organization is going to help. And we were like, “Yeah. So we should set up time to regularly exchange knowledge, basically do a brain exchange so that I can learn more about this type of thing, data and you can learn more about product and we both benefit.”

ARTY: Maybe we need to change how we frame those conversations as to what we're here to do when we have these interactions generally. Because a lot of the times when things are framed in terms of oh, well, it's going to be a waste of their time. We don't want to infringe on their thoughts when they're supposed to be focused on these other things that framing that value proposition for everyone with respect to over the long-term, we're here to learn together and learn from one another. Even if during that time, what we get is a picture in her head of what this other person's context is like, such that over our careers down the road, we'll have a better picture in her head of what these other people's contexts are like. That has long-term value that far exceeds the cost of 15 minutes.

But if we don't frame things that way and we frame it as this disruptive activity that only has this short-term potential gain like we were talking about at the beginning of how we frame these relationships that we have, how we frame these conversations, those few minutes that are involved in that initial relationship set up create this snowball of effects over the long-term.

If we make an effort to think about how we want each of those relationships to go, if we think about what the value proposition is from a long-term perspective, and we make that the point, we're on the same team, I think that's the stuff that makes all the difference.

CASEY: I like this framing for you and the person you're talking to. Hopefully, the framing is there on your team. Hopefully, it's in the whole org. Hopefully, all the leaders have it. But if the framing doesn't sound palatable on some level, I see that happen a lot. It's like, we know this is good long-term, we know you and I, even our team, maybe the bubble, it breaks down somewhere. A lot of places, most places, I think.

ANNE: Yeah. I think it can break down for a number of reasons. One is again, trust and safety. It's really interesting, I saw someone on Twitter talking about this specifically for product managers but obviously, it can exist outside of that, where they said, “Once people get to a certain level in their product management career, they notice that there's a lot less learning, even product people do between each other in an organization.” I think some of it is certain environments are hyper competitive and people don't want to seem like, “Oh, they don't know that,” or “They didn't think of that.”

Again, I think some of it goes to this idea that—and not saying everybody believes this—but the product manager is supposed to be this genius like Steve Jobs and you're supposed to have all the knowledge and all the ideas and not everyone thinks that. But I think some organizations may people feel like scared of having that kind of exchange with somebody else in my discipline.

And then I think some of it also can be companies where they stretch people really thin. They're like, “I know this is my career. I have my little bubble, but I have no energy, or interest in going outside my bubble for that kind of thing.” It's interesting because I think a lot of these things – some of it is individuals, but I also think a lot of these things are different causes from a culture standpoint that leadership could shift.

Because at the end of the day, if you're exhausted, do you want to add one more meeting to your calendar? Do you want to do another thing if you feel like you're already doing a lot right now and you're like, “Oh, I should do this, but I'm tired”? Also, there's that again, sometimes it's imposter syndrome, or other things that make people feel like in this company, I don't feel safe going to somebody else and being like, “I don't actually know this. Can we talk more about it?”

CASEY: Yeah. A lot of companies, there's no headroom. There's negative headroom. You're already over overbooked in every way. Asking anything of that in that environment is a lot.

ANNE: Yeah.

CASEY: I love thinking on the organizational level. Glad you two don't mind going there. Jacob dropped off. It's really fun for me.

I'm just looking at the time here. So with reflections, we usually go in a circle. It's usually the panelists first and then we have guests give your own reflections. It can be a thing that was interesting, or memorable, something that will stick with you after the episode.

ARTY: So the thing that stands out for me, I think about where we started this conversation with superpowers, empathy, and collaboration. When you were talking about growing up and being an outsider where things were really challenging, but at the same time, you developed this ability to understand what it was like to be on that other side of the wall. Such that now you're significantly more aware of what's going on in other people's heads and how they're perceiving these relationships that are going on. It's like being able to have eyes of what it feels like to be on the other side of that wall.

We talked about contrast and these contrasting experiences from that to where in your home environment, you were loved and accepted as you are, and then in your journey and growth, you mentioned this desire for congruence to be able to be yourself in these different environments and why that was hard at the same time.

As you were growing in that way, that congruence became your self-actualization of being able to find this strength in yourself, this belief and trusting in your own voice so that you could stand up when someone needed to stand up. So that you could go against the grain and be solid within yourself. To be able to do things and step into these uncomfortable situations. To create change. To create culture. To shape leadership. To shape these handfuls of super important, critical conversations that frame the entire relationship moving forward from contrast to congruence and just seeing you blossom in that, seeing what you've been able to do, what you've been able to bring to the table as a human being, as part of the team was really amazing.

Your journey of how you got there just says so much about who you are and I hope listeners will be inspired of just really seeing how important it is to be able to trust yourself in those ways, to be able to find that strength and solidity within yourself so you can be someone that helps to contribute to moving things in a positive direction.

CASEY: Oh, it's beautiful.

So my reflection is a little on the coaching and DEI side. I said it earlier, too. I was very excited about this idea. I used to think DEI was not something I could help with because I'm a white man. What am I going to say to anything?

But I do have the clear lens that gives me some kind of minority perspective that’s really valuable and white people, especially conservative white men, are more likely to listen to me, it's my power. So I'd like to wield that and do things like skills training, workshops, and coaching including for diversity, equity, and inclusion. But I never thought about specifically coaching people on DEI, making that content. I don't know why, because I don't know. All the formats of everything else that I do, but it was just like a light bulb went off in my head when you said it's like therapy, it could be talking through problems.

So I want to think about that more. Maybe we can talk another time about that. What would it look like? What would make it look successful? What would be helpful? Who could ever pay for it? Even companies, I hope. How do we really help people change and grow, the people who are motivated to? That's what I'll be thinking about after this episode.

ANNE: Yeah, I think that would be wonderful. I think mine is more of like a final message, really. It's a reflection, but it's more of, I think reflections of how am I feeling than necessarily a specific topic.

It is related, but it's been a wild nearly 2 years in this pandemic and I really think the future of where we need to go as a society, which also being in a tech driven society, is very important for people in technology to consider is how do you bring what you love to the table? I'm not asking you to be exploited by your company—and sorry, this is going to be very hippy-sounding—but if more of us showed up with love in terms of how we build our products.

Not just like, “Oh, I really love just building the product,” but also, love for the people who we're building it for and the people who will be impacted, but maybe we're not building it for. Showing up with love in terms of how we're treating ourselves that day and how we can empower others to be their best selves in our bubble, or when we have influence beyond our bubble, and really reflecting how you can show up in some of these environments where you can show up with more love and create safe and trusting environments. Because I truly believe just because it's digital doesn't mean that what you put in it doesn't impact the outcome.

If you put trash inside of a sausage, it's going to be trash in a sausage casing. If you put all your negative energy [chuckles] and disdain for what you're doing, or your team, or you just sort of like, “I don't care.” There's going to be things where obviously, you're going to work jobs just for a paycheck, but figuring out in which ways can you show up with love in that environment and whatever that means to you. That's my final thought for the day.

CASEY: I love it! Thank you so much, Anne for joining us here.

ANNE: Yeah, thank you. It's been such a pleasure to talk to you and talk to you about these things. You said earlier in our conversation, “It's great hearing these things from somebody else's mouth reflected back,” and that's how I really feel about this where I'm very passionate about these topics and being able to talk to other people and hear them value that as well means so much.

CASEY: Yeah. You're not alone. You're not crazy. You're not having ridiculous thoughts. You see somethings very clearly and you could enunciate them, articulate them, share them. I’m so glad we got to do that together today. All of us!

ANNE: Yes, yes. I’m incredibly grateful for this. It is such a pleasure.

ARTY: Well, thank you again.

Special Guest: Anne Griffin.

Sponsored By:

• Test Double: Software is broken, but it can be fixed. Test Double’s superpower is improving how the world builds software by building *both* great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater.

Support Greater Than Code

01:17 - Danielle’s Superpower: Empathy & Communication

01:56 - Going From the Hospitality Industry => Tech

04:58 - Education Technology (EdTech)

07:18 - Anthropology + Tech / Working With People

10:25 - Making Education Fun + Inclusive

16:18 - Transitioning Into Tech

27:57 - Resources

32:39 - @CodeSchoolQA / twitch.tv/thejonanshow

34:08 - The Streaming Revolution

39:45 - Making Tech Safe, Secure, and Protected

44:03 - Advice For New Devs: Work on Technical Things Sooner

Reflections:

Mandy: The secret in tech is that nobody knows what they’re doing!

Danielle: Ask questions and lean into community. Tech needs you.

Arty: Don’t be afraid to reach out to community members for help.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

ARTY: Hi, everyone. Welcome to Episode 254 of Greater Than Code. I am Arty Starr and I'm here with my fabulous co-host, Mandy Moore.

MANDY: Hey, everyone! It's Mandy Moore and I'm here with our guest today, Danielle Thompson.

Danielle is a newly minted software engineer working in the education technology sphere of the nonprofit world, after making a major career change from working in hospitality and events for many years. As a code school graduate herself, she loves to help demystify tech for others with non-traditional backgrounds and works to open doors into tech with her friends at Code School Q&A, weekly on Wednesday nights at around 7:00 PM Pacific at twitch.tv/thejonanshow.

Outside of work, she can typically be found with a nose buried in a book, hanging out with her doggo, and making delicious craft beverages.

Welcome to the show, Danielle!

DANIELLE: Thanks so much for having me, Mandy and Arty!

MANDY: Awesome. It's great for you to be here. So before we get into the meat of our conversation, we always ask our guests the standard question of what is your superpower and how did you acquire it?

DANIELLE: Totally. I think that my superpower is a combination of empathy and communication. I think I came by both pretty naturally—popped right out of my mom having both, I'm assuming. But both have definitely been amplified over the years by all sorts of experiences and hardships and just keep working to make them even more of a superpower.

MANDY: That's really great.

So I want to know about before we dive into your experiences as a new developer, I wanted to know about how you came into technology from your career change in hospitality, because I did the same thing.

I was a waitress when my daughter was born 10 years ago and I was working for about a year before I was able to walk out. It was Mother’s Day, my boss was being a complete jerk to me, and I was making enough money at that point that I just said, “You know what? I don't need this. I quit,” and I started my career in tech full-time. So I'm curious about your journey as well.

DANIELLE: Yeah. Obviously, COVID has happened in the last couple of years and that was one of the major factors in me getting to this point of leaving hospitality and getting into tech. But I had already kind of been thinking about what comes next. I've been a manager for a few years and was trying to figure out how else I could grow and what new things I can learn and challenge myself with. And outside of ownership, which is a major headache, there wasn't really much that I could push further into, within hospitality.

So when COVID happened and I lost my job because I was working as an events and bar manager for a local catering company, it was pretty obvious that things were not going to be coming back for the hospitality industry anytime soon and I needed to figure something else out then. And so, I started looking into different returning to education opportunities because I actually have an anthropology degree, of all helpful things that I could have gotten a degree in.

But I found a code school in Portland, Oregon and jumped on that within a few months of COVID hitting to the full-time track and connected with a number of my cohort mates that we started doing the Code School Q&A on Twitch with the director of developer relations at New Relic and have been doing that for almost a year now and have officially made it in the industry as a software developer, too in the last few months. So you can do it, you can get into tech. [laughs]

It's pretty funny, too because the type of job that I ended up getting is in education and technology sphere and I actually had a job in ed tech about a decade ago when I was still in college and had a remote job working with some family friends that got me hooked up with their company. And here I am doing something a little bit more in-depth technically than I was doing a decade ago, but it's funny how things come full circle.

ARTY: Well, education in particular is something that also really needs some reinvention and innovation and with all the disruption, where do you see that area going? Just curious.

DANIELLE: Yeah, absolutely. I feel that a lot of the changes that we've seen in COVID with remote work being such a prominent thing now and people wanting more balanced, more time with their family, more time with their critters, more time just not being miserable and commutes and stuff. I think that that's going to have a really long-term effect on how education happens and trying to make education more quality as well.

I think it's really rad what the company I do works for. Our whole mission is to work to make education in America more equitable. So we do that by working very hard to work with experts in the curriculum sphere that ensure that our curriculum materials are as inclusive and culturally relevant as possible, that they are representative of a large and diverse group of people, and they even do a ton of anti-racism work as well and work to embed that within our internal and external culture, as well as the products that we create.

So I hope that our company will continue to grow and make changes in the education world in America in general, because I think what we're doing is really, really, really important.

ARTY: Definitely important and with all the change and stuff happening, I'm expecting some new and cool and exciting things that do make things better. One of the upsides of lots of disruption is it's an opportunity for us to sit back and rethink how things could be.

DANIELLE: Yeah.

ARTY: And one of the benefits of not being entrenched in the existing fields of the way things have been is it's also an opportunity to look at all the stuff we're doing with a fresh set of eyes from outside of that existing world and bring some new fresh insights to tech. Maybe my anthropology degree will come in handy in some different sorts of ways. I imagine some of those skills that you learned in that have some applicability in tech as well. Have you found your degree helpful in other ways?

DANIELLE: It's funny. I think I ended up using my anthropology degree as a bartender far more than I ever would have as an actual anthropologist. That whole study of humans thing is something that is directly translatable to working with people no matter what field you're in. I feel that both my anthropology degree and my many years of hospitality experience have all led to a specific skillset that is very different from a lot of people that come into tech with more traditional backgrounds especially folks that go to college and get computer science degrees, and then they go to the tech industry and that's all they've ever known.

I've known so many other experiences outside of that and my ability to think about what other people need and want, to be able to respond to that, and embed that in all of the work that I do as an engineer to really be thinking about the user and the people that are interacting with whatever I'm building and even just thinking about working on a team and how I have so many communication skills built up from what I've been doing for work in hospitality for many years. I think that it definitely gives me a very specific and unique way of moving through the world and way of being an engineer as well.

That anthropologist hat definitely comes into play sometimes thinking about like, “Oh, like how do all of these dots connect?” and like, “How does this change over time and how do you see people like doing things differently now?” It's a definitely a fun lens to carry with me.

MANDY: Yeah. Having been done hospitality, I'm just shaking my head because –

[laughter]

I know I've brought so many skills from being in that world for 10, 15 years at one point.

DANIELLE: Yeah.

MANDY: Just the way you talk to people and interact with teams and anticipate what other people need before they even know what they need, that's definitely a skill.

DANIELLE: Yeah, definitely. I think that whole anticipating needs thing, too, it's like it can be both an internal and external benefit where you can think both about who you're building products for and also who you're building products with, and how best to communicate within teams, especially having management experience.

That is definitely at the forefront of my brain a lot of the time, but then also thinking about like, “How can I make the best experience for somebody else that's actually going to be using this? How can I make this easy and intuitive and fun?” Especially within education, have to make sure that things are fun and interesting targeting kids that are K-12; it has to be meaningful, impactful, interesting, and engaging.

MANDY: So how do you do that? What are some ways that you and your company make education fun for young kids?

DANIELLE: I think I'm still figuring that out. We have many curriculum products that I'm still just touching for the first time, or haven't even looked at it yet and so, there's lots of fun, new things to discover.

But I think the types of people that we bring on to work at my company, they're all experts in their field and renowned for the work that they do and so, I think that the quality of people that we bring into work with us and the kind of commitment that they have to work towards making education better and more inclusive, that is incredibly important. And how they also do an immense amount of work to make not just inclusivity a part of the major formula, but also that they work to make things culturally relevant. So like, thinking about how to tell stories to kids that actually means something to them today.

I don't know, a weird example is thinking about some outdated curriculum that's talking about using a landline for a phone, or something. Kids are like, ‘What's that?” Actually integrating modern things like cell phones and things like that into the curriculum where kids actually touch that and use that every single day so it means something to them. Whereas, outdated curriculum that is just some story to them. It doesn't have tangible meaning. Being able to bring that into materials is really important to keeping things engaging and also, relevant and fun.

MANDY: So the time when little Tommy was walking to the Xerox machine.

DANIELLE: [chuckles] Yes, yes.

MANDY: Somebody brought up a Xerox machine the other day.

DANIELLE: Oh wow.

MANDY: My goodness.

DANIELLE: [laughs] Yeah, definitely. But I think it's just a constant looking at how we do things, and making improvements and making real connection with the people that are actually using our products to use. That both means working with teachers and getting a better understanding of what is helpful to them, what makes things easier for them, what helps them bring better quality curriculum to their classrooms?

But then I think it's also connecting more directly with those kids that are engaging with our curriculum, too and figuring out what works and doesn't work for as many parties as possible. I think that's the anthropologist hat coming on again like, how can we bring as many people to the table as possible on the expert side, on the academic side, on the teacher side, on the student side? And even working to bring families to the table, too and looking at how families interact and not just parents, because it's really important to know that kids don't have just parents that are taking care of them—sometimes it's grandparents, sometimes it’s foster families. And really thinking about a wider range of who is around these kids, and how to get them onboard and make things easy for them to interact.

ARTY: It seems like getting into tech and these new tech skills that you've learned are also relevant in figuring out how to teach kids tech because we've got this new generation of kids coming into the world and learning how to code becomes more like learning how to read and write is fundamental skills move forward in the future. Are there ways that some of the things that you've learned through your own tech experiences you can see application for in education?

DANIELLE: Absolutely. From what I've been seeing, I feel like there are a lot more resources out there for teaching kids how to code and teaching them more things about technology. I think that's amazing and should totally keep happening. I think having been a bit more focused on adults in my own outreach for helping people find their ways into tech I might be a bit more acquainted with reaching out to those folks. But I'm sure that that intersection of being in education for K-12 students and this passion that I have of helping to find their way into tech, or build more technical skills because they are skills that are so transferable in many industries. I'm in education, but I have a technical job.

So there's lots of ways that those technical skills can be incredibly valuable and frankly, life-changing. The amount of opportunity and even just financial stability that can be found within tech is one of the main reasons that brought me to this industry and has really been a life-changing opportunity. It has opened so many doors already and I'm just like three months into my first developer job.

Even before I was ever actually officially an engineer, I was able to find community and able to find an outlet for helping others and outreach to immediately turn around and hold a handout to try to help others make their way into tech as well. I hope to continue doing that work in more meaningful and impactful ways over time, and have wider and wider reach as well.

ARTY: You had mentioned earlier about some of the difficulties of getting into tech and some of the challenges with finding resources and things that you were specifically missing when you actually showed up on the job. I'm curious, what was your experience like going through coding bootcamp and what were some of the gaps that you experienced that once you got on the job, you were like, “Oh, I didn't learn that.”

DANIELLE: Yeah, definitely. Coding bootcamp was an incredibly grueling experience for me personally. I was on a full-time track six-month program and [chuckles] not having much technical experience whatsoever outside of editing my Myspace profile back when that was a thing and having [laughs] about a decade ago doing some basic HTML, CSS editing and maintenance for the company that I worked for an ed tech originally. That was what I was working with when I started coding bootcamp. So it was a real hard learning curve and a very fast-paced program for me to just dive into headfirst.

My poor partner was like, “I basically didn't see you for six months. You were just a basement dweller at your computer constantly.” I would literally get out of bed, roll myself downstairs, get to my computer with a cup of tea in hand, and I would stay there until easily 10:00, 11:00, 12:00, 1:00 every night just trying to keep my head above water.

But a few months in, things started to click and I wasn't fighting with all of these computer puzzles [chuckles] trying to do this. Like, I always feel like learning coding languages is a combination of algebra and a foreign language. So at a certain point, my brain just started getting into that better and things started making sense. That was a very exciting moment where I got much less miserable [chuckles] in my code school experience and in the pace at which I had to move to keep my grades up and everything.

But the gap in between finishing code school and actually getting that first job is also another often-grueling process. There's so many jobs open in the tech industry, but basically, it's mid-level and above. It's like, I think two-thirds of the industry positions that are available are for mid to senior roles versus one-third of roles that are for junior associates. That is a big struggle, especially if you're not able to lean into community and building real connections, just sending applications out to the ether and never even hearing a peep back from companies. I think that whole experience, it's really hard for yourself esteem, especially having put in many months around the clock of work towards this new career that you've been told that you can get, that you can achieve. It's almost as much as a process getting that first developer job as it is to actually build those tech skills.

I think one thing that is so important to stress in that in-between time is to lean into community, to connect with as many people as you can that are already in tech, even if they don't exactly have a developer job. Like, talk to anybody that will let you talk to them—talk to people in QA, talk to developers, talk to managers, talk to project managers. That was one of the things that I felt I needed to do early on in my coding experience to really have a better understanding of what was even an option for me of getting into tech and what could all these different jobs look like, and then making that transition to actually getting the first job. Yay, hooray for first jobs and being employed again.

But I think one of the things that has been most striking in that change for me is going from this incredibly grueling pace. 8:00 in the morning, or so until 10:00 plus at night, non-stop coding for the most part, and then going to a 9:00 to 5:00 job where I can also make my own hours and I can take appointments as I need to. Like, I can go and get a haircut if that's something on my schedule and it's cool. As long as I'm getting my work done and showing up and contributing to my team, things are fine.

So that transition of like, “Wait, I don't have to be at my computer a 1,000% of the time?” [laughs] and the pace at which you learn things, too is just much slower because you can have balance. That transition of feeling like you're not doing enough because you're so used to this hefty schedule, that's been a major transition for me.

I think also coming from hospitality, too where you have to be there in person and oftentimes, somebody is going to call out sick at least every other week, or so. So you might be working like a shift and a half, or a double. There isn't a lot of balance in the service industry, especially now with COVID adding so many extra layers of complication to how that job works. Being able to just be like, “I need to go make a doctor's appointment,” and can just do that. It's like, “Okay, cool. Just put it on the calendar. You don't really need to tell me. As long as it's on the calendar, that's great.” [laughs] That transition has also been very strange.

And I think maybe just the trauma of [chuckles] working in hospitality and not being able to just be a human sometimes and now all of a sudden, I'm like, “Oh, I'm a human and that's allowed? Okay.” Still have to check in with my boss frequently about like, “You sure it's okay? You sure it's okay that I'm a human, right? Yeah.” [laughs]

MANDY: [chuckles] That was one of the things that I really loved coming into tech was the scheduling, open schedule, making my own hours.

DANIELLE: Yeah.

MANDY: And you're right, it was very strange at first. When I was waitressing, it was just always a go, go, go kind of thing and you had to be there, you had to be on, and if you didn't have tables, if you had time to lean, you had time to clean.

DANIELLE: [chuckles] Yeah. Always be closing. You know, ABCs. [laughs]

MANDY: So yeah, sometimes I still find myself on a random Thursday. I'll have my work done and I'll just be sitting here and I'm like, “Why are you sitting at your computer? Go do something, then check it and if there's stuff there –” Like, you don't have to have your ass in the seat from 9:00 to 5:00, or 8:00 to 4:00. You don't have to sit here for 8 hours and just stare at your inbox waiting for work. It's totally asynchronous and it's totally okay. I find myself having to give myself permission to leave my desk and just go and do something and work that asynchronous schedule. So tech is a really big blessing when it comes to that.

DANIELLE: I totally agree. I think also, not being neurotypical myself, I have ADHD, and so, being able to actually allow my brain to work in the way that is best for how my brain just naturally operates. Like, I can sit at my desk and fidget constantly, and it's not going to bother anybody because I work from home, [chuckles] or I can shift between sitting and standing and sitting on my bed, or sitting on my stool and just move at my desk as much as I need to. I can also step away and go clean some dishes if that's what's making noise in my brain. I can go and take my dog on a walk and get some fresh air.

That whole shift of having balance and being able to be empowered to advocate for what I need and how I learn and people are like, “Yeah, cool. Let's do that.” I think that's also very much a part of the company that I work for and the ethos that we have, which is all about making education better. So why wouldn't that also translate to the staff and how can we help you learn? It's such a wonderful thing to be a part of a team that's super invested in how I learn and helping me learn.

I think another thing that was a big, strange thing about my transition into tech was I ended up getting a junior engineer role in a tech stack that I hadn't worked with, which is pretty common from what I've heard from mid engineer on. Because once you have some of the foundational building blocks of a handful of programming languages and some of those computer science foundations, you can pick up most programming languages. But it's not so common as a junior engineer to get that opportunity to work with a full tech stack that you haven't really worked with before. So that was another big transition like, “All right, you trust me time to figure this out.”

ARTY: So it sounds like you walked into another big learning curve with your new job, too. It sounds like you were also in a much more supportive culture environment with respect to learning and things, too. What was the ramp-up experience like at your new company?

DANIELLE: In some ways, I still kind of feel like I'm in ramp-up mode. I'm about three months in. But because we have so much of our product that is built around very specific curriculum components, that has very specific contextual knowledge, it's just going to be a process to figure out which projects have what information and have certain numbers of records, and are tied to certain standards that are required in different states and for common core versus for some of the states that we work with, what that looks like. But figuring out a whole new tech stack was and continues to be a very interesting challenge. I have to remind myself when I have gaps in my knowledge that it's actually to switch gears back into learning mode, that that is a thing that's supported and encouraged even.

I even have little sticky notes on my desk that say, “Start with what you know, not what you don't know,” and that tension of when I reached the end of what I know and then going and finding maybe not necessarily the right, or correct resources, because there's so much out there that's good. That can be helpful. I think it's more about finding something that does work with how my brain learns things and being cognizant of how I learn. But also, remembering to dig into that fate that is being a developer, which is constant learning and ever-growing evolution of how we do things, and what things we do within the sphere of the developer. So I've signed up for perpetual learning and that's pretty great.

MANDY: What are your favorite resources that you used and continue to use as you're still learning, and finding community, and things like that?

DANIELLE: Yeah. I have certainly continued to lean on the curriculum for my school. It's online and it's free and that's rad. It's learnhowtoprogram.com. It's all put on online from Epicodus in the Portland area. Anybody can access it and that's wonderful. I'm a big fan of really great resources being available for free and making that more accessible. So continuing to use platforms that have that kind of ethos in mind is pretty great in my opinion.

Reading the documentation is another great way to keep learning what you need to learn and sometimes documentation can be kind of dry, especially as a new developer, you don't always know what exactly it is that you're looking for. So being able to parse through documentation and figure out what's most important, but then also filling in the gaps of some of the things that you don't yet know, or understand with YouTube videos, or deeper dives into like, what does this one specific term mean? I don't know, let's go find out and plugging in some of those gaps is really helpful.

I think figuring out how you learn, too whether that be very hands-on, whether that be visually, whether that be with audio, getting lots of repetition in; it's super helpful to lean into whatever works best for your brain for learning.

I think perhaps even more important than digging into resources that are online is lean into community. I really can't say it enough, build community. If you work with Ruby, like I work with Ruby, build community within the Ruby community. Connect to people online, get on Twitter, connect to tech Twitter, follow different people that work with the languages and the tech stack that you work with, and join places like The Virtual Coffee and other really rad developer spaces that are meant to help you find the answers that you need and to maybe do it in a way that's a little less arduous because you're with people that are like, “Yes, happy helper.” Like, “How can I make things easier for you?” It seems like a much easier way to go through tech when you can do it with others and remember, that there are human resources out there for you, too.

MANDY: You also had mentioned that you were connecting with folks over Twitch.

DANIELLE: Yeah.

MANDY: Can you tell us a little more about that?

DANIELLE: Absolutely. So a friend of mine in my Epicodus cohort, she reached out to the director of developer relations that had done a lunchtime chat with us at one point and she was like, “I don't know what I'm doing. I am so stressed out. I don't know if I can actually finish this school and let alone finish school, but actually make it as a developer and I have questions. Do you have some time for some answers?” And he was like, “Yeah, do you want to actually do this online on Twitch? And how about you bring a couple of friends and let's just ask lots of questions and I'm going to record it?”

She reached out to me and another friend of mine and here we are many months later still answering questions online about how to get into tech and what even are some of these things that we're talking about technically, or let's look at other roles outside of just developer, or engineer, that you can get into.

So that has been an ongoing theme of how can I help others? How can I help provide community for people that might not have been as lucky as I have been to already have a preexisting community with many of my friends and my partner that were in tech? How can I help create that advantage for others and how can I help reach more people and help them understand what their options are and connect them to the people that need to know to get jobs?

I think Code School Q&A, we are super, super excited about open doors for people to whether that be better knowledge, whether that be real human connection; what's most important to us is just supporting people as they are making transitions into the industry like we've been doing over this last year and a half.

MANDY: So what is the Code School Q&A look like when you join? Walk me through it if I were to show up, what would I get?

DANIELLE: Absolutely. So there's generally four of us on the stream and we ask a handful of questions, whether that be from our own experiences of like, “Okay, I'm a developer now and I've got some questions about some of these transitions that I am experiencing.” But we also lean into the audience as well and see what kind of questions they have, whether that be folks that are still in code school, or folks that are thinking about maybe potentially going back to school, whether that be computer science in a university setting, or bootcamp, or even self-taught people. We even have a number of folks that are already in their careers, too that are there to reach out and chat and provide additional feedback and support.

So I really feel like it's a bunch of friends just getting together on Wednesdays and that group of friends just keeps building and expanding. It is very much like a support group, but it's also fun. Like, our first question of the day is what are you drinking and how are you doing? Because we all hang out and chat, and drink while we're talking about how to get into tech and definitely try to make it as fun as we can and crack jokes and interrupt one another and it's a good fun time, but helping people is what's most important.

MANDY: And this is all live? Unedited?

DANIELLE: All live. Unedited. Yes, yes, and 7:00 PM-ish AV is a whole beast in and of itself. I just had to set up a Twitch stream for the first time in this whole time of streaming over the last year. I've been writing my princess pass and just shown up [chuckles] for every Twitch stream and now I know how much goes into that. I still had probably another few hours of set up to get past just a minimum viable product of we need to be online on the interwebs and you need to be able to hear and see me. Got there, but it's a whole thing.

MANDY: Twitch is certainly interrupting the industry, I believe.

DANIELLE: [inaudible].

MANDY: Especially since the pandemic. All of a sudden everyone's on Twitch. We're doing conferences live, we're doing like – how do you feel about the whole Twitch revolution and how is it different from how people traditionally came and connected in tech?

DANIELLE: Yeah. Having been in events myself—that was part of what my role was within hospitality—I personally really love that there's now this whole new opportunity for connection. I think it also makes connection way more accessible because folks that were already living some kind of quarantine life because of autoimmune disorders, or disabilities, or whatever that looks like, they couldn't easily make it to those conferences and now they have a way to connect with those conferences because of hybrid events.

I think it's a really rad innovation that we're seeing and it's a really wonderful way to even just as an introvert. I'm like, “I don't have to leave my house to be able to see my friends and have a good time? Yes! I am super interested in this.” I can – [overtalk]

MANDY: [inaudible].

DANIELLE: Yeah. I can hang out with my dog and give him scritches whenever I want, and still see my friends and build community within tech. Heck yes. Very interested in this. I think that accessibility feature that it provides is just, it's really wonderful to know that more people can become a part of tech communities because there's now this whole online outlet for folks that couldn't otherwise afford a flight to get halfway across the country to make it to this conference, or couldn't afford to get in the conference. There's lots of ways that just makes things more accessible.

MANDY: Do you think it's going to continue much beyond the pandemic? Like, do you think when it's all over, we're just going to be like, “Oh, we're back to conferences,” or do you think this is going to continue to the streaming and the slack chats and the live Q&As and things like that. Do you think that's going to continue?

DANIELLE: I hope so and I think so. I think that even just from a business sense, you can tap into whole new markets by having this addition of hybrid events. You can reach a whole new subset of markets and I think quite frankly, it'd be kind of foolish to not take advantage of the new ways that we've figured out that we can still have meaningful and authentic community.

[chuckles] There's definitely a way to monetize that and I'm sure plenty of people out there doing it, but I think it's also given voice to people that couldn't previously access those spaces and now they're like, “Don't take this away. This is community. This is this is what I've built,” and I think people are going to be willing to fight for that and I think that companies will see the business benefit of continuing to do both.

ARTY: So anthropology question then. [laughs]

DANIELLE: Great.

ARTY: How do you think this will affect us as a society of connecting more virtually instead of in-person in that we're significantly more isolated now than we were before, too in terms of in-person connection? How do you think that's going to affect us?

DANIELLE: One of the first things that comes to mind is infrastructure has to change. I think that support for higher speed internet across the states across the world has become much more of a priority that is striking to people, especially thinking about kids having to figure out how to do online school. All of a sudden, when COVID first hit, some kids didn't have access to the internet, let alone a computer, or a tablet, or a phone that they could go to class and do their homework on.

So I think that we're going to be forced to make technology and the internet more accessible by building better infrastructure to support those things and I think it's only a matter of time before there is better social support for getting technology in the hands of kids, especially, but getting them devices. Like, I know there are a number of initiatives out there that are giving small grants and stuff for people to be able to get computers, or tablets, or whatever and I think that we're going to just keep seeing more of that. Hopefully, fingers crossed because it's super important to be able to keep connection moving and I think keep moving our society in the right direction.

ARTY: So do you have any concerns about that as well as how –? We all get plugged in and are affected and in not so good ways, too. On the flip side of that, where do you see things going?

DANIELLE: My partner is in InfoSec. He is a security person. So that's definitely my first thought like, how do we keep the things that are most important to us and that are now online? How do we keep those things secure and safe and protected? Figuring out how to fill the gaps that are inherent within the security industry right now of there's just not enough bodies to fill all the jobs and build all of the security that needs to be built and maintain those things.

That's going to be a whole new ball game that tech has to figure out and it's going to take a lot of manpower to make sure that we can protect people and protect the things that are most important to them, and even just protect those communities, too. Make sure that those communities can continue to thrive and also, be carefully moderated and curated so that there is safety for people to interact; that there is less bullying happening online, that there is less hate crimes that are being perpetuated online.

Creating safe spaces for people and providing agency for them online is a whole new ball game when we're not even really that great at doing so in real life, in-person. There are a lot of groups that are going to have to fight harder to be heard, to be seen, to feel safe, and I think that's just an ongoing thing that we need to work at being better at.

ARTY: So we need ways to improve the connectivity community stuff and then also, need ways as we do those things to create safety in our communities.

DANIELLE: Absolutely.

MANDY: Yeah, we just had a really great discussion with Eva PenzeyMoog about two episodes ago. She wrote the book Design for Safety and it was an excellent, excellent conversation about ways that as designers and engineers, we should be building our infrastructure safe from the beginning and not just going back – [overtalk]

DANIELLE: Yeah.

MANDY: And doing it after the fact, but realizing who the most vulnerable people are and protecting them from the get-go.

DANIELLE: Yeah, absolutely. I think that's actually something that my company works really hard to do while we're designing our curriculum products is designing from the most vulnerable within our communities and using that as a starting point for how we build things and how we continue to maintain them. Because if you can keep the folks that are most vulnerable in mind, more people are actually going to be allowed to be safe, allowed to have agency, and allowed to grow. It's a far more inclusive space when we can think about the folks that don't always have access, or don't always have safety, or don't always have agency and designing with those people in mind first.

MANDY: And that's how we'll end up filling all these empty seats right now that are available in tech – [overtalk]

DANIELLE: Exactly.

MANDY: Is by not eliminating these people, designing a safe environment from the start, and attracting different kinds of people into tech because tech needs more diversity.

DANIELLE: Tech needs more diversity. Yeah, absolutely and I think that's one of the reasons why I keep doing Code School Q&A is because I want to see more people that look like me in tech. I want to see more people that don't look like me in tech. I'm very excited to bring as many people to the table as possible because I think that's when we also get the most creative and innovative. When more tool sets are brought to the table, more diverse experiences are brought to the table, we build far more robust systems, products, and things just get better when we have more differences from which to pull and more experiences from which to learn.

MANDY: As we said in the beginning, you're a fairly new developer. So I wanted to ask you the question: what was one thing you wish you knew, that you know now, that you would have known back then? If you could give Danielle advice a year ago, what advice would that have been?

DANIELLE: I think that advice would have been to start actually working on technical things sooner; to start digging into the educational materials that were provided for me for free before I ever started school. I think that actually digging into those materials and having the courage to not just wait until I was in a classroom setting to be able to interact with coding languages and learning how to program, I would have had such a less fraught time getting through school and giving myself the opportunity to get a bit of a head start and more of a foundation before just diving in head first and hoping that I kept my head above water.

But I think also, again, leaning into community and not being afraid to ask for help, not being afraid to advocate for myself because it took me a good 2 and a half months before a really felt like I could speak up and say what I needed. That's 2 months of time that I could have been getting more of what I needed, getting more help learning faster and more efficiently, and just being less miserable in the early stages of learning and entirely new skillsets.

So don't be afraid to ask for help. Don't be afraid to advocate for yourself. I think especially as a woman coming into a technical space, there is some extra fears of not looking like I could do this, or not feeling like I belonged not knowing what I was doing. But the thing to remember was that nobody knew what they were doing; we were all figuring it out together in that school program. Being the one to be like, “Hold up, this is not making any sense to me. Can we start this over again? Can we dig into what's happening here?” Often times, other people were like, “Oh, I'm so grateful you said something because I also don't know what's going on.”

MANDY: Well, with that, I think that's an amazing thing to end on and we can move over to reflections, which I can go and start off with right away is that's the secret. Like, nobody knows what we're doing in tech.

DANIELLE: [laughs] Nobody knows, no. [laughs]

MANDY: Nobody knows.

DANIELLE: Nobody knows yet.

MANDY: That's the secret. Ask questions. Lean on your community. There are so many people out there. I know you mentioned tech Twitter, #techTwitter. There are so many nice amazing people that will have your back if you just put those questions out there and even say, “Hey, tech twitter, anybody free? Do you want to pair?” They'll be like, “Yeah, let's hop on for an hour, or two,” and especially right now is when people aren't really doing much again. [chuckles] People are out there. So again, it’s a secret. Nobody knows.

DANIELLE: [laughs] Yeah. I think I am totally on board with your reflections for the day lean into community and don't be afraid to ask questions.

I think it's so important to know that tech needs you. Whoever you are, tech needs you and whatever valuable skillset you bring to the table, whatever diverse experiences you bring to the table, it's needed. You need more people that aren't traditional and whatever that looks like. There is space and there is need for you.

I think come and ask your questions at Code School on Wednesdays. We need generally every Wednesday, 7:00 PM Pacific time. We are happy to answer your questions and help connect you to the people if we don't know answers because none of us totally know the right answer most of the time.

MANDY: And how can people do that work? What’s the URL?

DANIELLE: Yeah. Come visit us at twitch.tv/thejonanshow. We also have Code School Q&A is participating in Oktoberfest, too. So you can find us on GitHub by looking up the Oktoberfest hashtag tag and you can find us on Twitter at Code School Q&A as well.

MANDY: Awesome.

ARTY: I just wanted to add that a little bit with lean into community, I was thinking about Mandy, when you were mentioning your story, when I was learning electron new technology I didn't know. I had this code base that I had to learn. I didn't know what was going on, I was frustrated, I couldn't get anything working, and then I tweeted and asked for someone to pair with me.

Lo and behold, some random person from the internet was like, “Sure! I'd be happy to help! Let's meet up air on this,” and I managed to get over the major hurdles I had with getting my environment to set up and getting unstuck, figured out how to run the debugging tools, and all those things really happened as a consequence of nothing afraid to reach out.

Even when you might feel like you're struggling with these things alone, there really is a community out there and people that are willing to jump in and help and I think that's really great cool thing.

MANDY: All right, well with that, I think we're pretty set to wrap up.

If you want to join us you are in Slack. Danielle will receive an invitation to join us as well in our Slack community. It is a Patreon where you can fudge to support us monetarily on a monthly basis. However, if you're not comfortable with that, or do not want to, you can DM anyone of the panelists and we will get you in there for free.

So with that, I want to thank you, Danielle, for coming on the show.

DANIELLE: Thanks so much for having me for a great conversation.

MANDY: Awesome, and we'll see everyone next week.

Special Guest: Danielle Thompson.

Support Greater Than Code

00:47 - Jen’s Superpower: Being Optimistic

10:13 - Working On Open-Source Projects vs Commercial Software/Products

12:57 - Major vs Minor Releases

18:45 - RFC / Feedback Processes

23:25 - The Ember Core Team

26:31 - Doing Open Source Better

39:56 - Participation Encouragement & Engagement Tips

46:00 - Widening the Pool of Participants

47:36 - UX-Driven Design (User Experience-Driven Design)

Reflections:

Damien: Perspective of those impacted. Sponsors, users, etc.

Arty: What it’s like to work on a big open source project and the challenges we face.

Jen: Exploring small-project lifecycles.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

ARTY: Hi, everyone and welcome to Episode 253 of Greater Than Code. I am Artemis Starr and I am here with my fabulous co-host, Damien Burke.

DAMIEN: And we are here with our fabulous guest, Jen Weber.

Jen Weber is a member of the Ember.js core team and is a senior software engineer at ActBlue Technical Services. Jen loves open source, rapid prototyping, and making tech a more welcoming industry.

Jen, thank you so much for being here. Welcome to the show.

JEN: Thank you so much for having me.

DAMIEN: So you should have gotten an email preparing you for the first and most difficult part of every appearance on Greater Than Code. Are you ready for this?

JEN: I am.

JEN: All right. So I did get that email and I've been thinking about those for the last couple of days. I think my superpower is being able to imagine the ways that things can go well.

DAMIEN: Wow. That's very special.

JEN: Thank you.

DAMIEN: How did you acquire that?

JEN: So I used to be very good at imagining all of the ways that things can go badly. Those are still the patterns that my mind walks whenever I'm confronted with a challenge, but someone gave me some advice. I was recounting to them all of the ways that things could go badly, they were like, “What would it look like if things went well?” I've been trying to build that as a muscle and a skill anytime I'm working on a new project, or something hasn't gone well, something's already gone badly, and I'm trying to figure out what to do next. I found that helped me open up to more creative thinking.

ARTY: I really think that is a superpower and in order for things to go well, for us to manifest good things toward a good direction, we have to be able to see the steps to get there, imagine ourselves walking in that direction to be able to do it. And if we're caught in a loop of worrying about all the things that are going to go wrong, anticipating those things going wrong, then it's like we're going to be waiting for him and doing things that help bring those things that we don't want into being.

So if you find yourself in this mode, it sounds like this is something that you struggled with and learned this adaptive skill to break out of this pattern. So what kind of things do you do? Like, do you tell yourself things or ask yourself certain questions, or how do you snap out of that mode and get to a better place where you're thinking about things in a positive frame?

JEN: Sure. I think for me, the first step is just recognizing when I'm in that negative loop and accepting that it's my first reaction, but that doesn't need to be my conclusion to my thought process. If I'm working on let's say, there's a real-world challenge. Just to give an example as part of my work on the Ember core team, I might think about how do I engage the community and announce that there's going to be this new version of Ember?

If I imagine things going badly, I imagine like, “O, wow, nobody even retweets it a single time,” and if I imagine things going well, I think like, “Wow, it's this big moment in tech.” And if it was a big moment in tech, what would have the involved people done to get to that successful end point and trying to work backwards from that to connect the dots. It takes some intentionality, it takes having enough rest, it takes not being over-caffeinated to be able to unlock that kind of thinking.

DAMIEN: But it sounds so powerful, especially as an engineer, or as an advocate. It's like because we're in the role of making things into what we want them to be, which is things going well, right?

JEN: Yeah, and it's a little different than a wishful thinking, I would say, because you're still thinking in order for things to go, well, you have to overcome challenges, you have to solve problems, you have to prioritize, there's going to be difficult moments. So you're not just dreaming that this good feature is going to come into existence, but actually figuring out what are the nuts and bolts, and pieces, like, what are the ingredients to that recipe? When we think and reflect on that, how can we take those ingredients and apply them to right now to get where we want to go?

ARTY: So you take that vision and then work backwards and translate that to actual action. These are things that we can do right now to walk the path of getting where we want to go.

JEN: Mm hm, and it might take you somewhere totally different direction. It might be very different by the time you're done. But usually, you can figure out a few things here and there that are steps in the right direction, and the right direction could be one of many different directions.

ARTY: Do you find yourself ever getting disappointed that things don't go the way you envisioned?

JEN: Oh yeah, for sure.

[laughter]

Yeah, and I think that's a little bit part of the rollercoaster of being involved in software. Like every single day is a series of things going a little different than you thought they would. You read the code; you think it's going to go a certain way. You're wrong; you change your plan. You have this idea of a direction you're going to go, you've thought about what are the successful steps to get there, and then you end up in the wrong corner and you have to go back to the drawing board and surviving those cycles is just part of what we do.

ARTY: So does that superpower help you escape those feelings of disappointment then?

JEN: Oh yeah, I think so because not that I have some way to see the future, but more that I have tools for helping to figure out what my next step could be.

ARTY: So then you're always focused back on action.

JEN: Mm hm.

ARTY: And how can I take what I learned and this vision of what a good direction would be, taking these new data points and things into account, and then reimagine and translating that back into action.

JEN: Yeah.

ARTY: I think that qualifies as a superpower.

DAMIEN: Yeah, I think about it, I guess because I was writing code this morning, and so often, when you're writing – when I'm writing code at least, it's like oh, the phrase was “defensive programming” from a long time ago. How can this go wrong? What happens if this is nil? What happens if some evil guy in a black hat comes in and tries to do something here?

And what I've had to learn and still need to remind myself of is the good case. What is it that we're doing good for our users, or whoever else the code touches? What are they trying to accomplish and what experience are we trying to create for them? And so, both, as an engineer and a product manager, just being able to ask that question and see an answer on a small scale on a feature in stories, super important.

JEN: Yeah, and even if you're thinking of that adversarial aspect where it's like, you're trying to think through all of the security risks that are involved in developing some software, you can still use this thinking to your advantage. What would a successful future be where somebody tries to exploit that vulnerability and they fail? You've got them. What are the things you built? What are the strategies and habits that that team had? What is the monitoring and infrastructure that resulted in successfully preventing this, or that problem from occurring?

DAMIEN: It's not only a useful strategy and also, feels really good.

JEN: Mm hm.

DAMIEN: That’s great.

ARTY: I like that, though just thinking from a standpoint of just vulnerability, or even a case where things go “wrong,” in the case that you do have somebody hacking your system, or trying to exploit some vulnerability, what's the logging and information infrastructure? What does that story look like where even though these things are happening, we're prepared, we have the right things in place to give us visibility into what's going on, and be able to catch it and address it quickly. Like what do all those things look like such that we're ready to go and can still have a success story, even in the case of these challenges that come up?

DAMIEN: That sounds connected to something, I think we want to talk about today, which is what goes well when you get a major library upgrade, what does that look like?

JEN: Yeah. I've been thinking about this a lot lately; informed by two things. So one is that I'm involved in an Ember, which is a frontend JavaScript framework, and we're getting ready to do a 4.0 major release. So going through all of those exercises to have preparedness all comes back to how do we do this, or what do our users need, what are the resources that are missing?

That's one thing on my mind and the other is that I've recently updated some dependencies in the apps that I work in and had a hard time. What can I learn for myself about what to do differently? What can I learn that might be takeaways for library maintainers? What can I share with my coworkers and my collaborators to make this easier next time?

ARTY: What's it like working on an open source project and how does that feel different? What are the different aspects of that from working on a commercial product versus something in the open source community?

JEN: There's a couple of pieces. The biggest one is that when you're working in your own code base, you have at least a fuzzy picture of what the product is, what the constraints are, how many users there are, and the things that the developers on your team generally know and the things that they don't know. You have all this information that would help you inform how do I roll out some new, big feature, or something like that.

When you're working at open source, your universe of possible products, developers, and users is huge. Like, you could never write down a list of all the ways that somebody is going to be using that software and so, it becomes really different than having a set of well-defined products requirements; we want to get from point A to point B. It's like, we need to give everybody a path forward even though they're using this tool in all these different ways.

To do that, a lot of effort goes into gathering feedback from other people in the community. So we use a process called RFCs, or Requests for Comments where someone says, “Hey, I think this would be a good feature. Hey, I think this thing should be removed, or deprecated,” and you have to get feedback. Because we can't imagine all the ways ourselves that someone could use this feature, or tool and then once there's consensus amongst the core team, then something can move forward. But everything goes through a lot of iteration as part of that process.

So the overall progress can sometimes feel slow because you have to think through all of this extra weight—the weight of depending on thousands and thousands of developers and billions of users on you to make the right decision. It means you can't just “Oh, let's just merge this breaking change and I'll make this breaking change and I'll just post on Slack to everybody like, ‘Hey, watch out. I just changed this one thing. I documented it here. Good luck.’” You can't really quite pull that lever in the same way, but when you do have a step forward, it's a step forward for all of these apps, for all of these projects, for all of their users and so, little baby steps can still translate into really big impact.

ARTY: So when you have something that's a major release in that context, like a major release of Ember versus a minor release. How are those different? What kind of things do you do in major releases?

JEN: Yeah, that's a good question.

So I'll just provide a little bit of background information on this vocabulary that we're using for anyone who's listening in. A lot of projects follow semantic versioning, which is a set of rules that a lot of projects agree to follow that if you ever see a version number that's like 4.2.1.—oftentimes, that's semantic versioning and action in the first number—is for major releases and a major release is one that has a breaking change.

So that means that I make a change in that code base. I would expect that other people would have to change the code in their own apps and they would be forced to go through that—make that change—in order to upgrade to that version for the library I'm working on. Minor is usually used for features. Patch, the last one, is used for bug fixes and internal refactors, things like that.

Not all projects follow in the same way. Some projects have time-based cycles where they say, “Oh, we do a major release every six months,” or something like that. But for us major releases are breaking changes and the things that are different about them is that we have to give people a path forward to get to the next version. That could include putting some deprecation warnings, any code that's going to get removed or change any API that are going to shift in the next major version. We want to let people know, with a little warning, if they're using those older syntaxes, or APIs, whatever's going to be removed. We also want to try to give a lot of advanced notice about what's going to change, or be removed via blog posts, things like having a help channel set up maybe that's just for those upgrades. When it's time to actually do the major release, we try to make it boring.

This is something that I would like to see happen across the rest of the JavaScript ecosystem. It does seem to be catching on more, which is that when you do a major version release, all it does is it removes the things that need to be removed. You make your breaking changes and that's it, and then in follow-up releases is when you add in all the new features.

So let's say, some API is just the old way of doing things. It doesn't match up with a new rendering engine, or something like that. You're going to want to remove the old thing and then incrementally work to roll out these big splashy, new, exciting features. So maybe your exciting release is actually going to be 4.1, or 4.2, or 4.3.

This has a couple benefits. It lets your major releases be a little less risky because you're not just removing code and then adding new code at the same time. It lets people not be as overwhelmed like, “Oh, first I have to deal with all of these things that are removed, or changed and then now I also have to learn this whole new way of thinking about how to write my app using this tool.” It lets you take little baby steps towards doing things in a different way.

DAMIEN: Does this mean, in an ideal scenario, that if you don't have any deprecation warnings—if you're taking care of all the deprecation warnings—then your major release can go – you can upgrade some next major version without a code change.

JEN: Yeah, that's the dream.

DAMIEN: It does sound like a dream.

JEN: Yeah, and it's not always perfect, but it's an important pathway towards including more people and participating in upgrades, app maintenance, and creating sustainable code bases so you don't have to follow the Twitter, the blog post, and be checking the JavaScript subreddit just to keep up on with what's going on. You're not going to be surprised by big sweeping changes.

So coming back to this experience I had with upgrading a different library recently, I was upgrading major Jest versions and was very surprised to see that there were a ton of breaking changes in a changelog and I got a little bit frustrated with that. And then I went back and I read the blog posts and I saw a blog post from 2 years ago saying, “These are the things that we are doing, this is what is happening,” and that was great, but I wasn't doing Jest tests 2 years ago and so, I missed all of that. Can we use the code base itself to connect those dots, make those suggestions, and guide people towards the work that they do?

DAMIEN: If they put those deprecation warnings in 2 years ago, you would've had 2 years to make those changes.

JEN: Yeah.

DAMIEN: And then when you finally upgraded, it would have been a dream, or have been painless.

JEN: Yeah, and maybe they're there. Maybe there are some and I just need to pass the debug flag, or something. Hopefully, there's nobody who's shouting at their computer. But there's this one thing that we put it in the console log output, or something. It's possible I overlooked it but.

DAMIEN: I want to rewind a little bit back to the challenge of dealing with a product that is used in so many contexts by so many people, like Ember is, and the RFC process. The first thing I thought of when you mentioned that is what do you do with contradictory feedback? Surely, you must have hundreds of engineers who say, “You have to get rid of this,” and hundreds who say, “No, this has to stay.” How does the core team manage that?

JEN: Yeah. So I think the most important piece is the contradictory feedback needs to be considered. So it's not just like, “Oh, let's collect these comments as annual feedback forms,” or anything like that.

[chuckles]

This isn't like, “Oh, let's do some natural language processing on these comments to figure out if the sentiment is positive, or negative.”

[chuckles]

None of that stuff you have to actually read through them and think what could I do using this new feature to help meet this person's needs, or what's at the heart of the objection that they're making? If someone is saying, “This doesn't work for my team,” and entering that process with a willingness to iterate. In the end, we can't make everybody happy all the time, or no RFC would ever get moved forward. There's always going to be a point where you have to prioritize the pros and cons, and ultimately, the decision comes down to reaching consensus amongst the core team members.

So being able to say, as a group, “We believe that the feedback has been considered. We believe that the iterations have been incorporated, the people's concerns have been addressed,” or “We're going to work to create tools that think that problem be not a problem for them,” and find a way to move forward with whatever the proposal is. Or sometimes, the proposals don't move forward. Sometimes, they get closed.

ARTY: Is the work you end up choosing to do primarily driven by this feedback process, or do you have some visionary leadership within the core team that drives a lot of things forward that aren't necessarily coming via feedback?

JEN: That's a good question. I think it's a little bit of both. So certainly, a lot of RFCs have come from the community and from people asking like, “Hey, can we have this better way of doing things? I have an idea.” And then other times, you do have to have that visionary leadership.

So to give an example, we have just started doing – well, I shouldn't say just started doing that. I think it's been like 2 years now. We have started doing this process called additions where if there's a big splashy set of cool features that are meant to be used together, we give it a name. That's separate from the breaking changes process, ideally. We can create nice, new splashy sets of features without breaking people's apps and trying to design that experience isn’t something that you can just piecemeal through RFCs waiting for feedback to come through.

There were quite a few members of the core team that designed a new way of building Ember apps that was better aligned with focusing on HTML as the core of building for the web and focusing on JavaScript features as opposed to requiring developers to know and understand the special API syntaxes. You can just write JavaScript classes instead of needing to understand what an Ember object is.

So aligning ourselves more with the skills that everybody, who works in the web, has at least a little bit of. That took a lot of brainstorming, a lot of planning, and ultimately, introducing those things still follows an RFC process. Somebody still has to say, “Here's the thing we want to change, or do, or add. Here's the greater vision for it.” But to get that big picture look still requires the big thinking. So the core team, I don't even know how much time. They must've spent countless hours trying to hash out those details.

ARTY: How big is the core team?

JEN: So there's several core teams. Though when you say the core team as a whole encompasses people who work on the data layer, the command line tools, the learning tools, and then the framework itself. I want to say, could look this up, it's like upwards of 30 people, I think.

ARTY: Wow.

JEN: I can get you the exact number later, [chuckles] but everyone's pulling out their different area of domain and so, all of those teams also have to coordinate around these major releases because we want to make sure the work that we're doing is complimentary. If we do the framework improvements, but we don't fix up the docs, we’re not on the good path for a successful release.

ARTY: Are people working on this stuff full-time? Are people funded, or doing this in their free time, or how does that work? Because there's this big picture challenge of we have this ideal of community sourced, open source projects, and then the realities of trying to fund and support that effort bumps up to constraints of needing to make a living and things and these sorts of difficulties. How do y'all manage that?

JEN: It's a mixture.

So the Ember project is fortunate to have a major player—LinkedIn—that uses Ember and so, some of the core team members, their work on Ember is part of their LinkedIn work because of the frameworks doing well, then LinkedIn projects that are going to be doing well. There's also a number of people who are consultants, or who run consultancies that do Ember work, they're involved. Their voice is an important part of making sure that again, we're serving a variety of apps, not just ah, this is this tool that's just for the LinkedIn websites. But it's like, they've seen so many different kinds of apps; they're working on so many different kinds of apps right now. And then there's people who help out on more of a volunteer basis.

So I've been in my past work, it was at a different job. It was part of my job responsibilities to participate on the framework core team. These days, I'm more of a volunteer and I mostly help organize other volunteers—people who want to do some professional development to learn, people who want to network, people who found something that they're frustrated about enough that they want to fix it themselves. That’s how I got involved; I wanted to learn. So that's the sustainability of having people involved is always an ongoing challenge it is for every open source organization, I think.

ARTY: Yeah. Do you have any ideas on how we can do those sorts of things better? As you said, it's a concern, in general with how do we do open source better with these kinds of constraints? And then two, I feel like there's been some cultural shifts, I guess, you could say over time of you think about when the open source movement first started.

We had a lot more of this community ownership ideal where we really were going and building software together and now, there's a lot more of, well, there's all this free software out there that we use, that we build on top of to build our apps on, but that ownership piece isn't really there. It's an expectation that there should just be this free software out there that's maintained that we get and why is it falling apart?

So I feel like, culturally, just over time, some of those things have shifted as far as expectations around open source and then you talked about some of the corporate sponsorship aspects with usage as being one way these things get funded. But I'm wondering if you have ideas on how some of these things could work better.

JEN: People have done PhDs on this topic, I'm pretty sure. [chuckles] Like, theses. I read a white paper, a really involved white paper, a few weeks ago that was about, what was it? it was called something like the Burden of Maintaining Software, or something like that and it did this deep dive into how much goes in and just keeping the ship afloat. How much goes into just if there's a package that needs to be updated? That kind of ongoing, constant, mundane work that adds up really, really big.

So for very large projects, I think it's a good thing to have some sort of an evolvement of a sponsor company, if you will and so, that sponsor company may not actually ever donate any money, but the time of their engineers that they say like, “Hey, we're willing to help support this project” is really important.

I think another piece is that the leadership of projects should consider the people involved, that that group is going to be rotating. That people's involvement is ephemeral. Every time somebody changes jobs, maybe they're not going to be involved in that project anymore. If we can think about that ahead of time, plan for it, and make sure that we are sharing knowledge with each other such that the project can survive somebody moving onto something else, it can survive somebody going on vacation for a while.

So I think that's another key component of success is how do you make it so that you're not just relying on the same set of people still being there so many years later? We’ve been very fortunate within the Ember community that a lot of the same people have stuck around, but I try really hard not to bank on that. The group of contributors that I help organize, I think, “Hey.” We have a chat every time somebody joins the learning core team and say, “Hey, we get that you're not going to be here forever. Please let us know what we can do to support you. Please let us know when you're thinking of taking a break, or taking a step back. Please involve other people on any project that you're working on so that they will also continue your work and also support you so you don't get burnt out.

Another thing I try to do is always framing the work into how it values the contributor. Sometimes in open source you hear this discussion of like, “Oh, well, everyone should participate in open source because we all benefit from it.” There's a better attitude that we can have, I think, which is that for people who are interested in participating, what can they get out of it? What can I do as a leader to help them get something out of this?

If you just approach it with this altruism of “This is a community and I want to help,” that'll get you like a little bit. But if you can say, “I want to help because I want to learn from other developers,” that's something I can deliver on. That's something that they can take. That's valuable for their future earning potential, income, confidence, maybe they'll make the connection that helps them find their next job. Even if someone isn't being paid to help out, is there something that they can take away from this? And lastly, just acknowledging that doing work for free is a privilege as well.

We have to reframe how we think about open source sustainability, too. Not everybody can devote a few hours after work here and there and involving them and including them means that it's got to be part of their workday. So continuing to socialize from the company level that engineers should have a little bit of time here and there to try to help improve an open source project. Everybody doing that just a little bit helps with quite a few of the problems that these projects face.

ARTY: I've been thinking about this myself and you work directly, you're significantly involved in a major open source project, and so, you see things that a lot of people don't have perspective on. So I appreciate your insights on this.

I'm wondering what if major companies that were using open source software, if we made more efforts for companies to be a project sponsor and donate part of the company somebody who's on the company's time to help contribute to projects as like a thing. I feel like if that thing caught on, that the companies that were using this software for free [chuckles] had more of a sense of a social obligation to be one of the people that contribute some time to helping with that. Or get some companies that are big enough, too. It's probably easier and they have more interest in those sorts of things.

But I feel like if we did make that more of a thing, that that would be useful because as you're saying, somehow realistically speaking, this has to be something that can be worked into the workday.

JEN: Yes.

ARTY: For us to be able to support and sustain these things. And people that can do that outside of their workday as an extra free time thing. It really is a privilege.

JEN: Yeah. I think a couple of strategies that can help here are to frame it in the value to the company and frame it as a value to the users, frame it as a value to the engineering team. So rather than having it be like, “Oh, you use free software, you should do this thing.” Instead more like engineers, we always need to learn constantly in order to keep improving our own skills and to keep up with things that are changing.

So having an open source hour, or something like that—it takes a little more than an hour usually to accomplish much. But having a period of time that engineers were allowed to contribute to open sources. Professional development that you don't have to pay for a subscription. You don't have to pay for a licensing fee. You don't have to pay for somebody’s conference submission. If someone has the opportunity to reach outside of their sphere of knowledge, or comfort zone and it just so happens that if they succeed, it'll benefit your company maybe indirectly.

Another piece is what's the value to the users? So there were a bunch of people who all contributed effort towards bringing some improved linting tools for the template system within Ember. When we think of linting tools, we usually think that's like, “Oh, here's this thing to remind me to use nice tidy syntax and don't make my variable names too long and space everything out in a certain way,” but they can also help us find real actual problems in our apps.

So an example that this team worked on is they introduced some more linting rules for accessibility. If one person succeeds in introducing this new linting rule for accessibility, then it's there in their app for their team and they get to stop talking about, “Hey, make sure you do this one thing” over and over again because now it's enforced in the code base. Also, they've brought this benefit to all of the other apps that are out there.

Again, sometimes you can tie it back in to that value for the product and for the users, and really trying to think creatively about that connection. Because there's so many different things we can all spend our time on, you've really got to sell it in a way that aligns with the goals, or values of that organization.

ARTY: Yeah. I like that reframing. I can see just how important that is. Other things I'm thinking about if you had a dev team and one of your developers was really involved with the Ember core team, you'd have more knowledge about how things worked. So when something was broken, or something, you probably have more insight into what was going on and being able to help the team more effectively –

JEN: Yeah. [overtalk]

ARTY: To build stuff. And then if there's any suggestions, or things that could make things easier for your team, you'd have the ability to have influence with getting RFPs through to get changes made and things. I think you're right. It needs to be reframed as a value proposition.

JEN: Yeah, and it also requires an attitude shift on the side of the projects as well. There's tons of people who've tried to do open source and hit running straight into a wall of they open up pull requests that are never merged, or even reviewed and that can be a really frustrating experience. And some projects just don't have the feedback structure, or the governance structure that really allows open participation either.

So that's something that I think is an ongoing journey with lots of projects. It's like, how do we communicate? How do we involve other people? What types of decisions do we say like, “Hey, implementer, or community, you're in charge, you can make this” versus things that have to pass some sort of review. It’s not just a one side of companies need to step up, but also, maintainers seem to have a long-term vision of how they're interacting with everybody else.

DAMIEN: Yeah, I really love that frame of this is professional development and that you can get for free. That's like how would you like to educate your engineers and make them better engineers, especially on the tools you work on and not –? Yeah, that's really awesome. But then of course, on the other side, you need a welcoming environment. That's like, “Oh yeah, when you make a contribution, we're going to look at it. We're going to give you useful feedback on it.”

JEN: Yeah. I tried to get an open source project going a few years ago and I struggled for a while and eventually ended up giving up. But some of the things I ran into, I'd have somebody that would volunteer to help out with things and I'd work with them long enough to just start to get a feel for things and be able to contribute and then they would disappear. [laughs] And I go through that process a few times.

It's like, “Oh, yay. I'm excited, I get –” another person has volunteered and so, then I go and start working with them and trying to – and I put a lot of attention into trying to get things going and then they disappear. t was difficult to try and get traction in that way and eventually, I went, “Well, I'm back by myself again” [laughs] and that I just need to keep going.

ARTY: Right. So what kind of things have you found help with getting that participation aspect going and what kind of things are barriers that get in the way that maybe we can be better at?

JEN: Yeah. So my advice is always start with using the buddy system. Trying to pair program with people, who I'm hoping to stay involved, and the leveling up version of that is the people who are contributing pair with each other. It's so much more fun. There's so much more of a learning experience when it's two developers working on the project.

Left to my own devices, the projects that I work on, I have to really dig into my willpower to keep them moving if I'm the only person working on it versus if we're pairing, what's the value that I'm getting? It's like, I get to hear how the other person approaches the problem. I get to experience how they work. They teach me things. I teach them things. We have this good rapport.

So I pair once a week with my friend, Chris, and we work on everything from this kind of mundane stuff to the big vision, like what would we do if we could totally change how this thing works, or something like that, and that kind of energy and get ideas, they build up. So that's one piece.

The other, this one's difficult, but having well-scoped, well-written issues is a huge time sink, but also, it can be one of the best ways get people engaged and keep them engaged. If I stop writing really specific issues, people peter off. Someone will ask, maybe only once, they'll ask, “Hey, I want to help out, or something. What should I pick up next?” They don't usually ask a second time, but I don't have something right away to hand off to them.

So what is the momentum? Can I keep writing up issues and things that other people can follow through with? And then presenting them with increasing levels of challenge of like, “I have this unstructured problem. We've worked on this a lot together. You can do this. How would you approach this? What do you think we should do?” I don't necessarily say,” You can do this,” because it’s more of a subtle cheerleading that's happening than that.

But “I'd love to hear your proposal of what should happen next” just is a really powerful moment and sometimes, that can be the thing that catapults somebody into taking more ownership of a project and gathering together other people to help them out. And then people do come and go, but the commits are still there! So that's something, right?

[chuckles]

Like, things have taken some steps forward.

DAMIEN: Yeah. People come and go, that's something you know you have to accept on an open source project, but it happens in other places, too. [chuckles] No team stays together for all of eternity.

JEN: Right.

DAMIEN: Is the project going to live on and how can you make it so that it does? So these are very good lessons, even for that.

ARTY: It seems like just investing in thinking about, we were talking initially about planning for the success case, even when things happen. So if we think about the case of okay, people are going to leave the team. [chuckles] What's the success case look like? Imagining the way that things go really well when people are leaving the team, what does that look like? What are the things that we wish we had in place to be able to ramp people up quickly, to be able to find new people, to work on the project quickly? All of those things that we can think about and open source has this to a much larger degree and challenge so that you really have to think about it a lot.

Where on a commercial project, it's one of those things that often happens when you wish it wouldn't and one of the things I see in corporate companies is you'll have a management change, or something will happen with a product that upsets a bunch of people and you'll have exodus phase on the project and then ending up often rewriting things because you lose your core knowledge on the project and nobody knows what's going on anymore and it actually becomes easier to rewrite the things than to [chuckles] figure out how it works. If we had imagined the ways that things could go well and prepared for those certain circumstances, maybe we wouldn't be in that situation.

ARTY: Yeah. You mentioned something really important there, too, which is what can we do to help people spin up more quickly on something. That's another big piece of sustained engagement because you need a group of people spun up quickly. You need a group of people who can figure out the next steps on their own. And so, we've spent a lot of time, the projects that I work most actively on, making sure that everything is there in the Read Me, making sure that if you run npm start that things work if you're running it on a different environment. Those types of little things, reducing those barriers can also go a long way and just widening the pool of people who could potentially help is another big one.

DAMIEN: How do you do that? Because you're a core contributor on the project. You have the curse of knowledge.

JEN: Yes.

DAMIEN: You have a development scene that is tightly home to work on this project.

JEN: That's a great question. Ah, I do have the curse of knowledge. Being easy to reach so that if people do encounter problems that they can find you and tell you, which can be, it can be a small step. Just making sure that if you have a documentation page, it's got a link at the bottom that’s like, “Find a problem, open an issue!” That sort of thing.

Also, I'm pretty active on Twitter. Sometimes other contributors, experienced contributors, they'll spot something that somebody else has posted and they'll say, “Hey, Jen, take a look at this,” and they bring it to my attention. There's this team effort to uncover those gaps.

Another aspect is just working in the open. So having open meetings, having open chat channels, places where people can interact with the people leading the projects, they can come to the meetings, things like that means that we're more likely to hear their feedback. So if we get feedback, “Hey, this thing was difficult,” making sure that we address it.

DAMIEN: Wow. Well.

JEN: I'm really big into user experience driven design. We've been talking about maintainability a lot, we’ve been talking about the code, and versions, and things, but coming back to what is the impact for our users.

If you accept a user experience driven way of developing software, it means that you're always going to need to be upgrading, you're always going to have to be flexing, changing, and growing because the products of 2 years ago versus the product of today can be really different. Open source library that you needed to rely on 2 years ago versus today. Maybe the web app ecosystem has shifted. Maybe there's new ways of doing things. Maybe there's new syntaxes that are available.

Sometimes, it can be a little frustrating because you feel like, “Oh, there's this endless pile of work. We made all these wrong choices back in the day and now this thing's hard to upgrade,” and all that.

A different mindset is to think about what do we know today that is different than what we knew yesterday? What are the things we know today about our users that inform our next move? How do these upgrades, or improvements, or my choice of open source library help the end user have a better experience? And trying to come back to that big picture from time to time, because it can be pretty frustrating. When you get stuck, you think like, “Oh, I can't. I just tried to upgrade this major version and everything broke and everything's terrible. But what's the feature list look like, how am I going to use this to deliver something better to the users can really help?”

DAMIEN: Wow.

ARTY: So at this part of the show, we usually do reflections and finish off with any final thoughts we had, or takeaways from the episode.

Damien, you want to start?

DAMIEN: The big takeaway I got from this is kind of… it's perspective. Jen, you mentioned a user experience driven design. I was already really close to that language, but from a perspective of contributors to an open source project, sponsors—both in terms of engineering and then money—and then also, users. Like, these are also users. These are also people who are impacted by the work we do. So in order to do it successfully, it's very important to think of how can this go well for them and then move to that direction. So thank you, that was really great.

M: For me, the big takeaway, I feel like I learned a whole lot just perspective wise of what it's like to work on a big open source project. I haven't really had a conversation like this with someone that's been that involved with a major resource project before. So I found that really insightful.

One of the big questions I asked you about how do we make this sustainable? [laughs] Like all the challenges around things. I know they're big challenges that we face in figuring that out and you had some really key insights around how we can frame things differently as opposed to framing it as an obligation, like a social obligation, or you should do this altruistically because it's the right thing to do as the appeal that we make is when you're talking to a contributor, how do you frame things to be a value proposition for them as an individual. When we're talking to a company, how do we frame things in a way so there's a value proposition for the company to get involved with doing something? And change the way that we frame all these things to be able to get folks involved because they realize benefits as individuals, as company, as people being directly involved in things?

I feel like if we can do some work to maybe change some of the framing around things. That maybe there's a pathway there to increase engagement and support of open source projects, which I think is one of those things that we really need to figure out. There's not really easy answers to that, but I feel like some of the insights you came to there are really key in finding a pathway to get there. So thank you, Jen. I appreciate the conversation.

JEN: So for me, when I'm reflecting on the most is the story that you shared already of trying to get people involved and just having them leave. They show up for a little while and then they disappear and where does all that work go? I'm interested to explore a little bit more of that small project life cycle.

I was pretty fortunate to just come in at a time where there was already a well-established community when I started getting involved in Ember and I'd love to hear more from other people about what are the success stories of those first few steps where someone began this little project and it really started to grow and take off. This might be a case where like some of the strategies I described, they work when you already have an established community. So it's kind of like a catch-22. I don’t know, that could be a really cool future episode is the beginning.

DAMIEN: Yeah. That's something I'd definitely like to hear about.

ARTY: Well, thank you for joining us, Jen. It was really a pleasure talking with you.

JEN: Thanks so much for having me!

Special Guest: Jen Weber.

Support Greater Than Code

TRIGGER WARNING: Domestic Violence, Abuse, Interpersonal Safety

01:26 - Eva’s Superpower: ADHD and Hyperfocus

08:19 - Design for Safety

12:45 - What Engineers Need to Know

15:02 - Expanding Our Understanding of What “User” Means

20:43 - Parallels with Security

22:23 - Spreading Awareness Across Teams Focused on Feature Delivery

31:38 - Thinking Beyond The User

35:25 - Traditional Design Thinking Protects White Supremacy

40:21 - Putting Ergonomics, Safety, and Security Behind Paywalls

45:58 - Tech Workers and Privilege

Reflections:

Mandy: Inclusive and accessible technology includes people experiencing domestic abuse.

Damien: If a product can be used for harm, it will be.

Coraline: How systems are weaponized against marginalized and vulnerable folks.

The internet is good for connecting people with shared experiences but we’re breaking into smaller and smaller groups. Are we propping up systems by taking a narrow view based on our own experiences?

Eva: Who didn’t teach you about this?

It’s our job to keep ourselves safe in tech. Tech companies need to take more responsibility for user safety.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

MANDY: Welcome to Greater Than Code, Episode number 252. My name is Mandy Moore and today, I'm here with Damien Burke.

DAMIEN: Hi, and I am here with Coraline Ada Ehmke.

CORALINE: Wow. I actually showed up for once. [laughs] I'm very happy to be with y'all today and I'm very excited about the guest that we have today.

Her name is Eva PenzeyMoog and Eva is a principal designer at 8th Light and the author of Design for Safety.

Before joining the tech field, she worked in the non-profit space and volunteered as a domestic violence educator and rape crisis counselor. At 8th Light, she specializes in user experience design as well as education and consulting in the realm of digital safety design. Her work brings together her expertise in domestic violence and technology, helping technologists understand how their creations facilitate interpersonal harm and how to prevent it through intentionally prioritizing the most vulnerable users.

Eva, I'm so happy to have you here today. Hi!

EVA: Hi, thanks so much for having me. I'm so excited to be here.

CORALINE: So if I recall correctly and it has been a while so Mandy, correct me if I'm wrong, but I think we open with the same question that we've been opening with for 251 other episodes and Eva, that is, what is your superpower and how did you discover, or develop it?

EVA: Yeah, so my superpower is my ADHD, actually [chuckles] and specifically my ability to hyperfocus and I didn't really acquire and start to until the age of 25, which is when I was diagnosed.

For people who don't know, hyperfocus is basically exactly what it sounds like. It's a state of very intense focus that people with ADHD will sometimes go into. It's not something you really have control over, it's not something you can just turn on, or off, and it isn't necessarily good, or bad.

But for me, I'm really lucky because it often gets triggered when I start to code. So as I was starting to learn code and then I switched over to focusing on design and frontend like CSS and SAAS. But as I was learning that stuff, it gets triggered all the time. So I can sit down and code and oftentimes, hours have gone past and so long as I don't like miss any meetings or forget to eat, it's totally a superpower.

CORALINE: That's amazing.

I've talked about before, I live with bipolar disorder and I tend to stay in a low-grade manic state as my resting place and I experience very similar things with that hyper focus and just losing hours on a task and sometimes, it's very positive and I get a lot done and sometimes, I'm like, “What the hell did I do?” [chuckles]

EVA: Right.

CORALINE: But I think it's great that—I've been talking to some other folks with ADHD, with bipolar—the judo moves we can do takes something that really negatively affects us in a lot of ways and finding a way to turn it around, like you said, and use it as a superpower. Those are the strategies we develop when we live with things like this and I'm always happy when people have figured out how to get something good out of that.

EVA: Yeah, totally and realizing that you have this thing that happens. Because I'm sure it's been happening my whole life, but I didn't recognize it, or understand it and then just being able to name it and see that it's happening is so powerful. And then to be like, “Oh, I can maybe do certain things to try to get into it,” or just being aware that it's a thing it's like very powerful.

CORALINE: I'm kind of curious, Eva, if you don't mind us talking about ADHD for a little while?

EVA: Sure. Yeah.

CORALINE: Okay. I have a friend who is – actually, a couple of friends who were very recently diagnosed with ADHD and they had so much trouble in the traditional tech were workplace, especially working for companies that have productivity metrics like lines of code, or number of commits, or something like that. It was really difficult for both of these friends to operate in an environment where you're expected to have very consistent output day over day and not having accommodation, or not having the ability to design their work in such a way that maximizes the positives of how they work and minimizes the negatives of how they work.

Is that something you've struggled with as well?

EVA: Yeah, and that’s so unfortunate that your friends because like I said, I feel like it is a superpower and most workplaces, they should be trying to harness it and understand that, you can have really, really awesome employees with ADHD. If you set them up for success, they can be so successful.

But it is something – so I've only ever worked at 8th Light actually, when I was interviewing, over 5 years ago now, and started doing, trying to find my first job in tech, after doing a bootcamp, I interviewed at a couple different places and none of them felt super great. But obviously, I was just really eager to get my first job.

But then I went into 8th Light and 8th Light was one of the places where I really, really did want to work there and was really excited for the interview. But when I got to the office, it was very quiet and there was an open workspace, but people were working very quietly and there were like lots of rooms.

I got into that and I was like, “Oh, thank God” like, this is exactly the space I need. I can't handle too much activity. I can't handle offices where they're actually playing music; that type of thing is my nightmare and I don't actually like wearing headphones all day like that. That's not just a easy fix for me and for a lot of people with ADHD.

So I felt like right away, now I want to work here even more and I've been really lucky that it's been a really good setup for someone like me to work and I have gotten some accommodations which has been good. I feel like if you don't give accommodations, they're breaking the law, they need to do that.

DAMIEN: This is really, really validating because I've had similar experiences of that. Even just this morning where I was in the code and I had no idea how much time was going by and I had no awareness of anything else. That's possible because of the environment I have that I work in. Whereas, previous jobs I've had with bullpens and just open office plans, I was in incredibly miserable there and I didn't understand how people could get any work done in those environments. So just this understanding of how people are different; in what environments some people thrive in and other environments other people thrive in.

EVA: Yeah. So have you always worked from home, or has this been a pandemic thing?

DAMIEN: This has been probably about 10 years. Yeah. [laughs] I went home and never left. [laughs]

EVA: Nice. [chuckles]

CORALINE: I've done something very similar. I started working from home, I think in 2015 and not for a great reason, but I found the exact same thing that you're talking about. Like I am very sensitive to my environment. I use music to control my mood and like you, Eva, I hate headphones. So I do wonder, you mentioned accommodations and the legal perspective on that. In Illinois where – Eva, you live in Illinois, too. Are you local for 8th Light?

EVA: Yeah. I live in Chicago.

CORALINE: We have that will employment and it's really easy to discriminate against folks on multiple axes rather than providing our accommodations. Without will employment, they can just let you go and you have no proof that it was because they're ableist, or racist or transphobic, or whatever.

EVA: Oh, yeah. That's so rough. Pritzker's got to get on that. Our governor. [chuckles]

CORALINE: So do you want to tell us a little bit about the book that you just wrote? I understand a lot of people are finding a lot of value in it and really opening their eyes to a lot of maybe issues they weren't aware of.

EVA: Yeah. So my book, Design for Safety, came out in early August and it's been really great to see people's reactions to it. I got my first formal book review, which was really cool and it was overall very positive, which has been very exciting.

I'm hopeful that it is helping people understand that this is a thing because it's different, I feel like than a lot of other problems. Someone else explained this to me recently and I had this light bulb moment that I'm not providing a solution to a problem that people know that they have this problem, like how their tech is used for interpersonal harm and now I have a solution like, here's this book that's going to tell you how to fix it. It's more that people don't even know that this is a problem.

So I'm educating on that as well as trying to give some of the solutions on how to fix it. It has been a lot of people just saying like, “I had no idea about any of this. It's been so eye-opening and now I'm going to think about it more and do these different things.” So that's been really great to see that just people’s awareness is going up, basically.

MANDY: I really like on the website, the sentence that there's a pullout quote, or I'm not sure if it's even a pullout quote, but it says, “If abuse is possible, it's only a matter of time until it happens. There's no might, so let's build better, safer digital products from the start.” I like that.

EVA: Yeah, thanks. I was very intentional and well, this goes back to when I was doing a conference talk. Before I wrote the book, I did a conference talk called Designing Against Domestic Violence and I thought a lot about the type of language should I use; should I say might happen, or should I say will happen? I eventually settled on it's going to happen even if it hasn't happened yet, or oftentimes, I think we just don't know that it's happened.

People who have gone through domestic violence, some of then we'll talk openly about it. But most people just don't, which makes sense. It's this really intense, personal thing to go through and there's so much judgment and survivors get blamed for all these things. So it makes sense that people don't want to talk that much about it. I ended up thinking we just need to say that it will happen.

DAMIEN: That's amazing. So I really want to know everything about this book. [chuckles] but to start with, you said the book is designing for safety and you witnessed this a little bit with domestic violence, violence and abuse. Can you talk about safe from what sort of things you mean when you say safety there?

EVA: Yeah, for sure because I know safety is a big word that can mean a lot of different things. But the way that I'm talking about it in my work is in terms of interpersonal safety. So it's like how is someone who has a relationship with you in an interpersonal way going to use technology, weaponized technology, in a way that was not meant to be used? We aren't designing tech with these use cases in mind, but how is it ultimately going to be weaponized for some type of abuse?

Domestic violence is really the emphasis and my big focus and was mentioned in the intro, some background in domestic violence space. But there's also issues with child abuse and elder abuse, especially in terms of surveillance of those groups as well as surveillance of workers is another thing that came up a lot as I was researching that I didn't get as much into in the book. But it's basically anytime there's an interpersonal relationship and someone has access to you in this personal way where you're not just an anonymous stranger, how is tech going to be used to exert some form of control, or abuse over that person?

DAMIEN: Wow, that is a very important subject. So I'm an engineer who doesn't have a lot of knowledge about interpersonal violence, domestic abuse, anything of that nature and I know you've written a whole book [laughs] and we only have an hour, or so here, but what are the first things that people, or engineers need to know about this?

EVA: Yeah, so I think the first thing is to understand that this is a problem and that it's happening and to go through some different examples of how this happens, which is what the first couple chapters of the book are all about. It's different forms of this interpersonal abuse via technology in the form of shared accounts is a really big one and this question of who has control and nebulous issues of control. There's also surveillance is a really big one and then location data as well.

So I guess, I don't want to say like, “Oh, just read the book,” but learning a little bit about the different – there's so many different examples of how this works. Just to start to build that mental model of how this happens like, someone taking advantage of certain affordances within a shared bank account software, or someone using an internet of things device to gaslight someone, or torment them.

There's so many different examples. Location data shows up in all sorts of really sneaky in terms of stalking. It's not purely putting a tracker on someone's car, or even like Google Map and sharing your location is a more straightforward thing. But there's also, it shows up in other ways like, a grocery store app that has a timestamp and location. You can learn someone's grocery shopping habits and maybe you're estranged from this person, or they've left you because you're abusive, but they don't know that their stuff is showing up in this app and their location data. So it shows up in all sorts of different ways.

This is a very long way to answer your question, but I think the first thing is to start to understand how this stuff works so that you're just aware of it and then from there, I have a whole chapter about how to implement a practice of designing for safety at your company. It is a little more design focused, but I think engineers can absolutely be doing this work, too. Even if it's just like quick research on how are any product with any type of message feature is going to be used for abuse and there’s lots of literature out there. So just looking at some articles, thinking about ways that aren't covered already, that just having a brainstorm about what are some new ways this might be used for abuse and then thinking about how to prevent them.

CORALINE: One of the things that I was thinking about after reading your book, Eva, is at a metal level, or zooming out a bit. I think a lot of the ways that we design software, we have this idealized and homogenous notion of a user. I think that in a lot of cases, especially if you're working on a project that's like more, or less one of those scratch your own itch problems, you tend to think of yourself as the user.

It's great to have that empathy for the end user, but what we don't have, I don't think as a field, is an understanding that user is an abstraction and it is a useful abstraction. But sometimes you need to zoom down a little bit and understand the different ways that people want to use the software and will use the software and what makes them different from this average idealized user.

That was one of the things that really struck me, especially from the process you were describing, is expanding our understanding of what user means and anticipating the different use cases with hostile users, with actively abusive users, and I think thinking of abstraction is super helpful, but I feel like sometimes we need to zoom down and think differently about really who the people are and what their circumstances might be.

EVA: Yeah. Oh man, I just wrote down what you said, user is an abstraction. That's such a good way to think about it that I haven't heard before, but you're absolutely right that it's encapsulating such a big group of people. Even if for a small product, something that's not like Twitter that's open to billions of people, even something that's a subscription, or something that's going to have a smaller user base. There's going to be such a diverse, different group within there and to just think of the term user as a catchall is definitely problematic.

Sorry, I'm just processing that user is an abstraction, that term because we use it so much as designers, definitely.

CORALINE: Yeah.

EVA: And anyone in tech is always using this term, but problematizing that term in a new way is really interesting to me.

And I think my other thought about this is that we talk a lot about needing to think about more than just happy path and I feel like even that, at least in my experience, has been other things that are also very important where it's like, let's think about someone who has a crappy Wi-Fi connection, or someone who's low vision. Like there are all these other very important things to think about in terms of accessibility and inclusivity.

I think I see what I'm doing as just adding another group into the mix of let's think about people who are currently surviving domestic violence, which is maybe a little bit harder to bring up than those other two that I mentioned because it's just so dark and it's something that we just don't want to have to think about, or talk about during work. It's just such a bummer, but it is really important to have this new group added when we're thinking about inclusive and accessible tech.

DAMIEN: There's a really great parallel here, I think with security minded design and research. Again, that's another user who is not behaving in the happy path. That's not behaving the way your normal users are behaving and you have to design your system in such a way to be resilient to that.

So I love this user as an abstraction, then breaking it down into all these ways and then also, there's a huge value to diversity in your team with this sort of thing.

CORALINE: Absolutely.

DAMIEN: You can understand the very different types of users having people on the team who can understand blackhat users who are going to be trying to use your servers to mine Bitcoin, or [laughs] blind users, low vision users, or colorblind users, for goodness’ sake. And then in addition to that, people again, who are experiencing domestic violence, other to terms of other forms of interpersonal abuse and just being able to understand all those users and their experiences with the things you're building and designing.

EVA: Yeah, definitely those are all really good points.

Just going back to what you said about the parallels with security is something I've actually been thinking about that a lot, because I think there are lots of parallels to that, or useful things about how security professionals think about their work and operate.

Especially the big one for me right now is thinking about a security professional. They're never going to be like, “Okay, we did it. Our system is secure. We're done. We have arrived.” That's not a thing and I feel like it's very similar with designing for safety, or even inclusion. There's just, you're never – I feel like we've had a mental model of “I can think about these things, I can check these boxes, and now, my product is inclusive, or my product is accessible.”

I feel like we should be thinking more like security professionals where there's always going to be more things like, we always have to be vigilant about what's the next way that someone's going to misuse tech, or the group that’s going to be identified that we've totally left out and is being harmed in some way. So I think that's just a useful shift that I'm thinking a lot about.

CORALINE: And Damien, I'm so glad you brought up the parallels with security. I was actually going there as well.

One of the things that I've been thinking about from an ethical source perspective is insecurity that, I think two tools that would be super useful. First of all, personas and secondly—I guess, three things—understanding that safety can be a matter of adding layers of friction to disincentivize abusive behavior and like you said, recognizing this is an ongoing arms race. Every new feature that you design opens up some kind of attack, or abuse factor and if you're not planning for that from the outset, you're going to be caught later when harm has been done.

EVA: Yeah, absolutely. Since you brought up personas, there is something in the process that I created that's a similar tool where I call them archetypes because they're a little different from personas. But it's identifying who is the abuser in this scenario, who is the survivor, and what are their goals and that's basically it, we don't need to get into anything else.

I don't think, but just articulating those things and then even having a little printout, kind of similar to the idea with personas like, oh, you can print them out for your sales team, or whoever it is to keep these people in mind. A similar idea of just having them printed out an on your wall so that it's something that you're thinking about like, “Oh, we have this new feature. We probably need to think about how is this abuser person that we've identified who would want to use our product to find the location data of their former partner,” whatever it is.

CORALINE: Yeah.

EVA: Use this.

CORALINE: From a mechanical perspective, Eva, one of the one of the challenges I had at GitHub when I was working on community and safety is that the other engineers and the other groups were creating so many new features. I felt like the knowledge about how feature can be abused, or like you said, will be abused wasn't spread very effectively throughout, especially a large software organization, and it fell on a small team of folks who frankly were not consulted. A feature would go out and we'd be like, “Holy crap, you can't do that because of this, this, and this.”

So do you have any do you have any thoughts? I know you said print it out, or put it on the wall, but do you have any thoughts for how to spread that awareness and that mode of thinking across teams who frankly may be very, very focused just on feature delivery and will see any consideration like that as slowing them down, or having negative impact on “productivity”?

EVA: Yes. I have many thoughts. [chuckles] So this is bringing up something for me that I've struggled with and thought about is should there be specialized teams in this area? I feel like yes, we want people with special knowledge and experts and that's really important, but also, I feel like the ideal scenario is that it's just everyone's job.

CORALINE: Yeah.

EVA: Those teams were already doing things and it wasn't seen as “Oh, Coraline’s team is going to come in and now we have to consult with those people,” or whatever because it's not our job, it's their job.

CORALINE: Yeah.

EVA: Which this isn't a very maybe satisfying answer to your question because I feel like it involves a huge shift in the way that we think about this stuff, but it is something I've thought about in terms of should I call myself a safety designer? Is that something I want to do? Do I want this to be like a specialized role? Maybe is that a goal where people start to see that? Because there are people who specialize in inclusive design, or accessible design.

But then the downside of that is does that just give someone else even more leeway to be like, “Not my job, I don't have to worry about this. And then we have the problems, like what you just described. I don't know, I feel like it's such a big shift that needs to happen.

CORALINE: Yeah. One of the models I've been thinking about and I was thinking of this in terms of generalists versus specialists is generalists, or to map that to domain that we're talking about now, the other engineers in your group, or in your company. I feel like there has to be a balance between specialization and general knowledge. The way I describe that is everyone should have literacy on a particular topic and the basic vocabulary for it and a general knowledge of the concepts augmented by a specialist who has fluency. So kind of a dynamic relationship between literacy and fluency. Do you have any thoughts on that?

EVA: I love that. I'm literally writing that down.

A generalist with literacy and a specialist with fluency is such a good way to think about it because I feel like I do say this. I don't want people who read my book, or see my talk to think like, “Oh, I have to be like her, I have to learn all this stuff. I have to really dig into domestic violence works and what it means and laws.” I don't want people to feel like they have to do that because it's just such a dark, heartbreaking thing to have to think and read about every day and I don't think that's a realistic goal. But I think being a generalist with literacy is realistic augmented by specialist with fluency; I'm just like basically repeating what you just said.

[chuckles]

But that's just a really brilliant way to think about it.

DAMIEN: That pattern actually really matches something that I learned from another Greater Than Code guest. I'm sorry, I can't remember their name right now. I believe we were talking about inclusivity and what they said was like, “It's not the expert's job to make the product, or the company inclusive. [chuckles] It's the expert job to support – it's everybody's job to make it inclusive. It's the expert's job to be an expert and to support them.” We also use again, a metaphor from security. We don't have security experts whose job it is to make your app secure, we have security experts whose job it is to support everybody in keeping your app secure.

CORALINE: Yeah.

DAMIEN: So I feel like that this matches really well. The job of the person with this expertise is to support, to educate, to guide not because they can't do all the work together all themselves, like Coraline said. There's just too many features being added for [laughs] for some team somewhere to go, “Oh no, this is fine,” or “That's not fine.”

EVA: Yeah, totally, and I feel like that just brought up something for me, Damien, about the speed at which we work, too many features being added, not enough time to actually do this work, and how—this is getting at just way bigger critique of tech in general.

DAMIEN: Yeah.

EVA: But it's okay to slow down once in a while. I feel like just the urgency thing causes so many problems outside of just what we're talking about. But this is another big one that I feel like it's okay to spend an afternoon thinking through what are the ways this is going to be not inclusive, or unsafe and that's totally fine. But I fall into it, too where I'm like, “I want to deliver things quickly for my client,” or if I'm doing so internal for a flight, I want to get done quickly. I don't want to hold people up. So it is a really hard thing to break out of.

CORALINE: It seems to me, Eva, that this kind of knowledge, or this kind of literacy, or this kind of making it part of the process can fall solely on engineers. Because in a lot of places, we have of product managers who are setting deadlines for us. How do you communicate to them why this work is so important when they may only see it as like, “Well, you're getting in the way of us hitting a release date and we have a press release ready,” or “We want our debut this feature at a particular time, or place”?

MANDY: And now we want to take a quick time out to recognize one of our sponsors: Kaspersky Labs:

Rarely does a day pass where a ransomware attack, data breach, or state sponsored espionage hits the news. It's hard to keep up, or know if you're protected. Don't worry, Kaspersky’s got you covered. Each week, their team discusses the latest news and trends that you may have missed during the week on the Transatlantic Cable Podcast mixing in humor, facts and experts from around the world. The Transatlantic Cable Podcast can be found on Apple Podcasts & Spotify, go check it out!

EVA: Yeah, totally. So I think ideally, this comes from everyone. My book is called Design for Safety, but I really hope that people are reading it, who are also engineers and who are also project managers—basically anyone who has a say in how the product is actually going to function, I think should be doing this work.

But specifically, if you have a project manager who is rushing everyone and saying, “We don't have time for this,” I do have a couple different strategies in my book about this, where it's like we can use statistics to talk about that this is a thing that is impacting a lot of our users. It's 1 in 3 women, 1 and 4 men in the US have experienced severe physical, domestic violence and that's just severe physical, domestic violence. There's so much domestic violence that doesn't have a physical component to it so that could be like a third of our user base.

So bringing stuff up like that to try to get some buy-in, but then also my process, I have little time estimate.

CORALINE: Yeah.

EVA: So saying like, “We want to do research; it's going to be 6 hours.” “We want to do a brainstorm; it's going to be 2 hours.” Giving people very specific things that they can say yes to is always going to be better than just an open-ended, “We want to design for safety.”

CORALINE: Yeah.

EVA: And someone being like, “I don't know what that means, but we have a deadline.” Saying like, “We're going to do a brainstorm to identify ways that our product will be used for harm. We want to do it next week and we want to spend 4 hours on it” is going to be a lot better.

DAMIEN: And I want to call out how important and useful the language you use there was you said because when you find something, when you do that brainstorm, or whatever analysis process, you go like, “Oh, here's the way our products will be used for harm.” Because if you say to a product manager, “Here's a way our product might be used for harm,” they go, “Well, okay.” [laughs] “Might not be.” [laughs] If you say, “Here's a way our product will be used for harm.” Well, now that leaves a lot less of wiggle room.

EVA: Hmm, yeah. That's a really good point that I actually hadn't thought about.

I think the other thing is there's tangible outcomes from something like that brainstorm, or these different activities that I have outlined. You can actually show the person, like, “Here's what we did. Here's what we came up with,” which isn't necessarily – I wish we didn't have to always do that; always have some type of very explicit outcome from everything we do. But I do think that's a reality that we have that this process kind of helps with.

CORALINE: I want to go back to the user thing. Again, one of the things that we're thinking about our ethical source is thinking beyond the user and thinking about not just who is using the technology that we're creating, but the people that the technology we're creating is being used on.

EVA: Yes. That's such a good point. I'm actually curious, have you come up with a term for that type of user? Like nonuser?

CORALINE: I have not yet, but that's a great call out. Language is so important so, yeah.

EVA: Yeah. I don't know that it exists and I've seen nonuser, but I don't know that that's agreed upon.

DAMIEN: I've gotten as far, the best I've come up with is constituency.

CORALINE: That is very interesting, Damien because one of the things we're developing is a governance tool. The W3C, when they were working on the HTML standard—this was a couple of years ago, I think—they mentioned something called a priority of constituent and this was very much from a standards body perspective, but it was one sentence and I think it is such a powerful sentence. Just for their example, they said, “In times of conflict, we prioritize end users over developers, over browser manufacturers, over spec writers, over technical purity.”

[laughter]

EVA: Wow.

CORALINE: That’s one sentence, but writing that down, I think can really help cut through a lot of a lot of the noise and a lot of the gray area maybe that's the most encountered. It's so simple and you can do it in a single sentence. So absolutely, the notion of constituencies and being explicit about whose safety, convenience, or what have you you're optimizing for.

EVA: Yeah. That's really important and I have two thoughts.

One is that this comes up a lot in the surveillance space where it's like, what sort of rights, or priority should we be giving someone who is walking on the sidewalk in front of a house that has a Ring camera that's facing out to capture the porch, but is ultimately capturing the sidewalk in the street? What are the rights of that person, that nonuser, who has not agreed to be filmed and isn't part of this product's ecosystem, but is still being impacted by it?

It's something I think about a lot, especially there's so many in my neighborhood I see. Since I wrote the book, I see the Ring cameras everywhere, including in places where they're not really to be like on the outside of someone's gate, just facing the sidewalk. It's like, you're not even recording your own property at that point. It's just the gate, or it's just the sidewalk, I mean, which I feel is very problematic.

You also said that it's important to explicitly call out who you're prioritizing and that's something – I read this book called Design Justice by Sasha Costanza-Chock, which was very lifechanging and it's just such a good book. It's a little more theoretical. She explicitly says it's not a guide, but she talks about this, about how it's really important to, if you are going to choose not to be inclusive, or safe, or justice focused, whatever it is, you need to explicitly say, “We are choosing to prioritize the comfort of this group over the safety of this group.

CORALINE: Yeah.

EVA: Or whatever it is. Like, you need to actually just spell that out and be upfront about it.

DAMIEN: Yeah. It reminds me of, I think I learned this from Marla Compton. Although, I don't know if she originated it. I guess, she probably didn't, but the phrase she taught me was, “We prioritize the safety of marginalized people over the comfort of non-marginalized people.” It's such a powerful statement.

CORALINE: It really is.

DAMIEN: Yeah, and just making that explicit like, “These are the tradeoffs and these are where we side on them.”

CORALINE: Yeah.

EVA: Yeah. Oh, yeah. That's such a good one.

I did this workshop recently, it's called How Traditional Design Thinking Protects White Supremacy, but they talked a lot about how feeling entitled to comfort is just such a white supremacist thing and I feel shows up in different forms of oppression as well like men's comfort, et cetera. But that's something I've been thinking about a lot is the feeling of a right to comfort and how that also includes a right to not have to have any type of conflict and a fear of conflict. How these things all play together and how it's all part of white supremacy and how it shows up in our culture, in our workplaces. It was a great workshop. I would highly recommend it because it's also been a lifechanging thing as I digest all of the different things from it.

DAMIEN: It's so powerful to name that as comfort.

CORALINE: Yeah.

DAMIEN: Like, this is what we're protecting. We're protecting these people's comfort [chuckles] and this is what it will cost.

CORALINE: I think about what Kim Crayton said for a year is, “Get comfortable with being uncomfortable.”

EVA: Yeah, that's such a good one. I love her.

CORALINE: Yeah.

EVA: I quoted her in my book about, oh, I forget what it is. It's something about not having strategy is chaos.

CORALINE: Oh my God.

EVA: Like, the need for strategy.

CORALINE: I learned so much from her from that one statement. That was literally lifechanging for me. That was literally lifechanging for me because I always had a negative feeling about strategy, like strategy is coercive, or insincere. And then another friend of mine I was talking to about it said strategy is good when it's not a zero-sum game.

EVA: Mm.

CORALINE: I think we maybe we can think about personal safety and abuse factors in that way.

EVA: Yeah, definitely. I think the full quote is “Intention without strategy is chaos.”

CORALINE: Yeah, that.

EVA: That has been very definitely influential for me and as I feel like a big part of the reason, that idea is why I wrote my book and did my conference talk is because I was feeling frustrated with – it's a lot easier to raise awareness about an issue than it is to have actual strategies for fixing it. I felt like I would always get really fired up reading something, or listening to a talk and be like, “Yeah, this is such a huge problem. We need to fix it,” and then didn't have a takeaway, or anything that I could really do at work other than just being told to think about this, or consider this, which I'm like, “When do I do that?”

CORALINE: And what does that look like?

EVA: Yeah, you can't think about all of the different things we need to think about from 9:00 to 5:00 while we're at work every day. We need a strategy to do that, which is why I like made these different activities that I have in my process.

But going back to this white supremacy and design workshop that I did, I also learned in there about how some other ways that white supremacy shows up is having an action bias and a sense of urgency.

CORALINE: Yeah.

EVA: And how a lot of that can come from people, especially white people, not being able to like sit with discomfort when we're faced with really uncomfortable topics and a desire to jump into action before we fully understand the problem and have internalized it.

So now I'm feeling like I need to backtrack a little bit and be like, “Yes, provide action.” But also, it is good to do deep learning. I think we need both, but I feel like a lot of people, it's one, or the other. Let's do a ton of learning, or let's jump right into action. I have always been a jump right into action person and now I'm realizing it's okay to take a beat and do some deep learning and to sit with all the discomfort of the heavy topic.

CORALINE: A friend of mine gave me a concept that I like a lot. He has a definition of ergonomics that is the marriage of design and ethics. When I use the term ergonomics in that sense, what I mean is how easy is it to do a particular action. One of the things that I see quite a bit—something, I think is a terrible consequence of the web, frankly—is putting ergonomics behind paywalls and asking people who use our software to yield some degree of agency, or digital autonomy, or security in exchange for features.

EVA: Hmm. So interesting.

CORALINE: So I'm curious maybe how you would frame designing for safety, some of the other axes of oppression that we discussed on the show today, from the perspective of the ethical aspect of our design decisions. What workflows are we optimizing for? What workflows are we putting behind a paywall, or in exchange for okay, you’re signing up. The [inaudible] says you're buying into surveillance capitalism and you just simply have to do that if you want an email account, if you want a Twitter account, what have you.

EVA: Yeah. I do feel like there is a bit of an issue with putting safety and security sometimes behind a paywall where you can literally pay more to not get advertised to, for example.

CORALINE: Yeah.

EVA: Which it's like, I get that products have to charge money and it’s like we shouldn't – the flipside of that is well, we can't just work for free. I see that a lot with journalism when people are criticizing paywalls and it's like well, but journalists have to get paid. They can't work for free just like everyone else.

But I do feel that with things like being able to opt out of advertising and I feel like there are other things. Nothing's coming in right now, but different ways that you can ease some of the crappier parts of tech, if you have enough money, to buy into the paid versions of things is definitely problematic. Who are we keeping out when we do that and who are we saying doesn't deserve this privacy and the safety? What should just be standard? The seatbelt; I'm obsessed with the history of the seatbelts.

CORALINE: [chuckles] I still have the [inaudible] that's been going around.

EVA: Yeah.

CORALINE: It’s amazing.

EVA: I've talked about this in many different places, but the seatbelt used to be something that you had to pay extra for. In today's dollars, it would've been like 300 extra dollars when you bought a car to get seat belts and only 2% of the people, in 1956 when they were introduced, actually paid for them and probably even less were actually using them. And then there was a revolution in the auto industry led by activists and everyday people. It definitely not come from the auto industry; they had to be forced into these different things. But now seat belts, the government basically, they passed a law and they said, “You have to just include seat belts as a standard feature.”

I think about that a lot in tech. The things now that we're making people pay for, should some of those just be standard features and how are we going to get there? Probably government regulation after a lot of activism and everyday people rallying against these different things with big tech. But I think we're going to get there with a lot of things and we're going to see a lot of seatbelts, so to speak, become just standard features and not something you have to pay for.

CORALINE: And I wonder, you mentioned government regulation; I have literally zero faith in government doing anything effective in the online world at all because our government is powered by 65-year-old white men that are rich and there's no incentive for them to care about this even if they did have the basic literacy about how this stuff works.

It seems to me one of the things that we've been seeing really emphasize is, especially during in post lockdown, is worker organizing and I wonder if there's a strategy here for empowering the engineers, who frankly, we are being treated rockstars right now. I hate that term rockstar, but we're overpaid, we're pampered—a lot of folks, obviously, not everyone.

So can we leverage our power? Can we leverage the privilege of being in such an in-demand profession to affect change in organizations that have no financial incentive to think about stuff like this at all?

EVA: Yeah. So many things I want to respond to. Definitely, I think worker power is like such a strong point in all of this and I feel like we are the ones leading out on this. A lot of it is coming from people who work in tech and understand the issues. Like, writing, speaking, and doing these different things to help everyday people who don't work in tech understand like, “Hey, actually, here's why Facebook is really terrible.” A lot of that is coming from people in tech, even former Facebook employees even.

CORALINE: Yeah.

EVA: Which is different, I think from the paradigm shift we had with the auto industry. I don't know, I would have to look, but I'm pretty sure is not coming from car designers and engineers weren't helping lead that charge the way that we are.

But I also want to respond to something you said about tech workers being overpaid and pampered, which yes, I agree with you. But I also think there are privileges that everyone should have and that no one should of and I feel like everyone deserves to be well paid, to be comfortable and have all these perks, and whatnot.

I had a career in nonprofit before this so I have so much internalized just baggage about and guilt around feeling with my pay, my benefits, and all these things. The work I do now, compared to the work I was doing in the nonprofit, which was helping kids who were basically on a road to dropping out before graduating high school, which was really important work and I made so much less money and worked so much harder. But I feel like everyone deserves to be as well paid as we are and it is possible.

CORALINE: Yes.

EVA: So I just wanted to kind of throw that out there as well that we – [chuckles] I feel like I'm trying to just absolve myself from being a well-paid tech worker. But I do think we deserve this and also, everyone else deserves similar treatment.

CORALINE: Absolutely.

DAMIEN: Yeah. I feel the same way, especially—to take an example within a tech company—as an engineer, I get paid a lot more than customer service people.

CORALINE: Yeah.

DAMIEN: And that doesn't mean I'm overpaid, [chuckles] it means they're underpaid.

CORALINE: Yeah.

DAMIEN: A lot. [laughs]

CORALINE: Yeah.

EVA: Yeah, and I feel like this whole conversation, honestly, this is a freaking tactic. This is what the people at the top, this is how they want us to feel; pitting us against each other, feeling like it's not that – the sales people, that's normal and we're overpaid. It's like, no, actually we're paid a livable amount where we can live comfortably and they're exploited even more than we are.

That's how I'm trying to think about things because I do feel like this other way of looking at it is just absolutely a tactic of, I don't know, the 1%, whatever you want to call them. The company leaders definitely don't want us to feel like we're – they would rather us feel that we're overpaid and pampered than just compensated for the labor we do in a fair way,

MANDY: Have us feel the shame and guilt around it, too. Before I was in tech, I went from welfare to making a reasonable standard of living in a year and sometimes, I still feel guilty about it. It's a heck of a feeling.

EVA: Yeah, and I feel like that didn't just come out of nowhere. We've been taught that we should feel guilty for just surviving. I don't know. Because I think even in tech, it's a lot of people there's still so many issues with burnout, with—I don't know about you all, my body sometimes just hurts from not moving enough during – like, there's still all these like different things that could be better. But the feeling that we should feel guilty for having some comfort and decent pay, I think that's definitely a strategy that has come from these different powerful groups. It didn't just come out of nowhere.

CORALINE: I appreciate y'all pushing back on that. I guess, I'm speaking from an emotional place. Eva, you went from nonprofit and the tech. In April, I went from tech and the nonprofit and personally, I took a 30% pay cut and – [overtalk]

EVA: Oh, wow.

CORALINE: It just really made very visible and very personal seeing what we value as a society and what we don't value as a society. I'm still comfortable; I still have a living wage and everything. But look at what happened during the lockdown with “frontline workers.’ They're heroes, but we don't want to pay them more than minimum wage.

So I definitely agree with what you're saying about other people being underpaid and I definitely hear what you're saying about that guilt, but guilt is a form of discomfort. What are you going to do with that? What are you going to do with the privileges and the power that we have as a result of the way we're treated in this industry? I feel like that's the more important thing and what do you do with it? Are you giving back? Are you giving back in a substantive way, or are you giving back to assuage your guilt? It's nuanced. As y'all are pointing out, it is nuanced.

EVA: Yeah. It's very complicated, but I feel like agitating for those—sorry, Damien, I think you said support people—getting paid more, that's something we can agitate for.

I know someone, I'll call her an online friend of mine in the infertility space, which I'm very involved in as I go through my journey. I hate that word, but I've made all these online friends who are going through it and one of them is a paralegal and she is obviously hoping, although it's not going well, to get pregnant. But she was looking into the parental benefits and realized that the lawyers where she works had, I think it's 18 weeks fully paid off and then everyone else got this weird piecemeal of 6 weeks paid off, then there's FMLA, and then there's PTO, and all this stuff that amounted to a lot less, and you had to like use all of your PTO and all these different things. She actually was able to—with some of the lawyers help, I believe—get that policy change that it was just the same for everyone because it was like, “I didn't go to law school. So therefore, I don't need as much time with my newborn? How does that make sense?”

EVA: So I feel there is a lot of potential to have more equality in our companies, especially as the most powerful people often in the companies, to push for that change to happen.

CORALINE: Yeah.

EVA: There needs to be a lot of solidarity, I think, between these different types of workers.

CORALINE: Yeah, and that's a great example of that.

MANDY: Well, this has been an absolutely fantastic conversation and I feel so privileged just to be sitting here kicking back and just taking in the back and forth between the rest of you.

I wrote down a bunch of a things, but one of the biggest takeaways that I have had from this episode, and especially if you've been listening to the show the past couple episodes, we've been talking about a lot of accessibility things. Eva, you said something that was mind-blowing for me and it shouldn't be mind-blowing, but it was because I was like, didn't even ever think of that and what the hell is wrong with me for not even ever thinking about that? but inclusive and accessible includes people experiencing domestic abuse. It’s not something – I guess, because as what you said, people don't talk about it. So just keeping that in mind was pretty pertinent to me.

I also liked what Coraline said about specialization and then the general knowledge and literacy versus fluency. That was really good as well.

So it's been an awesome conversation. Thank you.

Damien, what do you have?

DAMIEN: Oh, well, this has been really awesome and I want to of first thank Eva for being our guest here and for the work you do and this book.

The thing that's going to be sticking with me, I'll be reflecting on for a while, is this sentence both well, if the product can be used for harm, it will be, which is not only a really powerful thing to keep in mind when designing and building a thing, but also, a powerful sentence that is really useful in communicating these issues. So thank you very much for that.

CORALINE: One of the things that and actually Eva, this was a reaction I had when I first read your book is, I think a lot of us, a growing number of us, have at least an awareness, if not a personal experience, with how systems are weaponized against marginalized, or vulnerable folks. So I think it's really important that in your book, you focus very specifically on a particular domain of abuse, abuse of power and loss of agency and loss of privacy, loss of physical safety.

One of the things I've been thinking about a lot is how the internet has been really good for connecting people with shared experiences and creating communities around the shared experiences. But I do worry that we're breaking into smaller and smaller and smaller groups and I see that. I don't know if it's intentional, but it certainly is a way, I think that we're propping up, that we're being coerced into propping up these systems by taking a narrow view based on our own experiences.

I don't see that as a criticism. What I see it as is an opportunity to connect with other folks who experience that same kind of systemic damage in collaborating and trying to understand the different challenges that we all face. But recognizing that a lot of it is based frankly, white supremacy. We used to talk about patriarchy; I think the thinking broadly has evolved beyond that.

But I would love to see your publisher start putting books together on different particular axes, but also, looking at ways that we can bridge the differences between these different experiences of intentional, or unintentional harm. So that's something that I think I'm going to think about.

EVA: Nice. I can't give any spoilers, but I do think my publisher might have something in the works that it's getting at some of this stuff.

Wonderful.

EVA: Which is exciting.

CORALINE: Yeah.

EVA: Yeah, okay. Man, those are all so good.

My reflection, I'm just thinking a lot about our conversation about the way that people in tech might feel like we're overpaid, or pampered and how that feels like an intentional thing that has come from somewhere and things like that don't just – it always comes from somewhere.

I'm thinking Mandy, about what you said in your reflection. You said, “What's wrong with me for not thinking about this?” I always feel like when I hear people say things like that, it's like well, when were you – I think more who didn't teach you about this? Why wasn't this part of your education as you were learning to code and before you joined the industry? I feel like that's more where the blame lies than with individuals, but yeah.

Something I was thinking about earlier today, before we started recording, is that this idea of user safety, that it's like our job to keep ourselves safe on tech and there's so many resources out there, different articles, and different things. I've been thinking similarly about that, but that's a marketing campaign. That's something that the leaders of big tech done to intentionally shift responsibility from themselves and onto the end user.

We're expected to be legal experts, read these agreements, and understand every single thing about a product that no one uses every single feature, but we're expected to understand it. If we don't and something goes wrong, either interpersonal harm, what I do, or with like oh, someone guessed your password or whatever it was, it's your fault instead of it being the tech company's responsibility. I feel like that's another thing that I'm thinking like that didn't come from nowhere, that came from somewhere.

CORALINE: Yeah.

EVA: It feels like a very intentional strategy that big tech has used to blame us for when things go wrong. Not to say that we get to be absolved of everything, people have responsibilities and whatnot, but I feel like a lot of times it's like this comes from somewhere and I'm trying to think more about that kind of stuff. This conversation was really awesome for helping me process some of those and expand my thoughts a little bit more. So thank you all, this was just really awesome.

DAMIEN: Thank you. Thank you for being here.

MANDY: Thank you for coming.

CORALINE: Yeah. So happy to talk to you, Eva.

EVA: Yeah. You, too.

MANDY: All right, everyone. Well, with that, we will wrap up and I will put a plug in for our Slack community. You can join us and Eva will get an invitation as well to come visit us in Slack and keep these conversations going.

Our website to do that is patreon.com/greaterthancode. Patreon is a subscription-based thing that if you want to you can pledge to support the show. However, if you DM any one of us and you want to be let in and you cannot afford, or just simply don't want to, monetarily support, we will let you in for free. So just reach out to one of the panelists and we'll get you in there.

So with that, I will say thank you again. Thank you, everybody and we'll see you next week!

Special Guest: Eva PenzeyMoog.

Sponsored By:

• Kaspersky Labs: Rarely does a day pass where a ransomware attack, data breach or state sponsored espionage hits the news. It's hard to keep up or know if you're protected. Don't worry Kaspersky’s got you covered. Each week their team discusses the latest news and trends that you may have missed during the week on the Transatlantic Cable Podcast mixing in humour, facts and experts from around the world. The Transatlantic Cable Podcast can be found on apple podcasts & spotify, go check it out!

Support Greater Than Code

01:09 - Todd’s Superpower: Advocacy For Accessibility

06:18 - Joining The W3C

07:44 - Getting People/Companies/Stakeholders to Care/Prioritize About Accessibility

15:20 - The Domino's Pizza Story

18:21 - Things That Typically Aren’t Accessible And Should Be

26:27 - Accessibility for Mobile Devices

28:08 - Color Contrast

33:02 - Designing w/ Accessibility in Mind From the Very Beginning

36:22 - Contrast (Cont’d)

38:11 - Automating Accessibility!

Reflections:

Mae: Eyeballing for contrast.

John: We are all only temporarily abled and getting the ball rolling on building accessibility in from the beginning of projects going forward and fixing older codebases.

Mandy: Using alt-tags going forward on all social media posts.

Todd: Accessibility work will never end. Accessibility is a right not a privilege.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

JOHN: Welcome to Greater Than Code, Episode 251. I’m John Sawers and I’m here with Mae Beale.

MAE: Hi, there! And also, Mandy Moore.

MANDY: Hi, everyone! I'm Mandy Moore and I'm here today with our guest, Todd Libby.

Todd Libby is a professional web developer, designer, and accessibility advocate for 22 years under many different technologies starting with HTML/CSS, Perl, and PHP. Todd has been an avid learner of web technologies for over 40 years starting with many flavors of BASIC all the way to React/Vue. Currently an Accessibility Analyst at Knowbility, Todd is also a member of the W3C. When not coding, you’ll usually find Todd tweeting about lobster rolls and accessibility.

So before I ask you what your superpower is, I'm going to make a bet and my bet is that I'm 80% positive that your superpower has something to do with lobster rolls. Am I right?

[laughter]

Am I right?

TODD: Well, 80% of the time, you'd be right. I just recently moved to Phoenix, Arizona. So I was actually going to say advocacy for accessibility, but yes, lobster rolls and the consumption of lobster rolls are a big part.

MAE: I love it. That's fantastic.

MANDY: Okay. Well, tell me about the advocacy. [chuckles]

TODD: So it started with seeing family members who are disabled, friends who are disabled, or have family members themselves who are disabled, and the struggles they have with trying to access websites, or web apps on the web and the frustration, the look of like they're about ready to give up. That's when I knew that I would try to not only make my stuff that I made accessible, but to advocate for people in accessibility.

MAE: Thank you so much for your work. It is critical. I have personally worked with a number of different populations and started at a camp for children with critical illnesses and currently work at an organization that offers financial services for people with disabilities – well, complex financial needs, which the three target populations that we work with are people with disabilities, people with dementia, and people in recovery. So really excited to talk with you today. Thanks.

TODD: You’re welcome.

JOHN: When you started that journey, did you already have familiarity with accessibility, or was it all just like, “Oh, I get to learn all this stuff so I can start making it better”?

TODD: So I fell into it because if you're like me and you started with making table-based layouts way back in the day, because what we had—Mosaic browser, Netscape Navigator, and Internet Explorer—we were making table-based layouts, which were completely inaccessible, but I didn't know that.

As the web progressed, I progressed and then I bought a little orange book by Jeffrey Zeldman, Designing with Web Standards, and that pretty much started me on my journey—semantic HTML, progressive enhancement in web standards, and accessibility as well. I tend to stumble into a lot of stuff [laughs] so, and that's a habit of mine. [laughs]

MAE: It sounds like it's a good habit and you're using it to help all the other people. So I hate to encourage you to keep stumbling, but by all means.

[laughter]

Love it.

If you were to advise someone wanting to know more about accessibility, would you suggest they start with that same book too, or what would you suggest to someone stumbling around in the dark and not hitting anything yet?

TODD: The book is a little outdated. I think the last edition of his book was, I want to say 2018, maybe even further back than that. I would suggest people go on websites like The A11Y project, the a11yproject.com. They have a comprehensive list of resources, links to learning there.

Twitter is a good place to learn, to follow people in the accessibility space.

The other thing that, if people really want to dive in, is to join The W3C. That's a great place and there's a lot of different groups. You have the CSS Working Group, you have the accessibility side of things, which I'm a part of, the Silver Community Group, which is we're working on the Web Content Accessibility Guidelines 3.0, which is still a little ways down the road, but a lot of great people and a lot of different companies. Some of those companies we've heard of—Google, Apple, companies like that all the way down to individuals. Individuals can join as individuals if your company isn't a member of the W3C.

So those are the three things that I mainly point to people. If you don't really want to dive into the W3C side of things, there's a lot of resources on the a11yproject.com website that you can look up.

MANDY: So what does being a member entail? What do you have to do? Do you have to pay dues? Do you have to do certain projects, maybe start as an individual level, because I'm sure we have mostly individuals listening to the show. Me as a newbie coder, what would I do to get started as a member of this initiative?

TODD: Well, I started out as an individual myself, so I joined and I can get you the link to The W3C Community Page. Go to sign up as an individual and someone will approve the form process that you go through—it's nothing too big, it's nothing complicated—and then that will start you on your way. You can join a sub group, you can join a group, a working group, and it doesn't cost an individual. Companies do pay dues to the W3C and if your company is in the W3C, you get ahold of your company's liaison and there's a process they go through to add you to a certain group.

Because with me, it was adding me to The Silver Community Group. But as an individual, you can join in, you can hop right into a meeting from there, and then that's basically it. That's how you start.

JOHN: What are the challenges you see in getting not only the goals of a W3C, but I'm assuming specifically around accessibility?

TODD: Some of the things that I've seen is buy-in from stakeholders is probably the number one hurdle, or barrier. Companies, stakeholders, and board members, they don't think of, or in some cases, they don't care about accessibility until a company is getting sued and that's a shame.

That's one of the things that I wrote about; I have an article on Smashing Magazine. Making A Strong Case for Accessibility, it's called and that is one of few things that I've come across. Getting buy-in from stakeholders and getting buy-in from colleagues as well because you have people that they don’t think about accessibility, they think about a number of different things. Mostly what I've come across is they don't think about accessibility because there's no budget, or they don't have the time, or the company doesn't have the time. It's not approved by the company.

The other thing that is right up there is it's a process—accessibility—making things accessible and most people think that it's a big this huge mountain to climb. If you incorporate accessibility from the beginning of your project, it's so much easier. You don't have to go back and you don't have to climb that mountain because you've waited until the very end. “Oh, we have time now so we'll do the accessibility stuff,” that makes it more hard.

MAE: John, your question actually was similar to something I was thinking about with how you developed this superpower and I was going to ask and still will now. [chuckles] How did you afford all the time in the different places where you were overtime to be able to get this focus? And so, how did you make the case along the way and what things did you learn in that persuasion class of life [chuckles] that was able to allow you to have that be where you could focus and spend more time on and have the places where you work prioritize successful?

TODD: It was a lot of, I call it diplomatic advocacy. So for instance, the best example I have is I had been hired to make a website, a public facing website, and a SAAS application accessible. The stakeholder I was directly reporting to, we were sitting down in a meeting one day and I said, “Well, I want to make sure that accessibility is the number one priority on these projects,” and he shot back with, “Well, we don't have the disabled users,” and that nearly knocked me back to my chair. [laughs] So that was a surprise.

MAE: There's some groaning inside and I had to [chuckles] do it out loud for a moment. Ooh.

TODD: Yeah, I did my internal groaning at the meeting so that just was – [chuckles] Yeah, and I remember that day very vividly and I probably will for the rest of my life that I looked at him and I had to stop and think, and I said, “Well, you never know, there's always a chance that you're able, now you could be disabled at any time.” I also pointed out that his eyeglasses that he wore are an assistive technology. So there was some light shed on that and that propelled me even further into advocacy and the accessibility side of things.

That meeting really opened my eyes to not everyone is going to get it, not everyone is going to be on board, not everyone is going to think about disabled users; they really aren't. So from there I used that example. I also use what I call the Domino's Pizza card lately because “Oh, you don't want to get sued.’ That's my last resort as far as advocacy goes. Other than that, it's showing a videotape of people using their product that are disabled and they can't use it. That's a huge difference maker, when a stakeholder sees that somebody can’t use their product.

There's numbers out there now that disabled users in this country alone, the United States, make up 25% of the population, I believe. They have a disposable income of $8 trillion. The visually disabled population alone is, I believe it was $1.6 billion, I think. I would have to check that number again, but it's a big number. So the money side of things really gets through to a stakeholder faster than “Well, your eyeglasses are a assistive technology.”

So once they hear the financial side of things, their ears perk up real quick and then they maybe get on board. I've never had other than one stakeholder just saying, “No, we're just going to skip that,” and then that company ended up getting sued. So that says a lot, to me anyways. But that's how I really get into it.

And then there was a time where I was working for another company. I was doing consulting for them and I was doing frontend mostly. So it was accessibility, but also at the same time, it was more the code side of things. That was in 2018. 2019, I went to a conference in Burlington, Vermont. I saw a friend of mine speaking and he was very passionate about it and that talk, and there was a couple others there as well, it lit that fire under me again, and I jumped right back in and ever since then, it's just then accessibility.

MAE: You reminded me one of the arguments, or what did you say? Diplomatic advocacy statements that I have used is that we are all temporarily abled. [chuckles] Like, that's just how it is and seeing things that way we can really shift how you orient to the idea of as other and reduce the othering. But I was also wondering how long it would be before Pizza Hut came up in our combo.

[laughter]

MANDY: Yeah, I haven't heard of that. Can you tell us what that is?

TODD: [chuckles] So it was Domino’s and they had a blind user that tried to use their app. He couldn't use their app; their app wasn't accessible. He tried to use the website; the website wasn't accessible. I have a link that I can send over to the whole story because I'm probably getting bits and pieces wrong. But from what I can recall, basically, this user sued Domino's and instead of Domino's spending, I believe it was $36,000 to fix their website and their app, they decided to drag it out for a number of years through court and of course, spent more money than just $36,000.

In the end, they lost. I think they tried to appeal to the Supreme Court because they've gone up as high as federal court, but regardless, they lost. They had to – and I don't know if they still have an inaccessible site, or not, or the app for that matter because I don't go to Domino’s.

But that's basically the story that they had; a user who tried to access the app and the website, couldn’t use it, and they got taken to court. Now Domino's claimed, in the court case, that he could have used the telephone, but he had tried to use the telephone twice and was on hold for 45 minutes. So [laughs] that says a lot.

JOHN: Looks like it actually did go to the Supreme Court.

TODD: Yeah. Correct me if I'm wrong, I think they did not want to hear it. They just said, “No, we're not going to hear the case.” Yeah, and just think about all these apps we use and all the people that can't access those apps, or the websites. I went to some company websites because I was doing some research, big companies, and a lot of them are inaccessible. A little number that I can throw out there: every year, there's been a little over 2,500 lawsuits in the US. This year, if the rate keeps on going that it has, we're on course for over 4,000 lawsuits in the US alone for inaccessible websites. You've had companies like Target, Bank of America, Winn-Dixie, those kinds of companies have been sued by people because of inaccessible sites.

MAE: Okay, but may I say this one thing, which is, I just want to extend my apologies to Pizza Hut.

[laughter]

MANDY: What kinds of things do you see as not being accessible that should be or easily could be that companies just simply aren't doing?

TODD: The big one, still and if you go to webaim.org/projects/million, it's The WebAIM Million report. It's an annual accessibility analysis of the top 1 million home pages on the internet.

The number one thing again, this year is color contracts. There are guidelines in place. WCAG, which is the Web Content Accessibility Guidelines, that text should be a 4.5:1 ratio that reaches the minimum contrast for texts. It’s a lot of texts out there that doesn't even reach that. So it's color contrast.

You'll find a lot of, if you look at—I’m looking at the chart right now—missing alt texts on images. If you have an image that is informative, or you have an image that is conveying something to a user, it has to have alternative text describing what's in the picture. You don't have to go into a long story about what's in the picture and describe it thoroughly; you can just give a quick overview as to what the picture is trying to convey, what is in the picture.

And then another one being another failure type a is form input labels; labels that are not labeled correctly. I wrote a article about that [chuckles] on CSS-Tricks and that is, there's programmatic and there’s accessible names for form labels that not only help the accessibility side of it, as far as making the site accessible, but also it helps screen reader users read forms and navigate through forms, keyboard users also.

Then you have empty links and then a big one that I've seen lately is if you look up in the source code, you see the HTML tag, and the language attribute, a lot of sites now, because they use trademarks, they don't have a document language. I ran across a lot of sites that don't use a document language. They're using a framework. I won't name names because I'm not out to shame, but having that attribute helps screen reader users and I think that's a big thing.

A lot of accessibility, people don't understand. People use screen readers, or other assistive technologies, for instance, Dragon NaturallySpeaking voice input. But at the same time, I’ve got to also add accessibility is more than just deaf, or blind. I suffer from migraines, migraine headaches so animation, or motion from say, parallax scrolling can trigger a migraine. Animations that are too fast, that also trigger migraine headache. You have flashing content that can potentially cause seizures and that's actually happened before where an animated GIF was intentionally sent to someone and it caused a seizure and almost killed the person.

So there's those and then the last thing on this list that I'm looking at right now, and these are common failures, empty buttons. You have buttons that don't have labels. Buttons that have Click here. Buttons need to be descriptive. So you want to have – on my site to send me something on the contact form, it's Send this info to Todd, Click here, or something similar like that.

MAE: Can you think of any, John that you know of, too? I've got a couple of mind. How about you, Mandy?

MANDY: For me, because I'm just starting out, I don't know a whole lot about accessibility. That's why I'm here; I’m trying to learn. But I am really conscious and careful of some of the GIFs that I use, because I do know that some of the motion ones, especially really fast-moving ones, can cause problems, migraines, seizures for people. So when posting those, I'm really, really mindful about it.

JOHN: Yeah, the Click here one is always bothers me too, because not only is it bad accessibility, it’s bad UX. Like HTML loves you to turn anything into a link so you can make all the words inside the button and it’s just fine. [laughs] There's so many other ways to do it that are just – even discounting the accessibility impact, which I don't want it.

TODD: Yeah, and touching upon that, I'm glad you brought up the button because I was just going to let that go [chuckles] past me. I have to say and I think it was in the email where it said, “What's bothering you?” What bothers me is people that don't use the button. If you are using a div, or an anchor tag, or a span, stop it. [laughs] Just stop it. There’s a button element for that. I read somewhere that anchor tag takes you somewhere, a div is a container, but button is for a button.

MAE: I love that. The only other ones I could think of is related to something you said, making sure to have tab order set up properly to allow people to navigate. Again, I liked your point about you don't have to be fully blind to benefit from these things and having keyboard accessibility can benefit a lot of people for all kinds of reasons.

The other one is, and I would love to hear everybody's thoughts on this one, I have heard that we're supposed to be using h1, h2, h3 and having proper setup of our HTML and most of us fail just in that basic part. That's another way of supporting people to be able to navigate around and figure out what's about to be on this page and how much should I dig into it? So more on non-visual navigation stuff.

TODD: Yeah, heading structure is hugely important for keyboard users and screen reader users as well as tab order and that's where semantic HTML comes into play. If you're running semantic HTML, HTML by default, save for a few caveats, is accessible right out of the box. If your site and somebody can navigate through using let's say, the keyboard turns and they can navigate in a way that is structurally logical, for instance and it has a flow to it that makes sense, then they're going to be able to not only navigate that site, but if you're selling something on that site, you're going to have somebody buying something probably. So that's again, where tab order and heading structure comes into play and it's very important.

JOHN: I would assume, and correct me if I'm wrong, or if you know this, that the same sort of accessibility enhancements are available in native mobile applications that aren't using each HTML, is that correct?

TODD: Having not delved into the mobile side of things with apps myself, that I really can't answer. I can say, though, that the WCAG guidelines, that does pertain to mobile as well as desktop. There's no certain set of rules. 2.2 is where there are some new features that from mobile, for instance, target size and again, I wrote another article on CSS-Tricks about target size as well. So it's if you ever noticed those little ads that you just want to click off and get off your phone and they have those little tiny Xs and you're sitting there tapping all day? Those are the things target size and dragging movements as well.

I did an audit for an app and there was a lot of buttons that were not named. A lot of the accessibility issues I ran into were the same as I would run into doing an audit on a website. I don't know anything about Swift, or Flutter, or anything like that, they pretty much fall into the same category with [inaudible] as far as accessible.

JOHN: I also wanted to circle back on the first item that you listed as far as the WebAIM million thing was color contrast, which is one of those ones where a designer comes up with something that looks super cool and sleek, but it's dark gray on a light gray background. It looks great when you've got perfect eyesight, but anybody else, they’re just like, “Oh my God, what's that?” That's also one of the things that's probably easiest to change site-wide; it's like you go in and you tweak the CSS and you're done in a half hour and you've got the whole site updated. So it's a great bit of low-hanging fruit that you can attach if you want to start on this process.

TODD: Yeah. Color contrast is of course, as the report says, this is the number one thing and let me look back here. It's slowly, the numbers are dropping, but 85.3%, that's still a very high number of failures and there's larger text. If you're using anything over 18 pixels, or the equivalent of 18—it's either 18 points, or 18 pixels—is a 3:1 ratio. With that color contrast is how our brains perceive color. It's not the actual contrast of that color and there are people far more qualified than me going to that, or that can go into that.

So what I'll say is I've seen a lot of teams and companies, “Yeah, we'll do a little over 4.5:1 and we'll call it a day.” But I always say, if you can do 7:1, or even 10:1 on your ratios and you can find a way to make your brand, or whatever the same, then go for it. A lot of the time you hear, “Well, we don't want to change the colors of our brand.” Well, your colors of your brand aren’t accessible to somebody who that has, for instance, Tritanopia, which is, I think it's blues and greens are very hard to see, or they don't see it at all.

Color deficiencies are a thing that design teams aren't going to check for. They’re just not. Like you said, all these colors look awesome so let’s just, we're going to go with that on our UI. That's one thing that I actually ran into on that SAAS product that I spoke about earlier was there was these colors and these colors were a dark blue, very muted dark blue with orange text. You would think the contrast would be oh yeah, they would be all right, but it was horrible.

JOHN: You can get browser plugins, that'll show you what the page looks like. So you can check these things yourself. Like you can go in and say, “Oh, you're right. That's completely illegible.”

TODD: Yeah. Firefox, like I have right here on my work machine. I have right here Firefox and it does this. There's a simulator for a visual color deficiencies. It also checks for contrast as well. Chrome has one, which it actually has a very cool eyedropper to check for color contrast. If you use the inspector also in Firefox, that brings up a little contrast thing. The WAVE extension has a contrast tool.

There's also a lot of different apps. If you have a Mac, like I do, I have too many color contrast because I love checking out these color contrast apps. So I have about five different color contrast apps on my Mac, but there's also websites, too that you can use at the same time. Just do a search for polar contrast. Contrast Ratio, contrast-ratio.com, is from Lea Verou. I use that one a lot. A lot of people use that one. There's so many of them out there choose from, but they are very handy tool at designer's disposal and at developers’ disposal as well.

JOHN: So I'm trying to think of, like I was saying earlier, the color contrast one is one of those things that's probably very straightforward; you can upgrade your whole site in a short amount of time. Color contrast is a little trickier because it gets into branding and marketing's going to want to care about it and all that kind of stuff. So you might have a bit more battle around that, but it could probably be done and you might be able to fix, at least the worst parts of the page that have problems around that.

So I'm just trying to think of the ways that you could get the ball rolling on this kind of a work. Like if you can get those early easy wins, it’s going to get more people on board with the process and not saying like, “Oh, it's going to take us eight months and we have to go through every single page and change it every forum.” That sounds really daunting when you think about it and so, trying to imagine what those easy early wins are that can get people down that road.

TODD: Yeah. Starting from the very outset of the project is probably the key one: incorporating accessibility from the start of the project. Like I said earlier, it's a lot easier when you do it from the start rather than waiting till the very end, or even after the product has been launched and you go back and go, “Oh, well, now we need to fix it.” You're not only putting stress on your teams, but it's eating up time and money because you're now paying everybody to go back and look at all these accessibility issues there.

Having one person as a dedicated accessibility advocate on each team helps immensely. So you have one person on the development team, one person on the dev side, one person on the marketing team, starting from the top. If somebody goes there to a stakeholder and says, “Listen, we need to start incorporating accessibility from the very start, here's why,” Nine times out of ten, I can guarantee you, you're probably going to get that stakeholder onboard. That tenth time, you'll have to go as far as maybe I did and say, “Well, Domino's Pizza, or Bank of America, or Target.” Again, their ears are going to perk up and they're going to go, “Oh, well, I don't really, we don't want to get sued.”

So that, and going back to having one person on each team: training. There are so many resources out there for accessibility training. There are companies out there that train, there are companies that you can bring in to the organization that will train, that'll help train. That's so easier than what are we going to do? A lot of people just sitting there in a room and go, “How are you going to do this?”

Having that person in each department getting together with everybody else, that's that advocate for each department, meeting up and saying, “Okay, we're going to coordinate. You're going to put out a fantastic product that's going to be accessible and also, at the same time, the financial aspect is going to make the company money. But most of all, it's going to include a lot of people that are normally not included if you're putting out an accessible product.” Because if you go to a certain website, I can guarantee you it's going to be inaccessible—just about 99% of the web isn't accessible—and it's going to be exclusive as it's going to – somebody is going to get shut out of the site, or app. So this falls on the applications as well.

Another thing too, I just wanted to throw in here for color contrast. There are different – you have color contrast text, but you also have non-text contrast, you have texts in images, that kind of contrast as well and it does get a little confusing. Let's face it, the guidelines right now, it's a very technically written – it's like a technical manual. A lot of people come up to me and said, “I can't read this. I can't make sense of this. Can you translate this?”

So hopefully, and this is part of the work that I'm doing with a lot of other people in the W3C is where making the language of 3.0 in plain language, basically. It's going to be a lot easier to understand these guidelines instead of all that technical jargon. I look at something right now and I'm scratching my head when I'm doing an audit going, “Okay, what do they mean by this?” All these people come together and we agree on what to write. What is the language that's going to go into this?

So when they got together 2.0, which was years and years ago, they said, “Okay, this is going to be how we're going to write this and we're going to publish this,” and then we had a lot of people just like me scratching their heads of not understanding it. So hopefully, and I'm pretty sure, 99.9% sure that it's going to be a lot easier for people to understand.

MAE: That sounds awesome. And if you end up needing a bunch of play testers, I bet a lot of our listeners would be totally willing to put in some time. I know I would.

Just want to put in one last plug for anybody out there who really loves automating things and is trying to avoid relying on any single developer, or designer, or QA person to remember to check for accessibility is to build it into your CI/CD pipeline. There are a lot of different options.

Another approach to couple with that, or do independently is to use the axe core gems, and that link will be in the show notes, where it'll allow you to be able to sprinkle in your tests, accessibility checks on different pieces. So if we've decided we're going to handle color contrast, cool, then it'll check that. But if we're not ready to deal with another point of accessibility, then we can skip it. So it’s very similar to Robocop.

Anyway, just wanted to offer in some other tips and tricks of the trade to be able to get going on accessibility and then once you get that train rolling, it can do a little better, but it is hard to start from scratch.

JOHN: That’s a great tip, Mae. Thank you.

TODD: Yeah, definitely.

MANDY: Okay. Well, with that, I think it's about time we head into reflections; the point of the show, where we talk about something that we thought stood out, that we want to think about more, or a place that we can call for a call of action to our listeners, or even to ourselves. Who wants to go first?

MAE: I can go first. I learned something awesome from you, Todd, which I have not thought of before, which is if I am eyeballing for “contrast,” especially color contrast, that's not necessarily what that means. I really appreciate learning that and we'll definitely be applying that in my daily life. [chuckles] So thanks for teaching me a whole bunch of things, including that.

TODD: You’re welcome.

JOHN: I think for me, it's just the continuing reminder to – I do like the thinking that, I think Mae have brought up and also Todd was talking about earlier at the beginning about how we're all of us temporarily not disabled and that I think it helps bring some of that empathy a little closer to us. So it makes it a little more accessible to us to realize that it's going to happen to us at some point, at some level, and to help then bring that empathy to the other people who are currently in that state and really that's, I think is a useful way of thinking about it.

Also, the idea that I've been thinking through as we've been talking about this is how do we get the ball rolling on this? We have an existing application that's 10 years old that's going to take a lot to get it there, but how do we get the process started so we feel like we're making progress there rather than just saying, “Oh, we did HTML form 27 out of 163. All right, back at it tomorrow.” It's hard to think about, so feeling like there's progress is a good thing.

TODD: Yeah, definitely and as we get older, our eyes, they're one of the first things to go. So I'm going to need assistive technology at some point so, yeah. And then what you touched upon, John. It may be daunting having to go back and do the whole, “Okay, what are we going to do for accessibility now that this project, it’s 10 years old, 15 years old?” The SAAS project that I was talking about, it was 15-year-old code, .net. I got people together; one from each department. We all got together and we ended up making that product accessible for them. So it can be done. [laughs] It can be done.

JOHN: That’s actually a good point. Just hearing about successes in the wild with particularly hard projects is a great thing. Because again, I'm thinking about it at the start of our project and hearing that somebody made it all through and maybe even repeatedly is hard.

TODD: Yeah. It's not something that once it's done, it's done. Accessibility, just like the web, is an ever-evolving media.

MANDY: For me. I think my reflection is going to be, as a new coder, I do want to say, I'm glad that we talked about a lot of the things that you see that aren't currently accessible that can be accessible. One of those things is using alt tags and right now, I know when I put the social media posts out on Twitter, I don't use the alt tags and I should. So just putting an alt tag saying, “This is a picture of our guest, Todd” and the title of the show would probably be helpful for some of our listeners. So I'm going to start doing that. So thank you.

TODD: You’re welcome. I'm just reminded of our talk and every talk that I have on a podcast, or with anybody just reminds me of the work that I have to do and the work that is being done by a lot of different people, other than myself as well, as far as advocacy goes in that I don't think it's ever going to be a job that will ever go away. There will always be a need for accessibility advocacy for the web and it's great just to be able to sit down and talk to people about accessibility and what we need to do to make the web better and more inclusive for everybody. Because I tweet out a lot, “Accessibility is a right, not a privilege,” and I really feel that to my core because the UN specifically says that the internet is a basic human and I went as far as to go say, “Well, so as an accessibility of that internet as well.” So that is my reflection.

MAE: I'll add an alt tag for me right now is with a fist up and a big smile and a lot of enthusiasm in my heart.

MANDY: Awesome. Well, thank you so much for coming on the show, Todd. It's been really great talking with you and I really appreciate you coming on the show to share with us your knowledge and your expertise on the subject of accessibility.

So with that, I will close out the show and say we do have a Slack and Todd will be invited to it if he’d like to talk more to us and the rest of the Greater Than Code community. You can visit patreon.com/greaterthancode and pledge to support us monthly and again, if you cannot afford that, or do not want to pledge to help run the show, you can DM anyone of us and we will get you in there for free because we want to make the Slack channel accessible for all. Have a great week and we'll see you next time. Goodbye!

Special Guest: Todd Libby.

Support Greater Than Code

01:19 - Adrian’s Superpower: Humor

04:57 - Employee Resource Groups (ERGs): What are they?

09:20 - How ERGs Operate

18:03 - Successfully Policy Implementations: Examples

23:18 - ERGs and Management / Executive Sponsor Partnerships

30:41 - ERGs vs Unions

34:19 - Inclusivity Training

Reflections:

Casey: “ERGs are only as strong as the management supporting them.”

Mandy: Live programming + fireside chats over slideshows for inclusivity training.

Adrian: Pushing ERGs and DEI initiatives to the next level is crucial and keeping these efforts authentic.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

MANDY: Hello and welcome to Greater Than Code, Episode 250. My name is Mandy Moore and I’m here with my friend, Casey Watts.

CASEY: Hi, I’m Casey! And we’re both here with Adrian Gillem.

Adrian is a Technical Project Manager with Booz Allen Hamilton focused on deploying next generation digital transformation capabilities to public sector clients in Washington D.C., Honolulu, Tokyo, and Seoul.

Beyond his technical client-responsibilities, Adrian’s true passion is grounded in diversity, equity, and inclusion program management and partnership building. Over the years, Adrian helped lead Booz Allen’s LGBTQIA+ and African American Employee Resource Groups to new heights; instituting new internal and external partnerships and programs under a DEI strategy committed to representing and empowering our BIPOC, Black, Indigenous and people of color, queer, and ally employees across the firm.

Welcome, Adrian!

ADRIAN: Thanks, everybody! Good to be with you guys.

CASEY: All right, we’re going to ask you our first question, we always ask. What, Adrian, is your superpower and how did you acquire it?

ADRIAN: [laughs] I've had to think about this. My superpower is humor and I only acquired it because I was able to tell the same bad jokes over and over to my friends and loved ones, and I've just stuck with the ones that people laughed at.

CASEY: Testing. You tested them live.

ADRIAN: That's right. That's right. They had no choice.

[laughter]

CASEY: How many of them did you get full on laughter versus nervous laughter versus glares, which were also a sign they liked your pun?

ADRIAN: Yeah. I would say that my sarcastic humor definitely got 70% eye rolls, 10% hm and has and then the other 20% were slight laughs, maybe a smirk, or two. But over the years, I hope that it's gotten better more in my favor. People tend to smile a little more when I make a joke, but can't say it's a 100% success rate so far. But we'll see. Maybe I will start my life career as a comedian in the next 10 years since and just retire from technology, or I'll just do both. Who knows, who knows?

CASEY: Yeah. There's space for that.

ADRIAN: There is.

CASEY: Multi-passionate. You can be multi-passionate; you're allowed.

ADRIAN: Absolutely. I can make live jokes and do live coding on a set. I'll probably do really bad coding, which will be enough for people to laugh at anyway, so I'll already have material ready to go.

MANDY: That's awesome.

CASEY: You've got me smiling and laughing.

[laughter]

Even just the levity you're describing is funny.

MANDY: Yeah.

ADRIAN: Thanks. I appreciate you both for already bearing with me. [laughs]

CASEY: So I have a feeling you incorporate humor like this into your work with employee resource groups. It's hard to imagine you wouldn't. Tell us something like that—some of the joke that you've told, some scenario that you've managed to reframe.

ADRIAN: Oh boy, that's a really tough question. I think the way I try to incorporate my humor, especially in my work with our employee resource groups within the firm and especially with our partners outside of our company, is just to make everyone feel comfortable through humor. You start to meet with different folks of different backgrounds for the first time, maybe even for the second, or third time, whether it be at your water cooler, or in the kitchen, or at an actual meeting where you're talking about a diversity, equity, and inclusion agenda.

Some folks might walk in and not necessarily know everyone in a room, not feel comfortable to speak in the way that they would like, or act as authentic as they should. So luckily for me, humor seems to break that ice very quickly. It's always very – in my case, I choose to do self-deprecating humor first and then that just gets the ball rolling in making sure that everybody feels open and welcome to be themselves in the space that I'm in.

But absolutely, in the ERG, the last place you want to have this stoic, maybe stale environment is an ERG whether it be an ERG meeting, or an ERG get together, or anything like that. You want to make sure that everyone feels very comfortable being in that space and you don't want to have as any hesitancy to that authenticity. So I try to do my best with making many people laugh, even if it is at my own expense and that's perfectly okay, I signed up for it.

CASEY: So for listeners who may, or may not have been part of an employee resource group before, an ERG, can you tell us a little bit about what it's like being part of one?

ADRIAN: Sure. So being in an ERG, it's an interesting mix. You either are in an organization that has had ERGs for a very long time and there are predetermined ways that it operates. There's a leadership structure. There are formal rules and procedures in place. There's a lot of hype behind it. Folks feel that it actually represents their interest and they can use that to communicate up. By up, I do mean up to management, senior leadership on ways they are not feeling included, or feeling equitably represented in a particular company.

And then there are other organizations where unfortunately, a formal ERG structure might not exist and so, you'll have situations where employees informally get together based on shared experiences, based on shared connections, based on shared racial identities, or gender identities, or sexual orientation identities. But they don't have a formal way, or a formal mechanism to do that.

So in our case, in organizations that do have formal ERGs, really what it is used for is to make sure that staff have an effective, measurable, an impactful organized mechanism to really share insights on things that are affecting them as an individual employee and share it across colleagues that also might be feeling similar impacts, or might have similar experiences.

To provide a specific example in this case, I lead, or I'm on the board, rather of our African American Network. That's what we call it. Really, it's focused on engaging our African American and more generally, our brown and Black persons of color employees across the firm to make sure that their voice is not just heard, but felt, that their impact is not just seen, but felt in the way our company operates and the things that we focus on and try to improve on.

In that, most of what I'll do is typically liaise with our employees that are, let's say, onboarding for the first time to the company and they want to feel connected to that wider corporate group. We are a company of 26,000 employees, so it's very hard to feel like I can connect with a bunch of people pretty easily.

So connecting with new hires via this mechanism of an ERG provides an easy way for folks to get together with a smaller subsect of our staff. But get connected with a subsect that actually looks like them, talks like them, has had shared experiences and memories and livelihoods and lives just like them and so, that's just part of it.

The other part of it is representing our respective employees and our members within the ERG and their interest to upper management, to our human resources division, and folks with just a stake in understanding what is impacting our employees that are particularly aligned to this group and how can we make their experiences better. But better in the sense that they're able to be more effective in their job, feel more authentic in their day-to-day, and feel more appreciated for the unique contributions that they're bringing each and every day that they support the work that we do.

So I think that's a lot and I'm happy to break it down even further because I think that this is such a really, really important element that companies that have it formally structured sometimes take for granted because they might not be effectively funding it, or giving it the oomph, I'll say. The energy and relevance to do that kind of impact that I'm describing that I feel is unique to Booz Allen. But in a way, it's also a call-to-action for maybe smaller or mid-size companies that, like you mentioned, might not have a formalized structure like this and yet have employees who want to band together and make it so, so they have a way to drive that type of impact I was talking about earlier.

MANDY: So you create these groups—people who look like me, act like me, are like me identify in the same way that I do and we see things, where do we go from there? We identify the things that we want, or need. Do we go management? Do we go to HR? What's the kind of, how is it structured?

ADRIAN: So that's a very good question. I think ERGs and really, business resource groups, depending on the company, have varied reporting structures.

In the case of Booz Allen, we as an ERG work very closely and almost hand-in-hand with our formal diversity, equity, and inclusion departments, our human resources specialists, our recruiters, all those within that part of the company, to make sure that what we're hearing at what we like to consider at the grassroots level is actually delivering change that can be felt by our employees.

Now, what that does not mean is that employees would somehow come to us as an ERG with let's say, a formal employee level, or human resource level complaint, and we pass it on their behalf. No, no, no. That's not really the focus. The focus really is to make sure that everyone, broadly speaking, has a chance to voice things that are really important to them and their situation—basically connected to their identity and however they choose to identify in a particular space so that we collectively can share those insights to departments and components of a business that drive that policy discussion and policy change in response to situations arising.

So in our case, in the wake of the increased exposure of Black Lives Matter protests across the United States, in the wake of the murder of our brother, George Floyd, in the wake of so many impactful events that have happened over the last 2 years, not to mention a pandemic that we're all kind of living through in our own way, ERGs have become the focal point to articulating what really is, or are the needs of our workers, our colleagues, our friends in this company—whichever company that you might work for—and how can we represent what they are actually dealing with on a day-to-day basis?

Because I think one of the things that we forget is not all employees feel comfortable to go to human resources with an issue. Not all employees feel comfortable going to management with an issue—and I speak as a project manager myself. Especially when it comes to particular situations that are specific to issues that might be affected by their race, by their sexual orientation, by their gender identity, and so on and so forth.

So an ERG provides that formal, but not management connected mechanism to gather all of those insights, gather all of those feelings, and tell a narrative that's structured, but impactful to the human resources and management leadership elements of a particular company to drive that change.

Now, all of what I’ve described is the ideal. That's the ideal way that ERGs ought to operate in a particular environment. But I am very well aware that some, if not a lot, of companies don't do it that way. They're playbook for employee resource groups is I one of two things.

Either you will have a loose band of employees that may have won, what we call, executive sponsor that doesn't have a lot of weight to throw on it and by extension, financial support, leadership recognition to then drive that kind of impact. And then another is where there is no ERG presence whatsoever. But in this context, I'm also still talking about big companies, larger companies, even companies at my scale where all of the discussions, all of these things that I've talked about are really just management led.

So to provide an even more specific example that I think we've all heard about time and time again, especially in the wake of all of what we've experienced over the last 2 years, a lot of companies just hire a chief diversity and inclusion officer and call it a day. That's their impact, or they put out a press release that says, “We are going to revamp our recruiting strategies and we're going to “do better” to represent our minority employees, our employees of minority, gender identities, or sexual orientations.” But at the end of the day, that doesn't really translate to a grassroots level initiative of that delivers that kind of change.

So taking it all back to your question of is an ERG seen as that formal mechanism to interface between staff and human resources? It is, but only in the context of with it, we can get a lot more critical insight that feels more authentic, that is more authentic, because it's driven by our employees, vice waiting for one or two employees to feel comfortable going to HR directly with an issue, or concern and not really driving that kind of impact the way we would like to.

CASEY: It reminds me of the phrase “build with, not for.” So the second scenario where you just hire a DEI officer and they just do it on their own without including the people who are affected is like a build for. But if you get people involved who are affected without forcing them to either, which is the other end of the spectrum. [chuckles] Like you’ve got to invite them and they have to accept it and be content happy working with it. Maybe you have time.

I'm wondering, do you feel like you have working hours, time dedicated you can spend on the ERG work, or do you squeeze it in between everything you do?

ADRIAN: That's a good question, actually and a good point to bring up. I, myself, am very passionate about this stuff and I love doing it. So even if I feel like I'm adding on to my day-to-day work, it's not really a big deal for me because I know that what I'm doing is driving an impact that I am very, very excited to do each and every day. But more importantly, I get to go to sleep at night because I know that I'm just not doing a day-to-day job, that is doing day-to-day monotonous work, that there is a value add to it that I'm able to do liver to my colleagues, my friends in my company, and send a clear message of what I stand for and what I want to represent, what I want to share.

But for others, and especially in some corporate environments, you might see two structures. One structure is companies might devote to each employee a set number of hours that they can use to do what we'll call volunteer work and sometimes, this volunteer work may include ERG support, or ERG leadership, or program management, or event management. Others do not. So other companies expect that you focus on your day-to-day and anything you do outside of that is volunteer work that can be tracked, but there is no formal mechanism to track it.

At Booz Allen, and I can at least speak for our company specifically, we actually have a requirement almost and if not a push, that's been significantly increased the last year to leverage what our employees are doing in ERGs across the firm to help advance their case for promotion, for role change, really, it's to make sure that our employees are feeling like even if they are doing this as a volunteer role and it feels it is on top of their day-to-day, that there is a value to it. It might not just be value that they feel internally, but rather it's also value that is shown up at the end of the day, when they're up for promotion, or they're looking for an expanded role, or they're looking for a reward for the comprehensive effort that they're putting into the company.

But I think, by and large, most people don't focus on that because for a lot of ERG work, it's just because you want to do it. You want to make your fellow colleagues heard, and you want to use the leadership and the voice that you have and the willingness you have to articulate their message on their behalf, and you want to do it well so much so that if it takes a couple extra hours, a week, or a month, it's worth it.

CASEY: Cool. I love having the whole overview. I've got a clear image now.

ADRIAN: Yeah. [laughs]

MANDY: So tell me a story. I like stories, okay. So I was wondering like, if you could give a specific example of something, a policy that an ERG advocated for that you're a part of and that it got changed, or improved, or something? Like, is there a specific, “I want this,” and then what happened?

ADRIAN: Sure. Actually, [laughs] I could give you like 15.

MANDY: Go for it.

ADRIAN: But I'm going to boil it down to the one that I remember most and that really was a policy change that was implemented in, I think it was late 2017 perhaps, or maybe early 2018 where we were pushing for expanded, I would say, healthcare policies—I should say we say—better healthcare coverage for our transgender employees, one and on a side to that, trying to figure out how do we better represent our transgender employees who want to transition while working for the company and make sure that their benefits are covered. But also, articulate to the company, what are those benefits? What do they need? What are their healthcare needs? What is, or should be the needs that happen in the workplace outside of just healthcare? Things of that nature. What is a set list of guidance that Booz Allen can use to better represent and better support transgender employees?

So GLOBE, which is the LGBTQIA employee resource group at the firm, was at the forefront of that. We were taking the lead role in coordinating with our employee retention staff, human resources staff to articulate what exactly those needs will be and make sure that it is implemented in a timely fashion. What I mean by timely fashion is a lot of these initiatives that maybe ERG led could take months, if not years. But in this case, we were able to expedite it because we had built partnership with our HR departments, with our entities that could actually implement the kinds of policy changes we wanted for our transgender employees.

So based on our guidance, we were actually the ERG task with developing those initial guidelines and guidance on what should be medical coverage options for our transgender employees. In addition to that, we also set out guidance on what are the things that transgender employees want out of their management? What are the expectations on how they would like to be treated, how they would like to be addressed, how they would like to operate in our environment, in our corporate environment? So we set all of that up as one package that we were able to successfully route up to our leadership.

Again, I might be providing a cavalier-sounding story, but one thing I want to make sure everyone understands, and especially your viewers, is that we are a company of 26,000 people so making any change quickly is very hard. It takes an enormous effort.

So the fact that we were able to start from a piece of paper and one partnership and scale that up to an entire LGBTQIA board like ours, our leadership, and a set of sponsors at the human resource and management and leadership level at our company to also include our Chief People Officer, Betty Thompson, in span of just months was absolutely remarkable.

In fact, we were able to make that implementation, that change in time for our next pride summer session, which is really the hallmark and really, the focus that we had as our target. So by 2018, we had formalized the process, we had formalized these new changes to the policy, but the focus point was it was an ERG that led it. We led the discussion, we led the change, and we made the coordinated effort and we carried it along the finish line, along with our helpful partners in human resources, and especially under the leadership of our Chief People Officer.

I don't want to sound like I'm drinking the Kool-Aid too much, but I was really glad that we were able to do that because it's stories like that that made me want to stay working for not just my company because I think all companies try to do good for their employees in one way, or another. But it made me specifically want to stay on the board of our ERG and continue supporting the work that we were doing just because I got to see what kind of impact we can actually do if we work together with them and actually empower them to do the type of work that we hopefully intend for them to do on a regular basis.

MANDY: That's awesome.

CASEY: Yeah, great story. I'm impressed.

ADRIAN: Yeah, don't be impressed about me. Be definitely impressed by the team that I was with. I was a member of the board, but it really was a collective effort, which is usually the story for all ERGs across most corporate environments.

CASEY: I'm impressed with the structure that's set up that incentivizes all of this to happen. The ways that it should to have the people involved who are affected and all that, that is so cool. It's a good structure.

ADRIAN: Yeah, no, it was. [chuckles] I would say that it was a hard-fought battle. I don't think anything like this is easy. One, because one thing for, I think for all viewers to keep in mind is that employer resource groups are only as strong as the management that's supporting them. So that's why there has to be this partnership, this very strong tightly knit partnership, not just amidst the grassroots level members of the ERG, but also, the executive sponsors that you have behind it.

What do I mean by executive sponsors? Because I brought that up a couple times when I was bringing up some of the stories. Typically, you hear the term sponsor and you might think like a brand sponsor, or for, I don't know, a sports event, or something like that. In our case, program, or executive sponsor is a dedicated leader within the company who provides strategic level direction, more important funding, to make sure that our activities and our ability to operate continue unabated.

So it took a lot of time, effort, and number of years for Booz Allen, and I can say that confidently, to recognize the importance of having a tightly knit, but influential set of executive sponsors aligned to each ERG. What I mean by that is some ERGs have two, or three vice presidents that have access to budgetary resources to fund events, programs, and partnerships that we'd like to do in a particular fiscal year. Others might just have one, but that one might be the Chief People Officer of the whole company.

So all of that is very, very critical because having a formal structure, meaning you have a board chair, or you have a board member set up and members is good. But at the end of the day, if you don't have a backing behind it, or help your organization, or your ERG be more influential, unfortunately, can almost appear like a club. People are going after hours, having a good time, but they're not really making change they want to see in their company.

So you always, always, always, if you're trying to stand up your own ERG within your small business, or in your mid-size business, or trying to even improve the effectiveness of your ERG in a large company, if not larger one, you want to make sure that you have executive sponsors behind you who have the backing of your C-suite leadership and can help you and your team really affect the change that you're trying to affect.

But in our case, we just got lucky and over the years, we've had pretty solid relationships with our executive sponsors. They're pretty cool people. I must say Betty, our Chief People Officer, she's pretty awesome. I remember talking to her for 20 minutes during a trip about Prada bags. If that doesn't tell you about my superficial love of Prada bags, I don't know what will.

But it is good and I think it is continuously great that we have that type of representation, have that type of backing, and I think that should be almost commonplace for most organizations.

CASEY: This reminds me of two things I want to share. I think you'll find them interesting.

One is this idea of executive sponsors reminds me of how in high school, when you have afterschool groups that students want to self-organize, they need a teacher to sponsor it, or they cannot do it. They cannot stay in the classroom. Even if the teacher doesn't do anything, they don't have to do anything necessarily. The students can maybe run their club, like practicing improv from things they found online, but they need a sponsor. But it's even better if the teacher is involved and they're actually teaching improv, or whatever the afterschool activity is. A friend of mine is a teacher and does that so, I'm thinking of her.

It's interesting; you need that support for things to get done and you don't need babysitting in ERGs, but you do need it for other reasons like influence. They can influence a whole lot.

That reminds me a little bit of my friend was telling me about a choose your own story adventure game that Harvard Business Review put out where you were trying to make change in an organization like Trans Healthcare, or something like that. And then how do you do it? You make all these choices. Two things that surprise me how impactful they were, like those scores were way above the others, were the leadership support that you're describing and external consultant support. Even if—we know the story—the consultant says what the employees say gets done.

So it's funny, either source of authority can have a huge impact. We like to ignore it, but it's really powerful and we shouldn't ignore it if we want to get of things done. However you got it to happen at Booz—I'm sure it varies by company how you can get the support, what it looks like—but that's really powerful.

Were you around for that part before you got Betty on your side?

ADRIAN: So, [laughs] no. Unfortunately, when I came in, we had already had a pretty strong relationship with Betty. It seems like Betty was ready to go and support everyone, which is always great. So no, I didn't get to see the lead up efforts to having to influence all of our leadership to provide that backing.

But I think that speaks to the enduring, I would say, commitment that that Booz Allen has to our employees via these employee resource groups. Because specifically, even as early as the 90s, Booz Allen had set out a policy to, in this case, specifically recognize support and empower all our LGBTQIA employees. Something that was completely unheard of in the time for a lot of companies that, again, were existing in the wake of Don't Ask, Don't Tell, the Defense Against Marriage Act, et cetera. Our company, for an enduring period of time, has made a very strong commitment to representing our LGBTQIA employees and making them feel not just welcome, but empowered and making them feel like they have someone on the CEO leadership level in their corner ready to defend them.

But I wouldn't want to just talk about my company only. I feel that, by and large, we have seen a significant uptick in major brands, over the last even 5 years, making stronger statements, making stronger efforts, making more substantial improvements in how they operate and engage with employees of diverse backgrounds. The respective ramp ups for them probably are very different than what was it was for Booz Allen, but I imagine, at least I would hope, that of those companies, ERGs played a role in making that lead up a little bit easier. I haven't worked in every company in the United States. I don't think everybody has.

CASEY: Oh, not yet.

ADRIAN: As much as I would love to.

[laughter]

Not yet, not yet, but I would hope that the story is probably the same across the board; that it wasn't just a decision made in a vacuum by some director CEO, that it was a coordinated effort partnered by an employee resource group operating at that grassroots level capacity.

CASEY: Yeah. I believe that it's got to come from the top and the bottom. If you just have one, or the other, it's not really going to go far.

ADRIAN: No, it's going to hit an impasse, it's going to stop on the train tracks like, if you're on Washington Metro.

CASEY: That single tracking red line, yeah. I’ve been there.

ADRIAN: That's right. That's right. [laughs]

CASEY: This all reminds me a little bit of unions, but it's not unions. ERGs are not unions. They're different. They don't do formal requests, like you mentioned, complaints. But there is some formal structure; there's funding coming from the company. That's even the opposite of unions, too. But I don’t know, something about it feels similar. It's like, people coming together to support their points of view.

ADRIAN: Yeah. In a union, obviously, there's a membership, there's a formal charter, there's your set union president—they negotiate on your behalf for the company to do things that you want. You're absolutely right. Outside of the legalese language, if you will, there are very much a lot of similarities and even historical connections between unionizing and employee resource groups.

Really, the only difference rests in what is the collective bargaining capability between the two. ERGs do not bargain in any official capacity, but unions do. But you still have absolute value in formally standing up and empowering and strengthening your ERGs in the same way that you would recognize the inherent legal power, legal capabilities, and legal recognition of any union that your business might be dealing with.

It's a very good point you bring up because a lot of times, folks just feel like ERGs are that thing that they might get an email about and hear an event about, but maybe not think twice about it because it's not impacting their day-to-day. As in, it's not impacting their salary, it's not impacting their livelihood, their employee experience at a particular company. But one thing people forget is that half the time, these ERGs are the reasons why companies have events and programming opportunities that talk about different ways to grow in a firm.

For example, the women's group of Booz Allen tends to be the leader in hosting a lot of events that talk about networking, career empowerment, career improvement specifically for women in the workforce. Now they might be targeted to women who work within Booz Allen, but the message is broad and the message far exceeds the walls and halls of our company in that they want our female colleagues, regardless of where they might see fit physical location wise, to succeed equally. But that also comes with the equity part and I think that equity part is what makes kind of union like efforts that ERGs play in our companies so important because equity is what makes sure that regardless of the situation, we are going to give you the resources that at respond to your situation and give you the tools to succeed in spite of whatever you might be dealing with.

Whereas, before diversity and inclusion departments would just have an equal way of responding to a thing, but the way that they wanted to solve a problem might not necessarily work for Black and brown employees, the way they want to solve a problem might not work with women, employees, or Black female employees.

So to bring it all together when we're talking about [chuckles] the union-like functions of an ERG, you're absolutely right. We have organized ways to deliver mechanical if not systematic change, but change that have an impact and that impact every single member that might be tied to a particular group. But we also do it in a way that's structured. We do it in a way that ensures that there is an impact that can be felt in and outside of the organization.

CASEY: This also makes me think about inclusivity training like a lot of HR departments give to their employees. I've heard mixed reviews, but the content's good. We want the content. People want to know how to treat their coworkers really well. They want the awareness of what to say and not to say to people. People like that, that I've worked with.

But a lot of the HR training often is like a PowerPoint presentation online that gets tracked, how many slides you look at—it's very cookie cutter and no one wants to talk about it afterwards, or share notes and that helps a lot, if you can talk about things. Anyway, it doesn't feel as impactful as it could be. Do you have experience with inclusivity training like that and does the ERG work in interact with that any?

ADRIAN: Yeah. So that's actually really interesting because a lot of companies are struggling with that. How do you bridge the gap between diversity equity inclusion and at a very large scale in making it as generalized as possible, but still target the employees that it matters to the most?

So a lot of trainings now, especially as we're in a remote environment, are just like you said, just a lot of PowerPoints, a lot of online trainings. You’ve got to click through slides on a video and hope to God that you can actually click and fast forward past the slides because if you don't – [overtalk]

CASEY: Oh, yeah.

ADRIAN: Then you’ve got to actually wait through the slide and nobody wants that, but – [overtalk]

CASEY: Just with a transcript. That's accessibility. [overtalk]

ADRIAN: That’s exactly right.

CASEY: When accessibility makes that happen, I am so happy. I can read so much faster than listening.

ADRIAN: Absolutely. I have read so many books and that has proven to me that I can read through a transcript faster than listening to a [chuckles] slideshow presentation.

But what our ERGs try to focus on is live programming and I think that's the big distinction here because a lot of mechanized training programs that companies try to offer in diversity and inclusion, sensitivity training, inclusivity training, they're bound to systems and applications—technology that delivers the widest variety and the widest accessibility possible.

Whereas for us, our focus is really just targeted to live events with speakers, fireside chats, having our members do round table discussions where we're bringing together our members to talk about the things that they want to hear. We're more flexible in that we actually can of course, solicit and obtain topics that our employees want to talk about and have experts connected to that, whether it be inside, or outside of the company, to share their insights and share their expertise.

The reason why I think that's so valid and so valuable is you ensure that the audience actually can connect to what you're talking about and they see a face behind it. They don't see a slideshow with a portrait of a guy, some weird just stable figure with a suit doing weird static things that's supposed to action an image. That doesn't do it anymore. Nobody wants that. People want live programming. Folks want to see someone that looks like them, talks like them, has lived experiences like them, share insights that can relate.

So for us, now more than ever, we have been doing a lot of fireside chats with Black and brown authors, queer authors in the space to articulate the creative side to anti-racism, anti-LGBTQIA hate, things that our employees want to hear as an ERG, but don't want to see via slideshows that management puts together or has an outside consultancy or vendor put together.

In fact, one of our more recent events that the African American forum, or African American Network, rather in partnership with GLOBE, the LGBTQIA resource group I mentioned earlier, we recently put together a live event focused on queers in the workplace. Specifically, queer people of color in the workspace and we targeted this specifically to focus on how are our brown and Black employees operating in a not just telework posture, but how are they feeling?

How are they feeling with their colleagues? How are they feeling working with their supervisors? How are they feeling working with their clients? Do they experience, or are they experiencing, or have they experienced issues where they didn't feel welcome in a particular client space? How are they dealing with responding to issues that management needs to hear about, but in a telework environment where the only thing you can do is set up a Zoom call?

Those types of conversations can't be had effectively in a slideshow presentation that you're doing on a webcast. These are things where you want and have to have a grassroots level organization that is formally structured articulating the message, and having people who live those experiences articulate it for you and with you, and have that live dialogue to where your staff can feel that they're learning about the inclusivity that your company is trying to enforce, but actually have it stick because they heard it from a colleague. They actually heard a story that connected with them.

I think that's one message I would want to harp on the most is that all of what we do and by we, I do mean the collective ERG enterprise, regardless of whatever company you work for, that's the focus is messaging. You want to make sure that your ERG is sending a message that when that employee joins it, or when that employee participates in an event, or when that employee sees the ERG's name, they know that it represents authenticity. It represents a connected feeling that they can take back and say, “Hey, if I don't feel comfortable going to HR, but I know that I can have a voice to hear my issue that looks like me, talks like me, sounds like me, but in my own company,” then that's exactly what we want to send. That's the type of manage we want to ring home.

MANDY: Absolutely!

CASEY: Yeah, that sounds great. That reminds me of a panel we did together before, Adrian. Years ago now.

[laughter]

Tech Talk, D.C. We did Queeries in Tech. Queeries like queer, but also like the tech pun, like the aQueries.

[laughter]

ADRIAN: See. You see, Casey, you're going to take my bad joke job away from me. I’m

CASEY: We work together here. We're collaborative.

MANDY: I love it.

ADRIAN: That's right.

CASEY: Build with, not for.

ADRIAN: Yeah. I feel like I've been saying the same message, though since our last talk. So I’m at least improving that I'm consistent if even if my consistency falls on deaf ears from time to time.

CASEY: That's okay. Repetition is key to influencing this kind of level.

ADRIAN: That's right, yeah. That's what my music teacher used to tell me, when I was singing really badly, “Just say the lyric and sing it louder and over and over, you'll get that.”

CASEY: Yeah.

ADRIAN: “Don't worry. Somebody will listen to you.”

MANDY: That's why you’ve heard 250 episodes of this show. We [laughs] say it all over and over and over again in hope that people will pay attention.

[laughter]

CASEY: Yeah. Slightly different perspective, but always similar themes. It's true.

ADRIAN: That's right. Well, I hope it's this lucky 350th episode that somebody finally listens to it and says, “Ah, I get the message. I get what they're talking about.”

MANDY: We're only at 250.

ADRIAN: 350 times, but here I am.

MANDY: We're only at 250.

ADRIAN: Oh, 250? [overtalk]

MANDY: But maybe a 100 more times. [laughs]

ADRIAN: [laughs] Okay.

CASEY: I think this episode, we will get some ERGs at companies that didn't have them from this episode. I'm sure. People listen to it not just when it comes out, but for a long time afterward, it still comes up. I don't know, but we'll find out. If anyone does, let us know. We'd love to hear a success story, or even a challenge story where you just sang the notes wrong a lot. I’d love to hear that, too.

MANDY: Please add us.

ADRIAN: Yeah. Or even then, I would love it if your users could even share their experiences with their own ERGs.

CASEY: Yeah!

ADRIAN: Because my experience is not the only experience. I am obviously well aware I'm talking from the perspective of a member of two boards. So I imagine others might have different experiences and those are valid. Those are absolutely valuable because whatever insights you share about your experiences with an ERG, those are the experiences we want to hear so we can improve on them collectively.

It's a valid resource to have, but it can only be grown better if we have that kind of grassroots contributions on a regular basis. So don't be afraid. I always tell people, “Don't feel bad to tell me I'm doing something wrong because if you don't tell me I'm doing something wrong, I'm going to continue doing it and I won't know.”

CASEY: Yeah, I'd love to hear more people's stories.

MANDY: Yeah, and if anybody's out there that has one of these stories and wants to come on the show to talk about it, please get a hold of us because we love telling these stories, like I said, over and over and over again because that's how change is made.

CASEY: We want your voice. You can reach out to us on Twitter, or we also have a Slack community you can join. Greater Than Code Slack; you can find the link to that on our website greaterthancode.com.

MANDY: Yes, and it is a Patreon donation, but if you DM one of us panelists on Twitter, we will let you in regardless if you decide to sponsor us on any kind of basis, or not. We let everybody in as long as you, too are greater than code.

CASEY: Ding! Love it. Adrian, you'll be in soon.

MANDY: Yeah.

CASEY: We’ll bring you in.

MANDY: Yeah, he'll be in.

It sounds like this is a good time to move over to reflections for the episode. We usually let our guests go last, Adrian. So Casey, do you want to give us a start?

CASEY: My takeaway is Adrian, you said the sentence, whether you remember it, or not, “ERGs are only a start wrong as the management supporting them.” That's so true.

ADRIAN: Yes.

CASEY: I've tried to do changes so many companies from the grassroots level without the opposite of support, whatever that would be. No one was shutting us down, but if no one was supporting us from above, it didn't go that far and that's a recipe for frustration.

MANDY: For me, I really took away how the live programming over slideshows is so important. Just having the fireside chats and the round table discussions, inviting people who are behind the scenes advocating for this stuff on the frontlines is just much more impactful than sitting there through a slideshow a first day of training like, “This is how we –” we already know all this, okay.

So having that audience connection and being able to be interactive, I think is really important way to handle and get things done and not just being sat at and talked to. Being like, “Okay, so, let's have a discussion.” Open it up to the audience and do a back and forth. I love panels for that reason is that you can just feed off each other and yes and others and I feel that that's really good way to go about things.

ADRIAN: Absolutely.

At least for me, I have been just awestruck, I would say, especially on all of the conversation points that we've had so far, but most specifically the fact that we can share in the article that Casey had mentioned from Harvard Business Review and honing in on that idea that some organizations experience that ramp up where they have external consultants, they have external influences, internal influences, all trying to come together and figure out what's the best way to push an ERG, or a diversity, equity, and inclusion initiative, or effort to that next level. Get their employees a bit more engaged. They feel a bit more represented, feel a bit more committed to the mission that the company is trying to get after because it's so crucial.

The one thing I would add to that, as part of a final note for me, is for any company that is doing ERG work that has some formal structure, or even if you are a small business, or mid-size business and you have employees that are even talking about it, or hearing about it, make sure that that effort that either is already there, or you're seeing it grow into something, remains authentic. That it has authenticity tied to it and that authenticity can, will, and only can come from the employees who put it together.

So make sure that if the employees say want an ERG, make sure that they're absolutely committed to it, all facets of it because it's a lot of work, but it's good work. And if you have a preorganized and structured ERG that just wants to take it to the next level, make sure that you have management and executive sponsors who also believe in that vision for authenticity.

I think we, as queers and allies in tech, need and see authenticity. We recognize it all the time and every day and everything and everything we say and do that is also represented in the employee resource groups that do such good work, but can only do such good work if there's an authentic passion behind it.

MANDY: I love that. You're so right. A 100%.

CASEY: I have a feeling you've said some of this before because it's so polished and clear. You're articulate, Adrian. I love it.

ADRIAN: I honestly have thought about becoming just a dish jockey and just going on radio and then just quitting my day job. But then I realized that would only be successful for maybe one episode and then I would just get boring and then I would forget. [laughs] So I'm going to keep my day job. I'm going to leave you two as the experts on this stuff and I'll just keep saying the same message for the next few 100 years and hope somebody listens.

MANDY: Well, thank you so much for coming on this show. It's been wonderful.

CASEY: Thank you.

MANDY: You have been amazing in explaining all of this. I've honestly never heard of ERGs before. That's why I just sat here and was listening like, “Yes!” Thank you so much for talking about it.

ADRIAN: Sure.

MANDY: And you are welcome back on this show anytime!

Special Guest: Adrian Gillem.

Support Greater Than Code

01:19 - Chad’s Superpower: Making People Laugh

03:46 - #TechIsHiring

31:03 - eSports and Software Engineering

Reflections:

John: The simple act of connecting others with a hashtag.

Mandy: Follow @GreaterThanCode for new content and RTs! Amplify others.

Mando: Drawing comparisons and connections between playing fighting games and software development and engineering. Bringing experience from one realm to another.

Chad: The possibility of being a connector in a professional sense and the validation of comparing fighting games and software development as a discipline worth talking about.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

JOHN: Welcome to Greater Than Code, Episode 249. I’m John Sawers and I'm here with Mando Escamilla.

MANDO: Thanks, John. Hi, and I'm here with my friend, Mandy Moore.

MANDY: Hey! And I’m here with our guest, Chad Stewart.

As a software engineer and esports athlete with many years of experience in both fields, Chad dives deep into issues that he comes across, drilling down to the core of a problem and finds solutions others may miss, letting the lessons of the journey guide future expeditions into the unknown. If you’re confused at comparing esports to software engineering, you’d be surprised at how similar they are.

Welcome, Chad.

CHAD: Thanks. Thanks for having me. I never imagined that writing that [chuckles] and it being literally the thing introduces me on a podcast. Wow, I’m sorry, I’m a little mesmerized.

MANDY: I really do want to ask about how we compare esports to software engineering. But before we do that, we have to ask our standard question that we ask all of our guests, which is what is your superpower and how did you acquire it?

CHAD: So, funny enough, I listened to a few episodes before coming on and I wanted to tell a silly joke, but that segues into what my superpower is, is I make people laugh. That's just something I like doing, it’s a big thing for me and I guess, I acquired it by watching Cartoon Network way too early in my life [laughs] and just being, I don't know, I just enjoy making people laugh. I enjoy making myself laugh and I guess, it's just fun. To be honest, that's what I kind of do on Twitter all day, make people laugh.

MANDY: That's awesome. That's a great coping mechanism. Especially these days, I find myself doing the same thing, trying to make light of situations so things don't seem as dark. [laughs]

JOHN: Years ago, a friend of mine, it wasn’t exactly a criticism but he was like, “Man, you’ll laugh at any joke,” and I'm like, “Oh, that's the option. I can either laugh more, or I can laugh less and I choose more.”

MANDY: Yeah, I always say I'd rather laugh than cry about it.

CHAD: I completely agree. There's so much sadness in the world at the moment. We've been in this pandemic for an extended period of time now and there's been people who've lost family members and friends, people who've lost livelihoods. Obviously, comedy is not necessarily going to fix all of that, but at the very least, it makes it easier to deal with those problems.

We were all hoping that we were going to come out of that this year and it feels like that's not even going to happen. There is some level of normalcy, but long story short, definitely I'd much rather see people smiling and having a good time and if I can add more of that into the world, then great. Just trying to make people laugh and it's fun, it's good for you. It's physically good for you.

MANDY: That's awesome. So I know that I reached out to you to come on the show because I wanted to talk to you specifically about, I think it's something you started around the beginning of the whole pandemic situation, The #TechIsHiring hashtag, do you want to talk about that a little bit?

CHAD: Yeah. So #TechIsHiring is a hashtag that is specifically for job seekers and people who are looking for candidates for their jobs. What I noticed is people would post their jobs, or post that they're looking for a job on Twitter and depending on how strong their network is, it would get a lot of traction, or not so much traction at all.

So I was thinking, there are people out there who are maybe looking for work and to be fair, it started mostly from that in the first place. More people are looking for an opportunity and posting about it on Twitter and if their network isn't very strong, or for whatever reason, the tweet doesn't get a lot of traction, then it may potentially become difficult for them.

I started the hashtag so that if I saw a tweet like that, I could add it to the hashtag. If you have a job tweet that you're looking for somebody to fill this position, I’d just go out and ask if I could add it to the hashtag and if you say yes, I just tag it with #TechIsHiring and obviously, the same for if somebody is looking for an opportunity. It's been fairly successful like within the last couple of weeks, there've been a lot more usage of it.

I don't necessarily have great ways of coming up with data on obviously how, if people are really benefiting from it outside of me maybe probing to see, but for the most part, I have the Twitter bot that I created for the hashtag. I have notification alerts for that and it's like my phone goes off all the time with notifications and I'm just like, “Hey, at least people are using it and people are retweeting it.” So I'm pretty happy about that. There's a few things I'd like to do to kind of expand it, but I'm definitely happy with where it is right now.

JOHN: So you're saying that the need you saw was that people are posting about that they're looking for a job, but maybe their network isn't particularly good, or they're not getting a lot of reach out of that and so, they're not really getting the benefit of all of Twitter being available to them. So you wanted to create this way to amplify those tiny voices that are saying, “Hey, I need a job.”

CHAD: Yes, yes, yes. To be fair, the #TechIsHiring, it's growing, but ultimately, what I wanted to be is pretty much the thing that people can rely on. You know what I mean? So in essence, I want to build the network for #TechIsHiring so I go and look for like jobs and for people who are looking for jobs, I will actively go and search for them on Twitter and initially, this was to add to the hashtag because obviously, the hashtag didn't have too much when I started it and it's just become a habit of mine.

There are definitely some people who are looking who, by the time I get come across their tweet, which may be even a week after they've done it, they've maybe had two, or three, or so retweets and likes. I was like, “Hey, if I add this to the hashtag, maybe at the very least, people will see it.” My network is decent. It's not the best I'm not super Twitter famous, but I have a fair amount of people that follow me.

So what I do when I'm asking is I always make sure to like and retweet whatever I find and ask so at the very least, other people on my network could see it and so, even if they don't reply—and to be fair, some people don't reply for whatever reason, maybe they never see it, or whatever. But even if they don't reply, at least some people are seeing it potentially and even a lot more now, I will retweet some people's job postings, or some people's looking for jobs tweets and people will retweet it themselves.

I'm just trying to, I guess, be that bridge, or I guess, middleman. I don’t know, I can't come up with a better term, but I've just tried to be that person that helps because it's like, everybody's kind of been there. Like, you're looking for a job and you're doing your absolute best and you're stuck with whatever information you have. Information, or resources you have and it's like, if I can make this thing so that people can of latch onto it and use that, then maybe a lot more people can get in contact with somebody who can offer them an opportunity. But that's pretty much it.

MANDY: That's awesome. I used to use the Greater Than Code account to do a lot of that—amplify the voices of others—and I used to be on Mondays, I would go and fill a buffer queue of just content that I found on the internet that I could retweet others. Ever since my daughter got “laid off the school,” that's been a little more difficult, but I'm hoping that in the near future, I can start that up again and do the same thing with the #GreaterThanCode hashtag.

But what you're doing, it's not easy work and it takes time to sit there, look, curate, put all that stuff together, and then amplify it out and get people to notice it, and engage with posts and it’s hard work. So thank you for trying to be that bridge and trying to use your network for good. I think that was awesome and part of the reason I wanted to get you on the show was because you've been doing it for a really long time and you keep up with it and it's amazing.

CHAD: Yes. Thank you, thank you. There's a few things that I want to do like, I would like to reach out to more employers and it’s just always an awareness thing. I just definitely like to reach out to more employers and be like, “Hey, there are candidates here who are tweeting on Twitter and they're in this hashtag, you can look through that.”

I kind of do it, but I do it like – so I was thinking about it the other day and to be honest, I actually did this way before I actually officially started the hashtag. When I first got on Twitter, or at least when I first got on tech Twitter, what I would do is I'd be doing the Twitter thing and just kind of oh, this person's interesting so I'd make a reply and have maybe a small conversation. And then I would see somebody who's like, “Hey, I'm looking for work,” and I was like, “Hey, I passed the thread that's talking about all of these jobs.” So I’d just link it to them and I was like, “Hey, hopefully, they'll get something out of it,” and I just did that.

That was just something that just came to be naturally like sometimes I'll be on Reddit and they'll be like, “Oh there was some job posts here. I'll just link it to this person, they're looking for somebody,” and I guess, it makes sense that I ended up making a hashtag to do that in a more official capacity as opposed to one off.

But what I definitely want to do is just to reach out to people, or to more people actually who have positions and I probably should reach out directly to the people who I'm retweeting who’s saying that they're looking for people and link people, especially people who I've already retweeted and be like, “Hey there's a candidate here,” and just stuff like that. That's something I want to do.

There are a few organizations that talk about jobs on Twitter a lot and I want to reach out to them and just ask them if they could use the hashtag. I tend not to mess with them too much because they're out trying to make money and so on and so forth, and it feels kind of weird. I don't want to retweet their stuff. I don't know what their marketing plan is. But I just want to reach out to them and be like, “Hey I'm doing this thing” because I don't have any numbers on who benefits from the hashtag. It's all in hopes of type thing. So I just want it to be a little bit more direct with, “Hey employers, there's actually people here that you can look at.”

So that's pretty much the direction that I'm hoping to go in while obviously, also, actually adding opportunities and people who are looking for options. But hopefully, people start doing it on their own, which is the ultimate goal is that I don't have to curate it myself because everybody understands that it exists. But for now, I don't mind doing that work.

MANDY: So I love the fact that you're a connector in that sense. That's what I consider myself and what I would do before actually being a host/panelist on the show. I feel like you should really hook up with this person and talk about this thing because do you know this person? And then I've had so many people come back from conversations with all the people that I've hooked up on podcasts and they're like, “So-and-so is like my new best internet friend now, thank you so much for introducing us.”

[chuckles]

I love being able to take people and being like, “You like this, you like this, do you two know each other?” and forging relationships like that. That's one of my greatest superpowers I feel so it seems like you're in the same boat, which is really cool.

CHAD: Yeah. I would definitely say that I've been doing that for some time more in an unofficial capacity. It's more like, “Oh, this person needs something. I know somebody who can help with that.” So I go, “Hey, this person needs so-and-so,” and I just bring them together.

I haven't been doing it too much of late. Well, I guess, I have because of the hashtag, but I haven't been doing it too much lately because I feel like the tables have turned; I'm the person that's in need more often than not. But it's definitely something I would definitely like to do more. Again, obviously I'm doing it with the hashtag, but it's definitely like, I've always been like that even as a kid. I've just always been the person who will just help just for helping’s sake.

I'm not necessarily trying to like, “Oh, I'm going to help you so you can help me.” Like, no. “You need something. I think I can help you with that. What can we do?” I don't know, I like working to benefit people. I feel good doing that. You know what I mean? You hear people like, “Hey, things really worked out because of what you did,” and I'm just like, “Hey, I'm happy I could help.” I've always been like that since I was a kid and I intend on continuing to do that professionally.

I guess, now that you bring it up, I'm like, “I really should think about it more actively” because I do it very passively. It's usually, I have a friend who’s looking for a specific job and I will just be minding my own business on Twitter and then I'll see a job that looks like something he wants and then I'll just send it to him. [laughs] He'll give me his reply and he'll be like, “Oh, thanks for thinking about me.” It's like, “Yeah, no problem. I just want to help.” I've always been that person.

MANDO: I'm really glad you said that because I've been hearing you talk about how much you get out of this in addition to everything else that other folks get out sparked this question in my head, which was that have you thought about doing this professionally? Because there are a lot of people who get paid very well to do this kind of stuff very poorly and so, I wonder [laughs] if someone who knows someone who does it well and actually has a love for doing this kind of stuff, if you thought about making this an actual full-time job.

I just went through a hiring process and we just hired an engineer over here. I would gladly engage with recruiters that I knew were doing the work that you're trying to do as opposed to folks that are just downloading whatever they can off of Indeed, or other resume sites and tossing them in my face with little to no filtering.

CHAD: I actually have never thought of it as something professional to do only because I don't know, because I always viewed each event that happened where I'm helping somebody as “Hey, I helped that person.” I never viewed it as a group of, “I can do this professionally.” I don't know, like it's never really crossed my mind literally until you mentioned it. I don't know, it would be interesting. I would love for my career to be – to be honest, I don't even know what my career should look like at this point.

[laughter]

I'm just all over the place. I just like being here. [laughs] I just literally enjoy being here. Like I said, I haven't really thought about it professionally. Actually, literally after this, I'll probably give it some thought, but I'm going to continue doing this regardless. Even if, say for instance, I don't think about it as doing it as a job where I get paid, but definitely just because I did something that just feels good to me and I get to help other people, I do get the benefit of feeling good that I helped somebody else, I'm going to continue to do it. But I never even thought of it as something that you make money off but.

MANDO: A lot of people super do. [laughs] I cannot stress that enough. A lot of people super do and it is my experience that very, very few of them are worth what you end up paying them.

CHAD: Yeah. [laughs] I understand.

JOHN: You were talking about connecting with other organizations on Twitter around hiring that made me think about Diversify Tech. We had the founder, Veni Kunche, on the show last year, I think it was and she's been doing fantastic work over there. That was the first organization that came to mind when you were talking about reaching out, so they do good stuff.

CHAD: Yes. I was definitely thinking about reaching out to them especially because they do a lot of work on Twitter specifically. So right now, the way I think about it, the hashtag obviously lives on Twitter, but it's mainly focused for the Twitter community only because at the time, I was just like, “Hey, people on Twitter are posting these things, I should make some space to put all of these things on Twitter.” Obviously, it doesn't necessarily have to be. Could end up being an entire organization, an entire company, or something like that. But specifically, because they do so much work on Twitter already, I definitely want to reach out to them.

MANDY: That’s cool.

So I want to go back to the thing we were talking about with reading your bio about comparing eSports to software engineering. Can you tell us more about that?

CHAD: Yeah. So it's been something that I've been thinking about for a while. I say eSports athletes, I don't want to say professionally, but I compete playing fighting games. I've been doing that for about 11 years now. Pretty much the way I view it is when Street Fighter IV officially released on consoles, which was, I think February 9th. It was sometime in February 2009, that's when I kind of view my “eSports career” starting because I've been playing fighting games because of that. I played fighting games a lot longer before that, but when I started taking them seriously and competitively.

During that time, I was in school for software engineering at Nova Southeastern University and what I have found, that I especially kind of feel this now, is my abilities as a software engineer and as a competitive fighting game player tend to complement each other. I haven’t had, I don't want to say official, but I haven't sat down and wrote this out, or have a thesis.

But I find that there's a lot of comparison to fighting games and to making software so much so that I've been playing fighting games for a while and I would consider myself, if we're going to use the same terminology as software engineering, a senior fighting game here.

MANDO: Love it.

[laughter]

CHAD: As funny as it is, when I have conversations with people and what they would consider a senior software engineer, it's like I do more, or less the same things in fighting games. For instance, a question of tooling—and you can definitely chime in because I'm not going to pretend that I'm the most knowledgeable in the industry, especially from actual experience standpoint.

But from my understanding for a senior engineer, they understand various tools, they understand when to use them, what situations to use them in, when not to use them, how to tie things together, teaching other people how to do these things, they advocate for their project that's a little bit out of the fighting game. I guess, not really. But I guess the thing is that same thought process, the using the various tooling, is how I would—I'm looking literally back at my system just to think.

[chuckles]

But it's the how I play fighting games at this point like, I have tooling in my head. For instance, I'll be playing a match against a type of player and I'm like, “Okay, this type of player is so on and so forth. This generally works on this type of player. So let me apply this,” and so, “Okay, it's working,” or, “Oh, it's not working. Let me make some adjustments here.” I just feel like it's the same type of – I can't speak directly on that, but it feels so much like the same type of decisions except with software tools.

When do you use MySQL? When do you use Mongo? Obviously, you don't have an opponent. You could make a construct of what an opponent is if you want to keep that same type of thought process. But you use tools for specific situations and then you make adjustments based on the way the situation changes, maybe based on your features that the user wants, or based on what you've been finding has been successful, or you want to maybe add a feature, or so-and-so.

I just feel like the thought process is similar. Even the way you use basic tools in programming variables, functions and so on and so forth and how you don't even necessarily think about them, but you obviously use them because you have to. You do the same thing with fighting games. In fighting games, our primitives is we call them normal where it’s you literally press the button and you do nothing else and an attack comes out. You know what I mean? So you can view them as primitives for, I guess, programming fighting games. I don't have a better term [laughs] to make the comparison, but I don't know.

It's like for me, as a fighting game player and as a software engineer, I feel like there's a huge comparison. I'm still growing as a software engineer, but I'm actually getting to the point where I'm trying to look at my fighting game career, or my growth in fighting games and try to compare them to my growth in software engineering and see oh, where did I have issues here and how did I solve them? But that's just my thing like, I just feel like there's a comparison there that I definitely would like to explore a lot more, especially since obviously I'm in both industries, you know what I mean? But that's kind of why I make that comparison.

JOHN: Yeah. I was thinking you could think of it okay, the opponent is a right heavy database load that needs to scale 10x and we're going to attack it with sharded Mongo and RabbitMQ. [laughs]

CHAD: Right, and then how does that work? Because it's about the feedback, right?

JOHN: Yeah.

CHAD: It's the same thing in fighting games; it's about the feedback. I don't want to say it's more important than fighting games, but the thing is, a lot of people in fighting games, they have their strategy and they use it and it either works, or it doesn't work and they live and die by the strategy. But a lot of the times, it's you start with one thing because that's what you know and then you get feedback from the opponent, you know what I mean? You're generally trying to make the feedback favorable for you, but at the end of the day, it's just you leveraging the feedback from the opponent.

It's the same thing—in fact, it's extremely stressed in software engineering that you do get feedback from your users, or get feedback from wherever from either directly from your users, or say, for instance, there is some issue with your implementation, you have logs and so on and so forth. So it's like, what do you do with all of this information and like I said, I just feel like there is a comparison there that is really interesting.

Again, I don't necessarily have this as a thesis, or anything. It’s—I’ve been saying this a lot—something I definitely want to explore, but it's just really interesting to me. I still play fighting games. It's been years. I played two different Street Fighters and I've used the same mindset and I still have the same comparisons. I feel like there's something there that's worth exploring.

MANDO: Yeah, man. Just like what you were saying, Mike Tyson had a famous quote, “Everyone's got a plan till they get punched in the face,” and that's what you're talking about exactly with the fighting games and what John was talking about with the [laughs] heavy database load in an application.

I come from the technical operations world where we absolutely view all kinds of things in adversarial terms everything from malicious users to external and internal systems to, on our very worst days, other developers and engineers. [laughs] It is through no fault, but you have to be careful to make sure that someone can't accidentally do something bad to a production database because no one's and everyone makes mistakes.

Going back to what you were saying about drawing the connections between being a senior engineer and a senior fighting game expert, which I love that idea. In both cases, you build up this experience, this learned experience over time to where you learn.

The reason that I don't want you to have production database access isn't because I want to keep things away from you, it's because nobody's perfect and I'm not perfect, which is why I don't have it either. It's too easy to make these kinds of mistakes, but you have to balance that with your ability to actually get your job done. Like, don't tell me I can't have database access when I need database access to get this stuff done.

I imagine this the same way in fighting games. You want to win so you have to do stuff. You can't just sit there crouching in the back the whole time waiting, you know what I mean?

CHAD: I'm literally trying to formulate a scenario, but trying to form it in a way where I can actually explain it without using terminology and just going over everybody's head. So a similar situation would be in fighting games is that you would play a specific range so that you can go in and out of the opponent's range, but they can't attack you. I don't know if this is actually a good scenario—the only other thing that they could do is jump and in essence – or jump at you and so, you're holding this range to force these two options.

In your scenario, it's more like oh, this is to make sure that things don't happen. Bad things don't happen in a project. This is more okay, I know that if I'm too close, they can do more, or less anything they want to me so I'm going to hold this range so that they can and then I'm just going to leave them with these two options that I can control. This is not necessarily [inaudible], right? [laughs]

MANDO: No, it's 100% perfect, man. It's the same exact idea of me giving you production database access, but I only give it to you with a read-only user, or with certain CPU quotas, or something like that. So I'm making sure that what you can do is constrained in ways, like you said, that I can control and it's not only just to be defensive, it's to make sure that you get, I don't know, the most positive outcome of the situation.

CHAD: Right.

MANDO: Which, in a fighting game, is to win.

CHAD: Right. Like – [overtalk]

MANDO: And in my case, is to not get paged in the middle of the night.

CHAD: Right, yes. In fighting games, the goal is to one, the whole thing is to generally avoid getting hit. But if you can get hit, you at least know where and you can deal with it. This is more from a defensive scenario; I can come up with offensive scenarios, too. I just lose it trying to keep it in line with the same thought process.

MANDO: For sure.

CHAD: But it's like, I personally have not been in that situation that you described in terms of a production database. But the fact that I could come up with a scenario that is similar to something you described and they're completely, I don't want to say, obviously it's not completely, but it's different realms. It's just something interesting to me and then again, obviously I'm still learning, but I'm not learning.

I'm more of an expert in this thing. So I think that using my knowledge here to make the comparison to what I would say need to learn, or need to understand, or just how to approach a problem. I don't know. It's all jumbled in my head, but it's just fun. It’s just something fun that I want to explore more. I’ve been saying explore more a lot.

JOHN: Yeah. It’d make a great series of blog posts.

CHAD: Yes. I've been thinking of that, or making videos because then especially since fighting games is a very visual thing. I've been streaming recently, so it's just like, I can actually play the game and then maybe I can make a video on the game a little bit and then make some comparisons to basic ideas in software development.

It's something that I really wanted to play with very recently, especially because I still play the game and I enjoy it, but sometimes, it's frustrating because the internet is internet, right? But it’s something I just want to explore, something that’s really fun for me.

MANDO: So what are you playing right now, specifically? What are you competing in?

CHAD: So I play Street Fighter V. I don't compete too much anymore mainly just because there aren't as many active communities. So I live in Jamaica and there aren’t that many communities, not necessarily for eSports in general, but specifically for Street Fighter. So I still watch a lot of events on Twitch and I watch a lot of match videos on YouTube, but I'll play the game here and there and then obviously, I'm still trying to grow as an engineer.

I spend a lot of time doing that, but that, I would say a Street Fighter V. There are a few other fighting games that I'm interested in. Street Fighter V, it's being phased out. Eventually, a new version of that game will come out and for Street Fighter specifically, a lot of the times when they release a new game, it's fairly different from the previous one. So you take your fundamental tools and then you build on that with what the game gives you. But that's what I'm playing right now.

When I say I'm a fighting game player, I mainly play Street Fighter. There's some people who play a variety of fighting games and it's extremely difficult because a lot of fighting games are very different. The intricate decisions that you make are very different like, just how you approach the opponent is very different. But that's mainly what I've been focusing on for right now.

I'm hoping to get back into it once things settle down bit more—obviously, the pandemic put a damper on all manner of physical events. So once we are able to get back together when it's more safe, I'm really hoping to take part in that.

MANDO: Yeah. That was going to be my next question was how many of these competitions happen online versus having to have to be in-person because of response times and refresh rates? I've known a couple of people throughout my life who do this competitive gaming and the idea of trying to do it over the internet would just make them gasp like, “Oh, never. Never.” [laughs]

CHAD: Right. It's gotten significantly better than 10 years prior. 10 years prior, I won't say it was a nightmare, but it was pretty close. It's gotten better and I'm not going to pretend that, at the very least, the game that I play Street Fighter V is perfect. There are other fighting games where they've made significant strides in making the online experience better.

Funny enough, there's a project that recently, what I mean by recently within the last 2 years, got open sourced called GGPO. It stands for Good Game Peace Out. It means absolutely nothing to nobody; it’s just everybody's just used GGPO. But the creator is somebody who used to run the largest fighting game event. He's more of an advisory person now, but he used to run the largest fighting game event in the world.

He created, they call it Netcode. It's an unofficial term for just how the network works in terms of dealing with multiple players, but he created a system where generally, when you have two video games, I don't want to say generally, but for the most part, a lot of video games would try to keep the game as synced as possible. So if one of the two systems—within fighting, it's usually two systems. If one of the two systems went out of sync, then the other one would immediately stop what it's doing and try to sync up with the other system.

So this person, I don't remember his name. He has a twin brother. We call them the Canon brothers. I don't remember which one did it. Either way, he created a system where the idea was instead of keeping both systems synced all the time, making that the main thing that the network does, is we'll have both video feeds play on their own. We still would do some syncing here and there. But what we will do is just ensure that – how do I describe it? Say for instance, you would have the one video feed being specifically on a specific frame.

For people who don't know anything about video is that to get video, you just literally redraw images over a period of time and you get motion from that and we, in fighting games, use that specifically to understand how fast things are, what are our options, and so on and so forth. So in fighting games, it’s generally 60 frames per second that we use.

Say for instance, the video feed for one device is on frame two and the video feed for another device is on frame three. Like, the devices are out of sync, but what they will do is for the device that's ahead, they will say, “Okay, this is what happened from the device behind,” and they call it rollback. They call it rollback Netcode and they will roll ahead device back to what the behind device was. The idea is to keep the video feeds as fluid as possible, because timing is a big deal for fighting games.

So he did all of this work and it became a really, really popular option for net play, but he owned the rights to it at the time and he had owned the rights for 15, maybe not 15 years but for a long period of time and he recently opened sourced it. So it's something that I'm hoping that more game developers will be able to pick up on it and use it in their fighting games because otherwise, they would have to do one of two things.

They'd obviously have to get the licensing from him and use it in their game and he would provide technical support on how to implement it, or they would have to come up with their own thing and a lot of the times—in fact, funny enough, Street Fighter V is a famous example of this—is they won't get the implementation just quite right and then it just makes it a bad experience for the players.

But again, I guess, going back to the conversation about online fighting games, it's been getting better. Like I said, that's one option. There's a company called NetherRealm Studios for people who, if you remember Mortal Combat, they're the company that works with that, makes Mortal Combat. They themselves have developed, I don't know too much about that personally, but their Netcode—I use air quotes—is “exceptional.”

One of the big challenges is playing somebody from across the United States. So California to New York would be a good example. That's usually a horrible time for both people, but with both, GGPO and Mortal Combat, their Netcode is so good that that actually can happen.

I'm sorry if I'm sounding super technical, but there's another game that got rereleased recently, Guilty Gear Strive, where the Netcode is so good that people are playing cross continents. Now it's reasonable for them. Whereas, if you left the state, or if you started playing as somebody from the East Coast to the Midwest, it wasn't even practical. It just didn't make sense. So there's been great strides in that.

Especially because of the pandemic, a lot of events have been online. As a community, we've transitioned fairly well into doing a lot of online events. There's a lot of games that have been running online events and a lot of people who run very famous offline events have now transitioned to running good online events until the time that we can actually get back together. It's been an interesting and tough time, but I feel like everybody has stepped up to meet the challenge.

MANDO: Yeah. No, it looks like it's Tony and I was just like reading through the Read Me for GGPO and I don't know a thing about this thing, but if what the Read Me says is true, it is super, super cool.

CHAD: Yeah.

MANDO: It uses input prediction and speculative execution to send inputs to the lagging side, or the non-lagging side to mimic what the lagging side would normally be sending over.

CHAD: Right.

MANDO: So the person who isn't lagging, to them it just feels like they're still playing and then it does the same thing to the other side. So [chuckles] even though you may not necessarily be playing each other, it still feels as though you're playing and not hanging and trying to do the sync like you were describing.

CHAD: Right, and it does that until both sides get information about the specific frame and what happened and so – [overtalk]

MANDO: What actually happened, right.

CHAD: Yeah, or what actually happened and then it would like, “Okay, this is what actually most people were trying to do.” It's really interesting. Well, I think I still have the project on my machine. Funny enough, something that I actually really wanted to do. I'm not allowed to say that because I’m, to be quite honest, outside of the explanation. I'm lost from a technical point of what exactly is going on, but I'm hoping somebody is maintaining the project. I haven't seen anybody do anything with it, maybe even extending it. To be honest, I would love to go into it. But for the moment, it's way out of my wheelhouse. [chuckles]

Because I think it's really important, you know what I mean and I would definitely love to see more game developers use it and if it kind of comes down to me doing something, you know.

[laughter]

CHAD: I just think it's a really important utility, at the very least, for fighting games because I've heard of other people trying to use it for other applications as well. It was obviously made specifically for fighting games.

MANDO: Right.

CHAD: But I just want to see the project continue and want to see more people using it. I don't know if it needs to be fleshed out because it was fleshed out during its development for an extended period of time, but I just definitely would like to see it leveraged more in fighting games. If nothing else, for my own sake, because I hate playing bad matches.

[laughter]

JOHN: So I think now is the time of the show where we do what we call reflections, which is basically each of us are going to talk about the things that we are going to take away from this conversation—maybe new ideas to think about, or just interesting points that have been made today.

For me, it's definitely just the tiny little act that you started with this hashtag; just connecting a couple people and just making this little thing and now it's gotten bigger and bigger and you're putting the effort into it to make it bigger and all those things. But just people have gotten jobs based on what you've done, undoubtedly. It seems inevitable even if you don't have numbers on it. It's such a simple act of just noticing two people that should be connected and could be connected and making that simple. It's a retweet, or it's a little DM, or whatever it is, sometimes those small acts can have such big consequences.

So it's wonderful to see that you noticed that that was a thing that could happen and that you could make happen and that you're continuing to put your effort into it just to make it bigger and bigger and be even more impactful.

MANDY: For me, I also go back to the beginning of the conversation when I mentioned that we had the Greater Than Code Twitter handle and how I used to be super diligent about amplifying others, putting others content out there and then I stopped. I'm going to make that my back-to-school goal is to come back and get that done.

So listeners, stay tuned. There's going to be some new content on Twitter. Follow us if you aren't already and also, make the effort to do the same thing. Do some simple retweets for others, amplify others. If you've got an audience, somebody else might not and just that simple act, as John said, can really help others. So be more cognizant and do that sometimes.

MANDO: Yeah, it's great. Or the way that Chad, you took this thing that you love, you spent a lot of time, a fair amount of your life devoting to becoming an expert at fighting games and then taking that and being able to draw comparisons and make connections between that and the stuff that you do every day.

When you were describing these kinds of connections, the idea that popped into my mind was there's someone, or someone's out there right now who grew up playing fighting game and they're super, super, super deep into it like, talking about all the stuff that you were talking about. Talking about NetCode, talking about hit boxes and refresh rate, all that stuff, normal. And then at the same time, they might be trying to break into the software engineering world and they're an expert over here and not over here.

So hearing you talk about these connections and what if this in the fighting world could be reflected in the software engineering world? That might be just the kind of stuff that they need to hear so they can make those connections, those same types of connections in their minds and bring that experience from one realm into another, into the professional realm.

It just got me thinking about all the different ways like you hear people often say things like, “Well, I don't have anything to blog about. I don't have anything to make a talk, or a presentation app,” and it's just not true. It's just like, there's so many people in the world who need this kind of content and how John was saying, this kind of content can make a material difference in someone's life and then that little bit starts a chain reaction. It's like a snowball going down a hill and you get someone who is able to start working now as a software engineer and by the end of their career, imagine all of the money and all of the stuff they've been able to do for themselves and their family and their friends and their loved ones, all because of something that you thought was some dumb blog post, or getting too technical in a podcast about stuff, you know what I mean?

Like, it's important, it matters, and we need it and we need more of it. So thanks. I guess, this part was my way of saying thanks for coming in and talking about this stuff, but also, encouraging other folks, myself included, to not be afraid to talk about things, or just a connection in your mind because it's not just you, it's other people as well.

CHAD: My reflection is one about making the whole connector person. I didn't even know it was something that could be done in a professional sense. Like I said, I do it because I'm helping people. That's the only thing that's in my mind about it. It's like, “Oh, this person needs something. I can potentially help them get it done,” and that's all that was in my head.

So just having that as an option, as hey, you can actually make money doing this. There's that and to be honest, the validation that making the comparison to fighting games and all the technicalities of fighting games and software development as a discipline, there is that connection and it's something worth talking about and bringing it to other people and is potentially interesting. Obviously, I'm at least half decent at playing fighting games.

[laughter]

So I can talk about that and I'm still growing as a software engineer so it's almost like I have a foundation. It's like, I haven't made that journey yet, but I have a roadmap and I can potentially draw that same map and then give it to other people and they may be able to potentially leverage it for themselves, which again, I'm helping. You know what I mean? [laughs]

MANDO: Yeah, man. That's how it works, brother. That's how it works.

CHAD: Well, yeah, that's definitely – I don't know. I'm really happy about at least that kind of validation, if nothing else. So thank you very much.

MANDY: Well, Chad, it's been wonderful talking to you.

MANDO: Thanks for coming on, man. It's been great.

MANDY: Yeah. Thank you for so much for coming on this show and thank you to our listeners. So we'll see you all next week.

Special Guest: Chad Stewart.

Support Greater Than Code

01:27 - Andrew’s Superpower: Stern Empathy

03:30 - Setting Work Boundaries

18:54 - Providing Support During a Pandemic

23:37 - Keeping People Happy / Avoiding Team Burnout

36:26 - Developing Team Culture

43:08 - Knowing When to Jump Ship and Understanding Your Skills

46:51 - Developing & Enforcing Boundaries

59:05 - Making Mistakes

Reflections:

Arty: The intersection between identifying and acknowledging creates the precedent for the norm.

Jacob: Evolving culture to enable vulnerability more.

Casey: Andrew’s river metaphor and Arty’s cardboard cutout metaphor.

Andrew: Talking about and building psychological safety is foundational. Going first as leadership or being first to follow.

How to start a movement | Derek Sivers (being the first follower TED Talk)

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

ARTY: Hi, everyone. Welcome to Episode 248 of Greater Than Code. I'm Arty Starr and I'm here with my co-host, Jacob Stoebel.

JACOB: Hello! Nice to be here, and I'm here with my other co-host, Casey Watts.

CASEY: Hi, I'm Casey, and we're all here together with our guest today, Andrew Dunkman.

Andrew, he/him, is an engineering leader and software developer with 17 years of experience. He’s worked on and launched tools for contact relationship management, predictive sales, radiology and healthcare, learning and management, business-to-business timekeeping, and most recently in government at 18F, a part of the US General Services Administration that’s helping the federal government adopt user-centered technology approaches. He loves those.

He also likes building community in his free time. He helps moderate the DC Tech Slack, a 10,000-person community of tech workers in the DC area and he helps to run DC Code and Coffee, an informal hacking and community-building event every other weekend.

Even though his cat, Toulouse, is glaring at him for talking too loud, he is excited to be here with us today. Hi, Andrew!

ANDREW: Hey, y'all! So nice to be here. I'm honored to be a guest.

CASEY: Let's start with our standard question to kick stuff off here. Andrew, what's your superpower and how did you acquire it?

ANDREW: Thanks for asking. Yeah, this is whenever I answer the question of what my superpower is, it feels like bragging so I did what I normally do when I'm uncomfortable asking a question and I ask other people that question. I asked a few friends and they highlighted both, my ability to empathize with people and also, my sternness in that empathy.

I think sometimes when you get caught up in empathizing with people, you can allow their emotions and their feelings to overwhelm you, or become a part of you in a way that you're not necessarily hoping for. So I like to draw a firm boundary there and then allow other people to see that boundary, I suppose. [laughs] I don’t know, it's hard for me to say that that's a superpower, but I'm just going to lean into what other people told me.

ARTY: That's a pretty good superpower. I like it. How did you acquire it?

ANDREW: I credit my mom a lot actually. My mother is a dual major in psychology and English and as growing up, she had the worst way of punishing me, which is anytime I’d do something wrong, she would say, “Can you describe to me what you did and tell me how it made the other person feel?” which is the absolute worst thing to do to a child to make them explain how they've hurt you. [laughs] So I credit that a lot for developing those skills.

CASEY: That's so funny. You think it's the worst thing you can do? Could you imagine yourself doing it ever if you're around children like that?

ANDREW: Oh, totally. [laughs] Absolutely, yes. I now do it to my friend's children. I have no children myself, but I do to my friend's children and it's appropriately uncomfortable.

CASEY: I like that. Yeah. It can be the worst and it can be helpful and productive. I believe it.

ANDREW: Yes. As one of my coworkers like to say, “Two things can be true.”

JACOB: That boundary, I've been thinking about something along the lines of that recently, particularly in work settings where you can get really burnt out in everything is high stakes emotionally at work. I think that's a really good boundary to have.

ANDREW: Absolutely and it's also super hard to know. [chuckles] Both know where that boundary is and what to do when you are coming up to it. I think some people and myself occasionally notice you've crossed that boundary in retrospect, but not necessarily in the moment and it's hard to start off just know your tells when you're getting close to that line and when to pull the e-brake and take a walk, or go out and find some way to disengage, or reengage in yourself as a human and your human needs.

CASEY: I'd love to hear an example of a time when you pulled the e-brake recently, Andrew. It's so vivid you must have a lot of stuff under that sentence.

ANDREW: So my current organization, 18F, is one that's a matrixed so we’ve got our chapters is what we call them which is our disciplines. Those are engineering and design, product acquisitions, they're groups of people that do the same kind of work, and then our other angle of the matrix is our projects. Those are business verticals like the kinds of people that we're helping and the organizations that we’re assisting around public benefits, or around national security, or around natural resources.

So the result of a matrix organization is that you have two aspects to who's managing you—you have the manager of your work and you have the manager of your discipline—and the positive thing about that is that you can use both angles of the organization to support you in different ways. Sometimes in your work, you need someone to speak up for you as a person, or as your skills development angle and sometimes you need someone to speak up for you in terms of the project work that you're doing, advocating for success in the specifics of your project, regardless of the way you're contributing to that project.

The result, as you zoom out into upper layers of management, is that you have a conflict designed into the system and that conflict, when things are working well, benefits the health of the organization, both the health of people and the health of projects are advocated for and supported. But when things get out of balance, which happens all the time, in every organization I've ever been in you've got pendulum swing back and forth between different balances and when things out of balance, then suddenly you find yourself overextended, or advocating to an empty room.

A recent example was a conversation around advocating for the benefits of – I'm on the chapter side of the house so I support people within engineering and I had to pull an e-brake in a conversation where I was advocating for the health of people, but that I didn't have the right ears in the room to make a positive change. I found myself getting ahead of myself. One of the tells that I have is that I often feel tension in my jaw, which is usually a sign that I'm stressing too much about something. So I decided to take off a few hours and went to a gym [chuckles] and did a work out just to get the energy out of my system.

ARTY: It seems like those conflicts can become pretty emotional depending on the circumstances where you've got folks that are overworked and stressed out, and wanting an advocate to help support them in those challenging circumstances. You just think about product deadlines and things coming up and the company's trying to survive and it needs to survive so it can keep people employed.

Those things are important too, but then we've got these challenges with trying to live and be human and enjoy our lives and things become too stressful that we lose our ability to the function and we need advocates on various sides. So when you engage with someone, let's say, there's someone on the team that's burnt out and really stressed out, how would you approach empathizing with where they're coming from to help work toward some good the solution to these things?

ANDREW: Great question. I think in these kinds of situations, I always come in with the acknowledgement that no one in this conversation owns the truth. We're both working together to understand what the best thing to do is and what the reality of the situation is.

From my perspective, in trying to support someone seeing that they're burnt out, or overworked, that I think that's a misnomer. We can sometimes think of being burnt out overworked as an inherent state, or as something external. But I always try to encourage people to bring it internal because we all set boundaries and orders. The reality of an organization is that there will always be a resource constraint, whether that's people, or time, or money and it's up to the organization to effectively solve what they need to solve within the boundaries of those constraints.

So when people are feeling overworked, or when they're feeling burnt out, oftentimes there's an imbalance there where the organization perhaps is trying to achieve too much, or perhaps there aren't enough resources supplied here. If you can both internalize it to yourself and say, “Okay, it's up to me to set responsible boundaries so that I'm not burnt out, so that I'm not overworked and how do I, as a manager, support you in finding that boundary and helping push back when people try to violate your boundaries?”

Also, how do we, as an organization, understand where that line is and understand what kind of slack do we have? Because I think a lot of times in organizations, it's hard to see are we at 20% capacity, 200% capacity? It's hard to see because the more work you throw at people, unless you're getting pushback, it seems as if you still have more slack, more line you can pull.

Part of this is acknowledging that there is a systems level problem here where there's a lack of visibility into how overworked someone is and also, helping someone recognize hey, here's my boundary. We're over at. Now let's figure out a, how do we move that boundary back to where it needs to be so that I'm a positive contributor to this team and I can live my life [chuckles] in a happy way and also, how do we raise this in a way that the organization can see so that we can ultimately be more successful?”

If an organization is burning people out and making them feel overworked all the time, the work is not going to be successful. You care for people first and great people who are cared for then care for your projects and deliver great work.

JACOB: Yeah, and it’s like how can there'd be a health check for every person and what would that look like because I think if people are left to determine that for themselves, you can get really different conclusions from person.

ANDREW: That is a great question I don't know the answer to. [laughs] I've been thinking about this a lot recently.

My organization has a project health check where weekly, or bi-weekly, I can't remember, each project team talks about the different aspects of the work and whether, or not they're feeling well-supported, or if there are things external to the project that are getting in the way of project success. That gives you a data and interesting insights.

We also track our time and there is a way that we track our time that's flagged as support to the team. So that's where managers and people who are assisting in making big project decisions, those people track their time to that separate line. That's also interesting to look at because typically people ask for help after they already need it and the people that are close to the project can see that they need help. So if you're looking at the time tracking, usually a week, or two before something shows up on this project health tracker, you see a spike in hours in the kinds of support that people are providing to the project.

We have a lot of interesting data on the project health side of things, but it's really hard to collect data on the people part of this in a way that like makes people feel supported and it doesn't feel creepy. [chuckles] There's a whole aspect to this on whether, or not people feel comfortable reporting that they are feeling overworked and I haven't solved this problem. I'm curious if you all have ideas. [chuckles] I'd love to learn.

ARTY: One of the things I'm thinking about with burnout in particular is I don't think it's directly correlated to the volume of work you're doing. There's other aspects and dimensions of things that go into burnout.

So if I'm working on something that I'm really excited about, it can be difficult, it can be really challenging, it can be a huge amount of work, and yet as I work on it, as I get to the other side of that mountain I'm climbing, burnout isn't what I'm feeling like. It's a rush being able to accomplish something difficult and worthwhile as we don't necessarily burn out directly in correlation with working too many hours say, or something directly related to that.

The things I find that happen when people get burned out is when they lose their heart connection with what they're doing. When you love what you do, when you're excited about what you're working on, when you're engaged and connected to a sense of purpose with what you're doing, then we usually stay in a pretty good, healthy state. We’ve got to maintain not still keeping in someone in balance, but we're doing pretty okay.

Where I see developers usually burning out is there's some heart crushing aspect of things where people are disconnecting disengaging with what they're doing emotionally and they go into this mode of not caring anymore, not having those same compelling reasons to want to do those things and such that when that love connection dissipates, that work becomes too hard to maintain, to force yourself to do. So you start getting burnt out because you're forcing self yourself to do things that aren't an intrinsically motivated thing.

I feel like the types of things that we need to do are activities that encourage this sense of heart connection with our team, with our project, with our customers. We do need visibility into those things, but maybe conversations, or even just knowing that those things are important, making time to scheduling time to invest in those sorts of things. I'm curious your thoughts on that.

ANDREW: Yeah. Thank you for flagging that specifically. I think there's one thing that comes to mind for me is that is this work that you once loved that you no longer love? Like, is this something that you've connected with in the past and this really motivated you and now you're not motivated, I should say and if that's the case, what changed? I think brains are tricky and I think that we've all over the last pandemic, [chuckles] the current pandemic, I should say, the COVID pandemic is the one I'm referring to.

I think that as people have coped with lots of trauma in their lives and significant shifts and changes, it's come out in interesting ways. I think, especially as people are learning themselves a little more with new constraints, the impacts are not always directly connected between say, the project work that you're doing, maybe something that you once loved, and now suddenly you no longer feel attached to that. What is that? Is that the work is somehow different? Is it that you really just your threshold for everything else in your life is just ticking higher and higher and higher so now it's really hard to engage in any of the things that you once loved?

I personally have found myself, through the COVID pandemic, really finding meaning in repetition. So now I'm like a 560-day Duolingo streak and I've got podcasts I listen to every day of the week, and this repetition helps mark time in a way that makes me feel more like I have my life together. That gives me more capacity and reduces that stress threshold for me.

So I think trying to narrow in on what specifically changed and how do we tackle that problem head on, and it might not be the work, or connection to the work.

The other side of the question is, is this work your love? Maybe this is work that they've never really loved. Maybe this is grunt work—and one thing that I like to acknowledge is that every project has a grunt work associated with it and if you don't really have a framework for rotating that grunt work, a lot of times it falls to the person who has the least privilege on the team.

So if as a positive team, you can work together and say, “Hey, these are the set of tasks that just needs to get done,” maybe that's notetaking in meetings, maybe that's sending out weekly status emails, or running a particular meeting. “Let's rotate that around so that we can find a balance between the grunt work and then the work that we're here to do this stuff that motivates us.”

Because if the grunt work doesn't get done, the project won't be successful, but also, we all really want to work on the other thing, too. So let's make sure that no one here gets shafted with all that work [chuckles] and I think especially if teams haven't deliberately thought about that, patterns start to emerge in which people with less privilege get shafted. So I think that's something to be well acknowledge.

JACOB: Quick shoutout. Episode 162 of this podcast, we talked with Denise Yu who really is framing exactly what you're talking about. She calls it glue work and it's that work that's maybe not directly recognized as a value add, but is the work that holds all of it together. So all of the work that might get done in JIRA, or around a Wiki, or organizing meetings, taking notes, all the above.

The basic theory is like you said, how can that glue work be distributed equitably? Not to say that certain roles don't intrinsically need to do certain types of glue work because that's what their expertise is in. But it was a really good conversation. So if people are interested, go check that out, too.

ANDREW: What are some ways that you're seeing that pandemic affect people in their work?

ANDREW: I think the answer to that question is as varied as the number of people [laughs] that I support. I think each person is affected in dramatically different ways, which I didn't quite expect, but taking a step back and thinking about it, of course, each person's individual and each person reacts differently.

But I would say that for some people, especially people in care-taking roles, that kind of work has to shift to support them. So if you're someone caretaking, you're often dealing with a lot of details in your out of work life and especially through the pandemic, now those lives are merging together.

I'm currently at a remote organization and have been at a remote organization for the last 10 years, or so. The remote work thing is not necessarily new, but the complete merging of all of the things life and work is something that's still new and I think a lot of people who work remotely regularly often find ways to get out and get more exposure to people in their personal time, which is also something that has been limited. Especially if you're caretaking, you likely are doing that even less of your threshold for getting out is even lower.

So if you're constantly dealing with details in your life, it might be good for you to take on more of that glue work, or more of the when you're thinking about the – I think I've worked in three categories.

You've got the stretching work, or your growth work and that's work that is right on the cusp of your understanding. You're not really good at it yet, but by failing and by having moderate success, you grow as an individual.

There's also your comfortable work, or your safety work and that's work that you're good at, you can knock it out of the park, do it really fast. I think for folks who are dealing with a lot in their personal life at the moment, leaning more towards the glue work, more towards the safety work is really important for making you feel successful and you're not really hungering that growth. I wished I remember the reference, but I heard someone referring to growth as being in a boat in a river before. Sometimes the river is wide and sometimes the river is narrow. When the river is wide, you really need to row.

I found myself personally, in the last couple of years, not necessarily needing to grow as much and the river feels more narrow to me. So the current is faster and you're taken away with growth and you don't really need to do a lot to get there. Instead, you need to hold on [laughs] and try not to capsize. So that's one aspect, I would say I've seen people…

CASEY: That's such a cool metaphor. I'm going to remember that.

ANDREW: Yeah. I wish I remembered where I heard it from so that I can reference it for you all. It's definitely not an original idea of mine.

But another aspect of the way people have individually in coping and needing support is around their social connection and that's an easy example. I think we've all felt differences in our social connection through COVID and sometimes that takes the form of having more structured meetings.

Some people find more structure gives them the ability to communicate with each other in a way that makes you feel social and also isn't as draining and other people are the exact opposite where they want to get together in a room with less structure so that you can all just hang out and the structure gives people a sense of feeling stressed.

The way that I've been looking across my organization is what kind of things are we providing and are they varied enough that we're capturing the majority of people in the support that they need?

CASEY: I thought about a lot in the dance communities I am in that there is a lot of introverts that love to go dancing, partner dancing, because it's structured and they'll say so. Like, I love that I can just show up and do the thing and it's social, but I haven't thought about the other side of that, which you just said, which is some people don't want the structure. I'm sure those people exist and I just probably know a lot of them, but I haven't heard people say that about themselves as much. The introverts in the dance communities know and they say it. The other side, I'm going to look out for it. That's cool.

ANDREW: I used to play music for religious music ministry and one of the rules we had is that if you're always picking things you like, you're leaving people out. I think of that not necessarily attached to music ministry, but attached to all the other work that I do and that’s if your preferences are always represented, someone else's preferences are not. So trying to look around and say, “Who's not in the room right now, who could be benefiting from having their preferences heard once in a while?”

CASEY: I want to jump back to how can we tell if people are about to be burnt out at work? How can we help people have a healthier environment?

One of the lenses that I think about all the time is Project Aristotle by Google that came out, I don't know, maybe 5 years ago at this point and we're mentioning a lot of that aspects of it in our conversation already. Earlier, we were talking about on their list four and five are meaning of work like personal importance and impact of work, which is the company mission a little bit more. The other three that we touched on a little bit but not as much is psychological safety, which is number one on their list, dependability, like depending on each other, the coworkers, and structure and clarity, like goals, roles, and execution.

I'm sure this is not a full list of what keeps individual employees happy. But I think a team environment that hits all of these five really well is going to have less burnout. More than individually, it's been studied. That's true.

So when I did team health surveys before for the team, for the people, I like these five questions a lot. I bet it's a lot like the project surveys, Andrew, you were talking about. A lot of team health surveys are similar, but you got me thinking now what's missing from that list that's focused on the team that would show up in the individual one and I don't have a clear answer for that.

ANDREW: And adding onto that, is there a way where you can collect honest data? I think one of the benefits of having one-on-one relationships with your immediate manager is that they can read between the lines and what you're saying after they get to know you well enough.

I think for me, that usually happens about a year in with a new employee where you get to know someone well enough that you can understand. If they come to you and say, “Hey, I'm struggling with this right now in this project.” Is that a huge red flag, or is that normal? I think it takes a while to get to know someone and then you can read between the lines of what they're saying and say, “Okay, this is a big deal. It deserves my attention. I'm going to focus on this.”

One of the things I struggle with capturing this information is that a, it's hard to capture that sort of interpretation part in these kinds of surveys and b, the data that you get is – when we were talking about burnout a lot, sometimes when people are burned out, they don't have the energy to submit these surveys. [chuckles] So the data is not particularly representative, but that's a hard thing to keep track of because how do you know? So it's a really tricky problem. I'm going to continue to try things [chuckles] to get this data, but I do like the idea of looking between the lines on if we're surveying team health, is there a way we can focus in on individuals?

ARTY: There's also a lot of things that we don't talk about. Like Casey brought up psychological safety, for example and if you don't feel safe, you're not likely to necessarily bring up the reasons that you don't feel safe because you don't feel safe. [chuckles]

I'm thinking about just some team dynamics of some teams I've worked on in the past where we had someone on the team that had a strong personality, and we would do code reviews and things, and some folks that were maybe more junior on the team felt sensitive and maybe attacked by certain things. But the response was to shut down and fall in line with things and not rock the boat and you ask him what's going on and everything's fine.

So there's dynamics of not having psychological safety, but you might not necessarily get at those by talking to folks. Yet, if you're sitting in the room and you know the people and see the interactions taking place, you see how they respond to one another in context. Because I'm thinking about where those dynamics were visible and at the time, the case I'm thinking of was before the days where we were doing pull requests and stuff, where we did our code reviews in a room throwing code up on the screen and would talk through things that way.

You'd see these dynamics occur when someone would make a comment and how another human would just respond to that person and you see people turn in words on themselves. These sorts of just dynamics of interaction where people’s confidence gets shut down, or someone else is super smart and so they won't challenge them because well, they're a super smart person so obviously, they know. Some people speak in a certain way that exudes confidence, even if they're not necessarily confident about their idea, they just present in a certain way and other people react to that.

So you see these sorts of dynamics in teams that come up all the time that are the silent undercurrents of how we all manage to get along with one another and keep things flowing okay.

How do we create an environment and encourage an environment where people feel safer to talk about these things?

ANDREW: To me, psychological safety and inclusion are very closely tied and I believe that inclusion is everyone's responsibility on a team and in the situation you described there, who else was in that room and why didn't they stop it? I think that it's easy to say, “Oh, these two people are having a disagreement here,” but if we all truly believe that it's our responsibility to create a safe environment and include everyone and their ideas. As you mentioned, everyone in that room could see what was happening. [chuckles]

So I think there's a cultural thing there that perhaps needs some work as an organization and I'm not saying that that is something that I don't experience in my teams as well. I think this is work that's constant and continual. Every time you notice something, it's to bring it up and invite someone back into the conversation.

Some people like to think about calling out, or versus calling in and I really like that distinction. When someone oversteps a boundary, or makes a mistake, they've removed themselves from this safe community, and it's up to you as a safe community to invite them back in and let them know their expectations and I like the idea of that aspect of calling people in.

Obviously, that requires some confidence and I encourage people, especially people that have institutional privilege, to especially looking out for this because you can really demonstrate to your team how much you're willing to support them if you keep an eye out for these kinds of dynamics.

One thing you mentioned really made me think about earned dogmatism. When people are around for a longer time, they become more closed-minded. That's the earned dogmatism effect and it's the idea that since you've been here for so long, or since you've been working in this industry so long, you're the expert and it causes you to become more and more closed-minded to new ideas, which obviously is not good. [laughs]

So anytime I see that pattern popping up, I try to just let people know like, “Hey, do you know about this effect? Do you know that this happens with people in teams and is that how you would like to be? Would you like to become more close-minded, or would you like to continue learning?” I think just the awareness of the fact that that's something that you're going to inherently start doing helps people fight against that.

JACOB: I'm trying to imagine just a typical, if you can call it that, team in a tech company and they're probably in a state where a lot of these things we're talking about might not come so easy because I think what we're saying is that a lot of this is dependent on everyone on the team being vulnerable about where they're at.

I wonder if you have any ideas about how a team can get from there to the ideal state because it sounds like that's a really big barrier. I can't have better psychological safety and inclusion without somehow getting people's feedback and I can get feedback if they don't feel safe. So is there some iterative way to improve on that?

ANDREW: Yeah. So one thing that I have direct experience with is in the federal government, there's a lot of funding models between the federal government and local governments where the federal government will pay for a majority of something as long as the local government follows a set of rules on implementing a program. So like Medicare and Medicaid are examples of this and other benefits programs as well. Even the federal highway system; the reason why our interstates are all the same is because the federal government pays for a majority of them if the local authorities building roads follows a set of rules and guidelines.

I think that's one of the most dramatic examples of a power difference. If you're forming a joint team to make changes to Medicare, or build a new highway, or improve rail service in your city and one person in the room controls 90% of the money. I think that's a pretty dramatic example of what could be a really psychologically unsafe environment and it requires a lot of effort to break down that boundary of, “Hey, I'm here to say yes to what you want.”

But then the reality is the federal government representatives in those situations are often looking to collaborate and help solve problems because they're looking out to see how do I best spend this money to achieve the best effect. But the tendency is that other members of the team coming from the 10% side of the house, they're responsible for the execution of the program and so, they tend to hide mistakes, or hide hiccups as much as possible so that they don't get their funding cut.

That's just a very natural thing that happens and the experience that I have in this situation is what I like to think of as the Waffle House solution. I heard of a particular person in this situation taking the whole team to Waffle House. This obviously works better in-person. It's hard to take people to Waffle House remotely; that's definitely not something that you can't do.

The idea behind that conversation is just the problem here is that you're not connecting with each other on a human level and you want to be safe to share your vulnerability with each other, but before you can be vulnerable with each other, you have to recognize each other's humanity and let everyone know that you respect each other.

I think an easy way to do that is to share a meal, maybe it's to play a game together, maybe it's to schedule a meeting for 30 minutes in which you talk about note work. In the example that I gave it's up to the person in the position of power here to set that example, because if you're someone without that privilege, if you are someone who pays for 10% of a project instead of 90%, it's hard for you to go to your 90% funder and say, “Can I waste 30 minutes of your time? Can I waste half a day?” Because waste in this case is the idea from the business side of the house. You're wasting time.

But in reality, if you slow down and connect with each other on a human level—slow is smooth and smooth is fast—so you can help the team develop that sense of humanity with each other, create an environment where hopefully you can be more vulnerable with each other and collaborate more humanly with each other.

So I wouldn't necessarily say that this is a textbook plan like okay, you've got problems on your team, let's go to Waffle House and the problem solves. [chuckles] I'm not saying that but I am saying perhaps look for opportunities for you to recognize each other's humanity, and break down perhaps a structure that might be standing in the way of connecting with each other, and then just focusing on that can hopefully help you find that vulnerability better.

JACOB: You can't take yourself seriously at a Waffle House. It's just not possible.

ANDREW: [laughs] I'm pretty serious about Waffle House. I don’t know about you. [laughs]

CASEY: I'm starting to get a craving here.

Yeah, totally agree. I love that this is being talked about more and more, how do we build psychological safety on teams? It comes from trust, human connection, vulnerability, and how do we build that? By treating each other as humans.

ARTY: The things I think about just contrasting some teams I've seen over time and how they ended up developing and the culture that emerged is the technical leadership on the team that organically evolves. Some people have strong personalities. They tend to naturally act in a leader-oriented way. Even if they don't officially have the title hat on their head, they're somebody that people respect and look up to. They value their opinion and thoughts and whoever those people are that have the natural gravity tend to have a lot of influence over the emergent culture.

So when I've seen people in that position, be really supportive of listening to the ideas of other folks on the team, creating space and treating people with respect, creating an environment where people are heard and listened to and it's about the ideas that the behavior of those people have an outsized impact on the culture that emerges by just how they interact and treat you respect others and other folks on the team tend to mimic and model that behavior of wherever that natural kind of gravity is going toward.

If you've got folks on the team that are like that, that have a tendency to lift up other people around them, then what emerges is a much more psychologically safe environment. When you've got somebody in that gravity position that has an ego defensive response, they want to continue to feel like the confident expert ones, when people say counter things that are positioned as a challenge and you get a very different set of dynamics that emerge where people tend to be more walk on eggshells, try to say things very carefully to not upset things.

I feel like it's just human instinct response depending on who's in the room, who you're talking to, how you anticipate they will react to something, that emergent interactions come from that and that whoever those gravity people are tend to have this outsize influence. So who you have in your organization of those folks? I'd say probably being really careful to hire people that have a tendency to and a desire to want to lift other people up and to maybe not have such a fragile competitive ego dynamic going on.

ANDREW: Absolutely. Well, I have lots of feelings on hiring, [chuckles] but I do think that in the tech industry, we don't spend as much time focusing on communication and then I think that we should. I think a lot of times people who are in that ego situation are expressing vulnerability, but poorly and I think if they had more communication skills, they could potentially express that differently in a way that was more positive to culture.

So zooming back to one of the things you said around leadership, evolution, evolutionary culture, and who steps into leadership roles, I think one of the things that is really important to me about good leadership is staying ahead of what your big problems are and that isn't necessarily saying working ahead of everyone else. That’s saying keeping your eye on the horizon. Like, are you looking out to where we're going and what kind of problems are we seeing here?

If there's an acknowledgement of an issue with psychological safety on teams, letting leaders emerge naturally may not be the right approach. You can deliberately select someone who demonstrates the culture that you want to create on a team has that technical leader and give them –

I like the ACE model, the appreciation, the coaching, and the evaluation of leadership, where you give them that appreciation on the particular things that they're doing really well and in front of the team so that the team can say, “Oh, that's what the norm is here. That's what we should be doing.”

That also gives the person, who may have perhaps more of a natural leadership role, if that would have naturally emerged, but perhaps it's missing some of those communication skills, or other skills that makes them a more around teammate, gives them an opportunity to be out of the spotlight so that they can work on developing those skills and becoming a more active contributor to the team instead of holding it back in some ways.

CASEY: I love that we keep saying the word “skill: because these are all learnable skills. You can learn how to communicate well. You can learn how to be a strong, effective leader. You can learn how to foster a psychologically safe and inclusive environment. You can learn all these things.

I love to work at places where they want this, the culture that the leaders, the people who run the company, want it even if they don't know how yet because that growth is possible as long as there's the desire for that. I think we all have a base level of desire, but some people are aware of it and articulate it and say – I saw a tweet the other day. Someone was looking for a job and of their five criteria, top five they listed in the tweet, psychological safety was on the list. That person knows they want to work on a team like that. That's pretty cool.

So someone wants their team to learn these skills. A natural way is managers coaching their employees to do that kind of thing like coaching how to coach. That can work pretty well. It's pretty powerful.

Another one is communities of practice, where you have people come together and talk. It could even literally be about culture. Some companies have a culture, community of practice, where they talk about how to influence the culture. Some places don't have the skills yet and they hire external coaches. There's a whole bunch of companies including me. For myself, I'm a consultant for making happy teams. I do coaching and training, too. There's online courses, there's books, there's podcasts like Greater Than Code. It's pretty good. You should check it out. [chuckles]

But acknowledging the problem, being aware of it is a huge key first step and I don't like to push for a psychological safety in a place that doesn't value it. That's just a recipe for burnout for me. It's happened to me a lot, but in an environment where it is already desired, getting people from wanting to, to being able to. That’s super satisfying work. I think that's true for anyone in tech who is talking about this kind of stuff, who cares about it. You want to make a difference where you can.

ANDREW: Absolutely knowing when to jump ship at an organization because you are fighting upstream at a time when you are either being taken away in the current, or there aren't enough other people around you to swim upstream with you, it is super important.

One of the things that helped me open a door in my life that I'd be happy to share with you all is an assessment I took a couple of years back called the TKI assessment, Thomas Kincaid Institute assessment, or something. I could've gotten that all wrong, but it's a tool that helps you understand what skills you already have around conflict resolution and what skills you can grow around conflict resolution.

That unlocked a lot in my life specifically because it allowed me to understand how I naturally resolve conflict, to understand when I should push against my natural instincts to resolve conflict, and when I should feel that I have exhausted my abilities to resolve this conflict. That last step is a great indicator if you've tried everything you can to resolve the conflict, and maybe that conflict is around creating a psychologically safe workspace, you yourself cannot do this. So can you bring in other people that can help resolve this, or is it time to walk away and find a team that supports you better?

The five different modes that they reference in TKI are competing, collaborative, collaborating, I should say, compromising, avoiding, and accommodating. When I first took the assessment, I scored a 0 in competing which means I had no recognizable skill in competing. When I look back into my history, my childhood, how I was raised, that totally makes sense. I was raised in a household where when people wronged you, you let it go. You moved on to find people who would support you and believed that that person would eventually experience justice and that was not your responsibility to do that.

Applying to my work-life today, that means people can walk over me. [laughs] So how do you pick up those skills? The assessment doesn't necessarily dive too much into how you pick up the skills, but I think just knowing where your blind spots are was really helpful for me, because then I could recognize a situation where a, I flagged that I'm experiencing conflict. B, my natural tendency is to accommodate this conflict, or avoid it. C, is that the right approach for this environment? Is that a right approach for this problem? And then d, either do that approach, or change it.

It's really uncomfortable. Often, when I'm competing, it makes me feel selfish and I acknowledge that. So when I'm like, “Okay, I'm going to change my approach and I'm going to compete here. I'm going to argue.” It's like, “Okay, I'm readying myself,” like, “Okay, I'm going to feel selfish now, be ready to feel selfish, go for it.” [laughs] And that's just sort of how I counteract those natural tendencies.

So I wouldn't say there's one particular magic bullet, or this is the assessment that you should do, or anything like that, but there are a number of tools out there to sort of help you understand yourself and what skills you have and what skills you might want to grow into. They can also provide a sense of completeness around a particular skill area, like conflict avoidance, or conflict resolution, and let you know when you've exhausted the available options in front of you.

ARTY: That's interesting to me just thinking about where we started this discussion with boundaries and just people can react in a different way, and if you have someone who's kind of overstepping boundaries, how do you learn to stand up for yourself? If your instinct is to just run away from conflict, whenever it comes up, then we've got other sorts of problems and stuff that emerges. Sometimes, the right thing to do is to stand up for yourself and to be able to have the confidence to feel like you can.

One of the things that that helps me with that is when someone else is upset and reacting and stuff is maybe they're attacking me, or something is to separate myself personally for that. So if I imagine them in their head and I'm a cardboard cutout character that I'm like, “Okay, they're kicking the cardboard character and that's not me.” They have a picture in their head of this little cardboard character that they've got an upset relationship with that that's separate from me.

I can look at the dynamics that are of what's going on with them and why they're upset with this cardboard character, understand what's going on in their world with separating myself from that, and then I can respond in a way that is standing up for myself without necessarily reacting to the situation where I feel like I need to defend myself against an attack that something going on that really has nothing to do with me, but still, I need to be able to stand up for myself and not necessarily back away from the situation. So I find those kinds of skills really help with being able to not take other people's stuff so personally.

You talked about the challenge with boundaries and over empathizing can put us in a situation where the things that other people say can end up hurting us a lot, or we internalize somebody else's feeling so much, or someone else's worldview so much that we can lose ourselves in someone else's emotions and feels. How do we separate enough so that we can have a solidity in our own self and our own sense of knowing such that we can have our own compass that doesn't fall over, that we can feel bolstered in ourselves, independent of what everyone else is doing? That's where that empathy and boundaries and resilience and stuff come in.

So a question for you, you did mention this boundary thing early on, what are some of the things that have helped you to develop boundaries, or some of the tools that you use to help in those challenging situations?

ANDREW: I love the cardboard cutout analogy. I personally like to replay situations as if they're soap operas. I'll describe the characters, especially when things get heated emotionally, it's easy for me to recognize it as a soap opera, which helps me chuckle about the emotional component of it in a way that externalizes it from my feelings.

It's a really tough situation. That's a tough ask. I think one thing that I do in the exact moments when I am feeling hurt, or valued, or some kind of emotional component is attached to something someone just told me is to again, pull that e-brake and say, “Okay, stop. I am not my work.” Similar to when you submit a pull request, you are not your code. I am not my work. I am not this conversation. I'm a whole self, I am valued as myself. I'm surprised by something that just happened and I'm reacting to it in a particular emotion, emotional reaction.

So if you can create a pattern, when people get you into that emotional state, whether, or not they were intending on getting you there, of saying, “Hold on, I'm caught off guard by that. Can you tell me more?” Like, “I don't understand that comment.” It shifts the power dynamic from someone putting you on the spot, which they may, or may not have intended to do, to shift it back towards them to say, “Now the responsibility is on you as the person who has made me feel upset, or I'm caught off guard by that and the responsibility now is on you to describe more so that I can contextualize the emotion that I'm feeling, or just give me time to react to that.”

You don't always have to immediately respond and oftentimes, I find myself reacting too quickly. All of the tools that I have in my toolbox are slowing down. That's one of the tools that I definitely use to help acknowledge that something is unusual.

Another tool is I'm asking people to summarize so acknowledging that, “Hey, I'm surprised by that and I'm starting to get lost in the details of this meeting. Would it be all right if I asked you to summarize the main points here, or could you follow-up in Slack after this, or follow-up an email after this?” That's another one of those, like my natural tendency to avoid. It's like okay, I can take a step back here and avoid this immediate conflict, or this immediate emotion, and then take a breather.

Often, in the before times, as I would go out and speak at conferences and I'm not a natural extrovert. I have this tendency after I speak at a place to go find a closet, or some dark room somewhere [chuckles] just to recharge a little bit, do nothing. I often will just sit there and sweat in a closet for 30 minutes, or something like that. That process allows me to reset my blood chemistry and say, “Okay, how do I fully acknowledge this situation?” Like, do I feel like I did a good job? Am I proud of the work that I'm doing? Am I proud of this? Is this where my boundaries should be? It allows me to give that moment to step away, to reset a little bit.

So it’s something I think that I will spend the rest of my life learning, which is how to recognize my boundaries and set them appropriately, and I think that's right. I should be continuing to learn as I continue to change.

ARTY: I really liked the summary thing. Just thinking about someone's really upset, it's a pretty safe question to ask and at the same time, it forces them to take a step back and really think about what it is that they're trying to say. Because usually when we're upset, we just spew lots of words of upsetness, but it forces you to shift into more of a thinking mode away from emotional mode, which I feel like would have a really good impact on level setting the conversation. Just take a deep breath. What is it you're trying to communicate here? What are the main points? I really liked that summarization idea.

ANDREW: The one thing I always myself in those moments is, “Nothing is more important than my next breath,” and that helps me to unplug from the situation and focus on breathing and focus on relaxing and then be able to show back up and reengage.

JACOB: Something that I think can be important is if I'm at work and I'm realizing that I need to be vulnerable in one way, or another because I need to draw a boundary, or for some other reasons, something that I feel like would be really important that I would really need to have is an example that would give me some idea of what will happen when I do that.

How can team members get examples of what happens when I'm vulnerable, because if they don't know what will happen, they're probably going to be left to their own personal experiences from maybe at another job, or something like that, that probably don't apply, that probably would be completely different. So it's like, how can managers, or leaders help people see, or experience examples of this is how we talk about difficult conversations to normalize it and just help people understand, like, this is what will happen and this is the way we go about it and yes, it will be safe.

ANDREW: I don't think you can say that. [laughs]

JACOB: I know.

ANDREW: And that maybe is controversial, but I don't think you can say, “Yes, this will be safe.” I think you can strive for it and you can work for an environment that's safe, but in a professional setting, there's always a line and maybe it's not safe to share something that you think is appropriate to share and there are lots of reasons for that. Maybe it's the impact on other people.

But the pattern I like to encourage and people just ask for permission, which is something that is maybe not always universally applicable advice, but oftentimes, I find myself talking to people when they're on teams where they want to say something controversial, or they want to say something difficult, or they want to share something that's personal and how they attach to this project, or this work, or something that happened in the team.

I think there's a lot of power in asking people to support you to coming in and saying, “I really want to share something with you all and I'm not sure how it's going to go. Can you support me in this? What are you interested in hearing?”

The way I often say it, when I'm trying to say something controversially is, “Can I be spicy for a moment?” [laughs] And that's an acknowledgement of saying like, “Hey, I'm going to say something comfortable.” It gives people a moment to set their expectations and it gives them a moment to recognize how they should respond before they hear what you say and then are caught up in the emotion of the response.

I think that's a really kind thing you can do to your team to say like, “Hey, can I be vulnerable for a second here?” Like, “This is a project which involves researching prison populations and three of my family members are in prison.” If you lead off with saying, “Three of my family members are in prison,” people don't know how to understand that comment. But if you start by saying, “Can I be vulnerable for a second?” People will recognize that hey, you're showing something deep about you and your personality and it's something tied to your sense of identity, or something deep within you in a way that is not the responsibility of the team to validate, or say it's right, or wrong.

But it is the responsibility to the team to hear you and to understand you and ask questions to say, “Hey, tell me more about that. Tell me more about how that connects to this work,” or “Do you want to interview some of your family for research on this project?” [chuckles] Or “Do you want them to stay out of this project?” Or “How do we support you as a team member? Is this something that you want to acknowledge, but you'd prefer to put that in a box and keep it on the shelf, or is that a part of your identity that you'd like to bring to this conversation and bring to this work?”

I think those conversations like can really benefit from that asking for permission step and you don't really need to wait for people's answers there, [chuckles] but it gives you an opportunity to set the tone for the conversation.

JACOB: I feel like if I was working on your team and I saw Andrew use that phrase, “Can I have permission to be vulnerable? Can I be spicy?” I feel like later when I felt like I needed to be vulnerable, I would feel a lot more comfortable because now here's a map that's if I do this, it's probably not completely out of bounds and that now I have a way to know here’s how we go about that on this team, because there’s a leader who modeled it.

ARTY: Yeah, bingo. I was just thinking about all the different ways I've screwed things up and stuff and learned, I guess, the hard way, what boundaries are the hard way of what unsafe things are is by making mistakes and screwing things up. I think about some of these experiences that I had and I feel like the saving grace for me, even when I messed something up, is that I genuinely cared and that people knew that and could see that and so, that when I apologize for something, it was authentic and that we could move forward and stuff because I cared. Underneath it all, I genuinely care. So even though I made some mistakes and stuck with things that was okay.

And then after that, when I was thinking about being in more of a leadership position, one of the things I made a point of doing was putting mistakes and stuff I've made on center stage. Making it okay and safe for people to talk about when they screwed something up. Being in a leadership position, when I talked about all the things that “Well, I screwed up this thing, I screwed up this thing;” it makes it okay when our leaders demonstrate vulnerability, or create ways and pathways that show us how to do those things safely, too.

ANDREW: That reminds me of a friend of mine had a conversation with me last weekend specifically around a mistake that they had made and that mistake was in an online community. They were discussing building a world in a video game and they suggested building something that was offensive. They immediately dove into how they didn't know it was offensive at the time and that the reaction that other people gave to them was inappropriate and that they felt like they didn't know how to apologize in a way that would help support growth, or reengagement with the community, and that they felt like, “Maybe I'm just being canceled,” or maybe people are overreacting here.

After the whole conversation, I just let them talk out and they ended with like, “How do I reengage here when people are now ignoring me?” and I just said, “Well, you don't deserve a second chance.” Not that anyone deserves to be canceled immediately, or cut out, but when someone says something offensive that you take offense in, it's up to that person how much tolerance they have for you. If someone has decided that this in this situation was so offensive, or that their tolerance for that offense is low, you don't get a second chance there. That's a mistake that becomes part of you and hopefully, you can allow that burden to not rest on your shoulders and hold you down, but you can internalize it and learn from it, and it becomes part of the foundation you stand on so that you don't make these kinds of mistakes next time.

And also, [chuckles] demonstrating an aspect of my superpower, I disagree with you. I don't think you didn't know that that was offensive. [chuckles] I think you had that part of your brain turned off and hey, can we like talk about that? I think that this particular thing, you knew it was offensive, but you were thinking about this in a different context, or you thought this would be okay, and now you're rewriting this and placing yourself as a victim. That is a dangerous pattern so don't do that. [chuckles]

I think that in a work setting, tying this back, when you are having these difficult, or vulnerable conversations, being able to acknowledge when you've made a mistake, maybe perhaps when you've shared something that is offensive, or perhaps you've made a comment about someone else's moment that's offensive, it's really important to acknowledge the mistake to provide the opportunity for others to give your feedback and acknowledge that you've damaged trust here.

It's your responsibility as the person who damaged that trust to then rebuild it and maybe rebuilding that trust means leaving the organization, or changing teams, or maybe that means really, truly deeply listening and empathizing with people moving into that position of hurt that you've caused and being uncomfortable with it, especially when you're personally wrong.

When I'm personally wrong, I really feel that I want people to understand how much I'm hurt and if there isn't a great opportunity to share that pain with someone it's hard to accept their apology, because you don't feel like they understand. In those situations, it's up to the person who's done the controversial thing, or overstepped that boundary to step in and say, “Let's talk about this when you're ready.”

ARTY: And also, the other thing I'm just thinking is that when things do happen, we need opportunities and stuff to start over, too. Sometimes the right thing to do is walk away from the whole thing, but learn from it and there's always, there's so many people out there, there's so many opportunities out there, and we're surfing on the waves of life. We learn things along the way and there's always new relationships and things we can build and if we take those lessons and stuff with us for when we do screw things up that maybe we can navigate the next opportunity a little bit different.

I've had enough facepalm moments and stuff of just relationships where the things that come to mind for me are things where someone was put off from me because I'm kind of the passionate, excited person and not everyone knows how to deal with that, or might think I'm a weirdo, or something. So I'll scare someone away and I don't mean to. I'm like, “But I'm a nice person” kind of thing, but sometimes there's nothing you can do about it.

It's like this first impression thing that you can never really fix, but there's other opportunities out there, there's other relationships, and maybe the purpose of this interaction in your life is just for you to internalize and learn this lesson so that you carry it with you forward. We're all surfing on the waves of life and these kinds of things happen and it's not the end. It's just an opportunity. It's an opportunity to learn a lesson that then we can take with us into the future.

ANDREW: Absolutely. Yeah, I know. I've been fired from jobs, had friends cut me out of their lives and made a lot of mistakes. That becomes part of who I am and I carry that forward and I'm happy that I've made these mistakes in my past because they prepared me for making bigger mistakes in the future. What could be more fun?

CASEY: A lot of people get stuck on these experiences, thinking about them over and over and over in a loop and one way to get out of the loop is to correct the situation, which people like to try first, of course. Like, try to get back into that relationship, or community. Another way is to realize there's nothing you can do and move on, that's often called acceptance in meditation mindfulness terms. But it can be hard to get to acceptance if you feel like there's something you can do still, or something you could learn, you didn't learn everything you could yet and how to do that is hard.

It's a lot of the chapters in the book I wrote, Debugging Your Brains. I'm not going to go into that right now, but there are things you can do to get out of the loop when you're stuck in the loop. I feel so awkward ever plugging my own stuff, but it's so relevant. That's what we're talking about here.

[laughter]

Y'all don't mind, I know.

JACOB: No, I'm glad to hear about it.

CASEY: Now let's go to reflections. So at this is the part of the episode where we each reflect on something that stuck out to us. Something we'll take with us. Something that was interesting from today's episode.

ARTY: One of the things that stood out to me as we were talking about psychological safety, and these dynamics of leadership and who we choose as leaders as being important is this intersection between once we identify what the kinds of things are that we want to select for, that we can identify those people and then give them acknowledgement, the baton of an official hat to wear, and what the effect of that is, is a way to say to the organization of, “Oh, these are the normal things that we want to build around those characteristics.”

So there's this intersection between identifying those things and acknowledging that with – I'm holding up a little ball right now, give someone that baton, the thing, or whatever and that the combination of those two things is what creates the precedent for what is the normal we're trying to move towards. So it's not just the hiring, it's not just management things that we do; it’s the intersection of those two things that sets the norm.

JACOB: I'm thinking a lot about a possibility of getting stuck in a loop where people want to be vulnerable with each other, but they can't because they don't want to be the first one. [laughs] So I'm really thinking a lot about what are ways to break out of that and I don't know, it might just involve finding ways that people can be vulnerable about maybe something a little bit lower stakes and see if you can iteratively build up on that. Yeah, I'm thinking a lot about that like, how do you evolve the culture to enable vulnerability a little bit more?

CASEY: I'm taking away some metaphors and I wish I wrote them all down, but I have to go through the episode again. I remember Andrew's river metaphor, that it's wide, or narrow and you might have to row, or not and Arty, your cardboard cutout that if someone's arguing with you, you can imagine the cardboard cutout of yourself that they're working with to separate it from you. That visual metaphor is so powerful, I can't wait to use that myself sometime.

Andrew, how about you?

ANDREW: For me, to add to your list of metaphors talking about psychological safety, building psychological safety, and building a culture of being able to share vulnerable things and be able to provide each other feedback. That really builds the strong foundation so that you can build the house—the house being the project that you're actually doing, the work that you're doing without that strong foundation. I think the house is shaky. Doesn't have that firm foundation.

On the subject of being vulnerable and how do you break into that vulnerability, I think it's important to acknowledge the leadership here. Being the first to be vulnerable and being the first to follow are both demonstrations of leadership. So if you're looking at who on your team you'd like to nominate, or select to be your next leader, to create that sense of that culture shift, the person who's vulnerable and the person who follows, I think are great people to look at.

CASEY: Like that TED Talk, the first follower.

ANDREW: Exactly.

CASEY: I think you showed me that years ago, Andrew.

ANDREW: [laughs] Yes. The TED Talk about dancing on a hillside.

Right at the end here, if you don't mind, I'd love to put in a little plug. 18F is a part of the federal government and that means that I'm a federal employee and a civil servant. My salary is paid by all the folks that are paying the taxes. I just want to put on a plug for civil service. Not necessarily for 18F; that's just the area where I've found my talents seem to be best used.

But maybe for you, dear listener, that is your local government, maybe that's your state government, or maybe that means running for office. The government that we have is not perfect. It is the best one we figured out how to create and if you want to be involved in changing what the best is, or demonstrating that what we have is not as good as what you want, one of the great ways to do that is to be involved in changing it.

So if you haven't considered looking for a position as a programmer, as a project manager, as a product person, designer, all across the board, the government both, federally and state, and locally needs people like that so, trying to find those and figure out how to support them.

ARTY: Well, thank you, Andrew, for joining us. This was a great conversation.

ANDREW: It was such a pleasure. It was an honor to be a guest and hope you all have a great day including those that are listening.

Special Guest: Andrew Dunkman.

Support Greater Than Code