Compassion At Work And How It Helps Collaboration Between Designers & Engineers

Karolin Siebert at UXDX Community: Barcelona. Video: https://www.youtube.com/watch?v=yIu1yN1U12A

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From designer to the developer in the basement

[00:00:00] Hello, my topic is compassion at work and how it helps collaboration between designers and engineers. I'm a software developer, working in the field for five years after having transitioned careers from design to engineering. I guess that's also why this topic is really interesting for me, because I've often been wondering about how to improve the processes, how to improve the collaboration and how to just communicate in a more efficient way.

[00:00:38] I always had this stereotype, and I'm not the only one, of a developer being somebody who works in a basement, rather isolated. And especially working remotely, I turned into that developer. I enjoyed it a little bit, but whenever I wanted to communicate with my peers and collaborate with them closely, I sometimes had problems, because the communication didn't go as expected. I realized that I was disconnecting from my job and my team, but I didn't really understand why.

[00:01:24] About two years ago, I read a tweet from April Wensel, who introduced the concept of compassionate coding. She also has a company with the same name, giving workshops in tech companies and at conferences about how to use the learnings of emotional intelligence in the workplace. There seems to be a contradiction already in the term compassionate coding, because compassion is a human emotion, and coding is the rather rational work of a developer.

What compassion is and why it matters

[00:02:16] So let's try to identify and define what compassion actually is and where the term comes from. It's not just an emotion, because there's an evolutionary purpose behind it. And if there's scientific proof, and if there's a purpose, for me it's always really convincing to get interested. Babies of the human race are born with giant heads. That's why when you try to sit them up or make them stand up, they just tip over. This is because humans are pretty intelligent, and they have giant heads. If we hadn't learned to be compassionate as human beings, we wouldn't have made it to where we are now as a human race. That's why compassion is so important.

[00:03:21] Let's try to sort this out again. What does compassion mean? It first means seeing somebody suffer and having the desire to help. I'm always linking the sources of the things I mention at the bottom. This is one example of an individual of the human race with a giant head. It really needs help; otherwise, it would just lie on the floor.

Suffering in tech

[00:03:55] An interesting question I also asked myself: why is compassion so important in tech? That's because there's actually a lot of suffering in tech, also in other fields, but especially in tech. I'm going to go through a bunch of examples. Technology can lead to suffering because technology by default doesn't respect privacy, and some applications haven't implemented the right privacy rules or regulations. Tech can also lead to addictive behavior, because some interfaces are designed to attract humans to interact with them.

[00:04:46] Another interesting example is imposter syndrome, something I've definitely dealt with during my career transition from design. In case anybody hasn't heard of it, it means worrying about your self-worth, about your knowledge, while trying to get stuff done at work with your newly acquired knowledge.

[00:05:12] Another very important point is that the language in tech and in engineering teams can be unfavorable to the human being. Let's look at a couple of examples, which is always helpful. One is definitely "read the fucking manual." That's something people have to hear if they ask a question and people are basically too lazy to explain it in their own words. Especially as a new developer, you really have to learn how to read documentation first. Then, if somebody tells you, "You just don't get it, and there's no place for you to work here," that's definitely going to be disappointing and demotivating. Also, the way it's phrased is not exactly ideal.

[00:06:15] I think developers often say, "This code base is a nightmare," even if it's about their own code or another company's code. It's just not the right way to phrase things. Then I have definitely seen before, maybe even said myself, "Let's do the mom test," assuming that somebody from the older generation or the other gender might not be able to understand your complex technology. But it's not really the right way to communicate.

[00:06:59] Another important point to mention is that we do sit down a lot at work as engineers, and it actually leads to physical pain. And we do have tight deadlines and work overtime, which can lead to a lot of stress. We should also not forget that as an engineer, continuous learning is the standard. We do like it and feel challenged by it. I definitely love learning all the time. But we have to keep in mind that learning new programming languages and technologies requires changing habits constantly, and that is hard.

Self-compassion and reframing

[00:07:51] Now let's get more practical. Where can we actually start to be more compassionate at work? This is a pretty simple one. It sounds a little bit hippy, touchy-feely, but it can actually be very useful: practicing self-compassion. One simple exercise could be, when you make a mistake, try to observe yourself and see how you talk to yourself. Let me give some examples of something you've probably said to yourself before: "Why was I so stupid? Why have I done this this way? Why have I written something like that? I could have known it before. I'm so silly." The question you should ask yourself, though, is: would you talk to a friend like that?

[00:08:56] Self-compassion should definitely not be mixed up with self-pity, because it's a completely different thing. Practicing and learning self-compassion leads to resilience, which will make us stronger and more reliable in the workplace. Surprisingly, studies have shown that when our self-worth depends on competing with others, we tend to have more anxieties.

[00:09:31] So how do we use this every day? One thing I definitely asked myself while learning about this is: can compassion really be trained? It really made me wonder, because I like to see the scientific proof of things. There are studies that have shown that yes, you can train it. There's a technique called cognitive reappraisal to practice it: people learn to reframe their thoughts to feel less negative about things.

[00:10:09] I've tried to bring one simple example. Let's say a new member has joined your team, and your first thought is, "Okay, let's see how they find their way around the code base, around what is already out there." A better way to think about that new person would be to see how they're suffering, and how you can actually help them to have a smooth start. That would lead to rather positive emotions for them, and would be being a really good teammate.

Descriptive language instead of judgment

[00:10:54] Then something which has a huge, huge impact if you implement it, and it's actually hard: if you observe yourself, we're being judgmental all the time. But the right way to go would be to use descriptive language. I want to go through a couple of simple examples which have a very subtle difference, but they're super amazing.

[00:11:27] I will tell you a little story of something that happened to me. I was a new engineer; I had started to work in the field maybe six months before, and I was having a pair programming session with one of my peers. I was looking at his code and he was explaining to me what he was doing, and I kept asking questions, because I really wanted to understand well. After a while he kept saying, "No, you don't understand me. No, no, no, you just don't understand me." And I thought, why am I feeling so off, why am I feeling so down because he says that? If you look at it logically, it's not offensive, but it could be said better. The nicer way to say it, because there is no right and wrong, would be to say, "I did not explain myself right," assuming from his side that it could have been described better to a newbie.

[00:12:31] Let's go to the next example. I am presenting my new idea to my boss, and he says, "That's not going to work." That's a pretty clear message. The problem is that this ends the conversation, because he already decided for both of us that my idea is complete nonsense. The better way would be if he would say, "That's one option, but I do have my concerns." I think then we could actually come to a conclusion together and have a proper conversation about it.

[00:13:09] The last example would be, let's say, the UX team and the engineering team have a meeting, and at some point somebody stands up and says, "We will never agree." That's pretty negative, right? The better way would be to say something like, "Let's look at what we have and see what we can do with it." Do you see the difference between these two ways of expressing yourself? I think they're subtle, it's true. I also had to learn how to differentiate between them. You can definitely work a lot with I-statements and express your feelings about stuff when using descriptive language. There is a lot to learn about it, which will have a very high impact.

Compassion and effective work

[00:14:02] This also made me wonder again: being kind with each other all the time, can that really lead to effective work? Good question. Actually, many software projects fail because of a lack of communication and a lack of documentation, which is basically what brings people together, because they have shared knowledge and a shared understanding about some things. So finding a way to work well aligned with your peers can actually prevent failure at work in companies.

[00:14:43] This is one of my favorite visualizations, infographics, about compassionate coding, because it brings up a bunch of really nice examples of values that we should think about. Let's just talk about the last one, because it's my favorite one. I've often seen job ads requiring that developers should be a rock star. What does that even mean? To be honest, I never wanted to be a rock star. I think the great alternative that April Wensel, the founder of Compassionate Coding, came up with is to be a great mentor. That is somebody we should respect, right? Because that's somebody who's giving to the community, who gives back to the team, who can really be providing to the whole team and not be the one who competitively stands out.

Applying compassion between designers and engineers

[00:16:03] Now let's come to the most interesting part. How can this actually be applied to the way designers and engineers collaborate? Let's imagine I see my colleagues in the UX team suffer because they don't understand my code, and I decide to document this code to make it accessible for everybody. This is how I could reduce suffering a lot. And it also goes the other way around. I want my UX team to document all they do, so I can access it as an engineer and see what it's about and get the full picture.

[00:16:50] Here I'm mixing in one of my favorite quotes, because it really describes what I believe about software, about code: "Programs must be written for people to read, and only incidentally for machines to execute." If code is not so cryptic in the first place, it might even be touched again, and it might be easier for others to understand it. Let's say the UX designer wants to make some small changes to your work or add some styles to it, and they cannot even find where to put stuff. That means it's not well-documented code. So another simple step could be making your code more readable, simplifying it, sticking to the best practices of your language or of your framework.

[00:17:59] Another simple step is to explain what you're doing, because seeing your colleagues suffer because they want to understand what you're doing should be avoided. This is another very interesting one, and it actually looks at the user. If the user is suffering a lot because your software has a lot of bugs, then maybe it's the right time to write good tests. That's where collaboration between UX and engineering teams comes into play again, because the UX designer is actually the one who designed the user flows and will be aware of the tests, for example the acceptance tests that should be written.

[00:18:48] This is one of my favorites. I really like to agree with the design team about the naming of things. Let's say you have a UI component that is called one thing in the code base and then has a different name in the UX workflow. That is inconsistent. So make sure that you're documenting your components, your services and your APIs super well, so that designers and engineers speak the same language and are informed about each other's work. Basically, really respect each other's work.

[00:19:34] This one is rather from the UX side: give the engineers access to the prototypes, data flows and wireframes, so they can be aware of the whole process, and maybe explain it really well in a meeting, appreciating each other's opinion. Because one thing that makes people really unhappy at work is the feeling that their opinion doesn't matter.

Coming out of the basement

[00:20:16] So what's actually the conclusion of all this? Don't judge your peers' or colleagues' work or their opinion. Don't educate them about what's right or wrong, because there is no right and wrong. Ideally, the outcome of all of this would be to build really nice connections with your colleagues, because you're not competitors. Don't be fake nice. I really don't like fake nice; who does? And be authentic. If, for example, you realize that you don't have time to help somebody who asks you for help, better to say no and postpone it to a day when you're actually available, rather than being there only half-heartedly.

[00:21:11] But when you mentor, observe how much you actually learn from helping somebody. So all of this is basically about how I turned from the developer in the basement, a bit isolated, into the one who comes out from the basement and really interacts and collaborates a lot with their colleagues. And to be honest, it's much nicer to be with a bunch of people who are taking on challenges together. Thank you very much for listening. I hope you enjoyed it, and I'm very curious about your questions.