So then I guess I'll get started. Um So I'm uh Josie Ames. I'm the senior director of platform Engineering at Tile. And today I really wanna chat with you about engineering with empathy.And you know, when I first signed up to give this talk, I had no idea um how important this topic would be given, you know, current events going on today in the US and around the world. And I really had time to reflect over the last couple of weeks on how much empathy I have as somebody who actually talks about this and you know, how I can really be a better ally to my black colleagues and friends who are struggling, heartbroken and exhausted. And, you know, I actually had to admit to myself that when the protests started, I actually had thought, hey, why are people looting and rioting? Why is everything not peaceful? And you know, I reflected, and I actually watched a Trevor Noah video on youtube about where he took the time to talk about how the social contract has been broken for Black Americans on a daily basis and they're living in fear. And I realized I hadn't been taken into account this difference of perspective and I needed to apply more empathy there.

And I also realized, you know, this difference of perspective isn't just what we need to be listening to, but it's what we need to be taking action on when we're building technology. Because let's be honest, even though technology is impacting all aspects of our daily lives, it wasn't actually built to help everyone equally. You know, some of the challenges are voice assistants are less accurate with female voices as well as for those have accents, facial recognition software does not work as well with people with darker skin tones. And, you know, there's a lot of bias in the underlying data that's being used by the machine learning algorithms that power a lot of this technology, an inherent bias is present in our company cultures in the tech industry. That's why we have a revolving door of diverse candidates.

You know, in the last 20 years, companies have spent billions of dollars in diversity and inclusion, but the numbers really haven't moved much. And at the end of the day, you know, why would you wanna stay in a career if you're constantly being discriminated against? And, you know, it's usually not a big event or an overt occurrence. You know, as I'm sure a lot of, you know, it's usually done by 1000 paper cuts, having your ideas appropriated being spoken over, being passed up for promotion, you know, being assumed to be non technical when you're actually in a technical role, despite having been an engineering director for many years, people still assume I'm a project manager when I show up to partner meetings sometimes.

But what we really need to be instead doing is creating cultures of belonging where diverse team members cannot just exist but where their ideas and opinions are heard and acted upon and they can actually thrive and to create these cultures of, of belonging. We have to embrace empathy and take action on it. And today, I really wanna focus on empathy through the lens of an engineering team. And a lot of times engineers are really focused on growing their technical skills. But I think empathy can be one of the most valuable tools an engineer can have, you know, empathy can be learned and it's actually something you can get better at with daily practice, you know, as an engineer, how many times are you giving feedback to not just your other peers, but you know, on product documents and designs as well or figuring out what features are most important to focus on and build, you know, all of those things can actually be accomplished more effectively and successfully by looking at them through the lens of empathy.

And I keep talking about empathy, but I haven't taken the time to define it. So I wanna start there. And one of my favorite definitions of empathy comes from Renee brown who's a shame and vulnerability researcher and, you know, she defines it as really being made up of four components. The first one is being able to see the world, as others see it. You know, as engineers can we take the time to see the world through the lens of all of our potential customers and our diverse coworkers. And, you know, can we learning be learning about their cultures and challenges to do this more effectively? The second one is being nonjudgmental.

You know, it's easy to point fingers and play the blame game. Hey, we even have a command, get blame to figure out, you know, who committed a certain line of code. So what if instead of blaming others and shaming them? You know, we assume that hey, our colleagues are trying to deliver their best and maybe there's a reason they did things a certain way. And what if we instead treat everything with curiosity instead of jumping the gun? The third one is really understanding another person's feelings and engineers kind of get weird with me when I talk about feelings. But you know, you're not building code in a vacuum, you're interacting with other human beings, day in and day out and not just not only do your colleagues have feelings, your customers have feelings too and if you don't understand them, it's gonna be harder to build an effective product as well as how to effectively collaborate with your team.

And finally, number four is being able to communicate your understanding of that person's feelings back to them, you know, to be able to have a constructive discussion, you have to do this and, and a lot of arguments could be avoided if we just acknowledge somebody else's feelings, that doesn't mean you have to admit that it's right.

But a lot of times people just need to feel understood and especially if you want somebody to change something or provide them feedback. If they don't feel heard, there's no way they're gonna accept it. And of course, having empathy isn't in it, in and of itself enough, you have to take action on it. And hey, that's actually also the hard part. So today, I actually wanted to talk about practical things that you can do right away after this session. And so we're gonna talk about applying empathy to code reviews as well as other engineering practices and processes. So, hey, we can all we can all work towards creating this culture of belonging and hey, build more inclusive products. And you know, before I dive into some of the more explicit examples of empathy within engineering, I like to start with something that I think is the cornerstone of empathy and it's active listening. So take a moment and reflect in maybe the last 24 hours. How many times have you had a conversation in a meeting? And you are either not fully listening or halfway through somebody saying something, you were already formulating your response and you didn't really listen to the second half of their sentence. You know, what are your triggers that get you distracted? Especially with being remote now, you know, it's easy to get distracted by slack notifications. There's, you know, other people, you know, emailing you.

So I try to turn off all my notifications during meetings so I can fully be present and so take a moment and hey, maybe take a challenge for the next 24 hours. See if you can fully be an active listener in all of your meetings. But as I said, I wanted to dig into how empathy applies for engineers. So let's start with code reviews. And so when I went to create the slides for the talk, I wanted to find an example of a coder view that lacked empathy and you know, to provide us to so I can have a star counter example. And I landed on this example from Linus Toral. Anybody who thinks that the above is a legible, be efficient c particularly safe is just incompetent and out to lunch. And actually this is just a small subsection of a much larger rant that included cursing that I did not include. And of course, you might say, hey, this is an extreme example and you'd never write anything like this. However, how many of you have started a sentence and are guilty of saying, why didn't you I'm sure I have at least once or twice when I've been frustrated. You know, why didn't you remove this variable? Why didn't you just return here? But I know I don't feel good being on the receiving end of a, why didn't you statement? So I doubt our colleagues are either.

And so what if the reviewer instead said something like, hey, I don't see the variable XYZ being used elsewhere in the code. should it be removed? And you know, a code reviewer's main objective isn't to be right and have the person who wrote the code be wrong. You know, it's about providing suggestions and being curious about the ways to improve the code to create a better product and the code may not be perfect or up to your expectations. And that could be because of constraints the developer faced and you know, it could be anything from time to share unrealistic expectations. Do you know anything going on right now? And as a reviewer, if we take the time to dig into what some of those constraints are, it allows us to have more empathy in the reason the code may be written the way it is. And I think we should really treat code reviews as a learning experience for both the reviewer and the creator. And you know, I've been talking about empathy from the side of the code revere, but it's also on the person who wrote the code as well. And I know once I've been done with writing my code and tested it and I'm about to create my pr I usually just wanna get it shipped and move on to my next thing.

But you have to remember, your colleagues are gonna review your code, didn't just go through the last couple months of coding and gotchas and meetings with you. And so they need context if you want them to be most effective at reviewing your code. So you know, make sure you're creating good pr descriptions with links to Pr Ds and architecture documents. I tell everybody to think of it as a fact finding mission. You know, if in a year or two, you and your somebody in your team had to fix the bug. Could you look at that pr and actually be able to find, you know, ha find interesting gotchas in there. Hey, pull, requests can also become great artifacts for future history and you know, you can apply this to more than just uh code reviews. You can apply this to the whole development process for your code, commit messages and github, you know, they can have useful descriptions that actually say what was in the commit it. You know, if we applied this, we could have better documentation where you could much more easily onboard new developers as well as the fact with us being remote now, having more documentation will actually empower a lot more collaboration. And you know, I've been focusing on feedback within code reviews, but you know, engineers are constantly giving feedback, not just to other engineers but you know, cross functional team members as well who may not be as technical.

You know, we have to line on product requirements, documents, architectures UX designs and schedules and you can apply empathy to all of these situations to actually make them more collaborative. And you know, the engineers that I know who can collaborate the best are the ones who, you know, do you take the time to think with empathy and think, hey, how do I need to explain these things successfully to my non technical colleagues? And you know, there's, there's this trial and balance between engineering design and product and healthy tension is always great. But I also have seen this sometimes degrade into unproductive discussions, you know, where people are speaking at each other instead of listening.

But you know what if instead, you know, when you notice that about to start happening instead of being frustrated and triggered and digging in, you know, you stop and think with empathy about the other person, right? At work at the end of the day, all of you are trying to create an amazing product to hopefully fulfill your customers needs. And so can you align on that goal and see each other's differences or just two sides of the same coin? And so one of the last areas I wanna focus on today is you know, how empathy is really needed to create the products that fulfill the needs of our diverse world. And you know, I started with this as well and I think that even back end engineers should have an opportunity to talk to customers, read their feedback and really understand their challenges by having empathy for what the customers needs are and how those might be different from our own.

It can actually change how we write our code, what the UX looks like or even what features we provide. And we need to take the time to do that by looking at their perspective, emotion and like I said, withholding judgment. And while I've been talking mainly about customers here, this applies to our diverse colleagues as well. Hiring diverse team members is what's gonna provide us different perspectives that we may not be aware of. And if we take the time to truly understand and appreciate those, we can build better products that not just account for but actually fulfill the needs of our diverse world. And what I've covered is really just the tip of the iceberg when apply when it comes to applying empathy to engineering. Um I haven't delved into leading with empathy, how empathy can be applied to meetings. Uh There's a lot of different topics around empathy I could get into, but those have to be another topic for another day because there's only so much I can cover in 20 minutes. But you know, if you want to know more, you can always reach out to me on linkedin. But I wanna finish with empathy is a skill and like I said, we can get better at it with time and daily practice.

So I'm gonna explore each of you who are listening to me today to take some time to reflect on some of the things I shared and maybe take one thing you learned and apply it, but not just today a little bit every day. So after the session, pull out your calendars and schedule 15 minutes every day to s to see how you can maybe apply more empathy in your daily life. By engineering with empathy, we can create more effective teams that produce better products as well as providing a space where diverse team members can thrive. And I think empathy and taking action on it is one of the things that will lead us to the companies of the future that can truly create the technology that fulfills the needs of our diverse population. And hey, as the current events in the world show that's the future we need today more than ever. Thank you. All right. Does anybody have any questions we have like one minute or two?

OK.

Yes. Feel free to type any questions you have in the chat. Ah help people be less personally attached to their code. Yes, I I think one of the things that somebody said to me is when you're writing code, review comments, think about it as being a copywriter, right? And try to think about it and instead of say, and try to think about things from like a second person point of view. And, and so it's all about not like you wrote this bug, but hey, I saw this issue in this code. Um And so yeah, I think it's really about the, the, I think people get attached to their code because they, they created it and you know, this is a creative expression for them. But I think it's also an opportunity to, hey, be willing to be more vulnerable and create a culture of vulnerability. All right, the last question is OK, you show empathy to your subordinates and your boss calls you weak for it. How do you continue to show empathy? Well, I first I have to say, I'm sorry that your boss calls you weak for uh showing empathy um because, you know, showing empathy is not a sign of weakness. Um And uh truly to, to be creating, like I said, these, these companies of the future that are going to fulfill the needs of our diverse world. And you know, get us to be an anti racist society. We need to be showing empathy.

Um So I don't know if you can talk to other people in your leadership team about empathy and see if you know other people within your company also value empathy. And you can make it kind of a grassroots effort. So then it's not just your boss against you and it is, time is up right now, I think. And so um it was great getting a chance to chat with all of you. And if you have any more questions, like I said, please feel free to reach out to me on linkedin. I'm happy to answer any questions anybody has.