Recently I have been getting more interested in the people side of work, how we work together to get the best results. Getting this right is way harder than the coding side, right?!
In particular, I have been noticing how people treat each other in tech industry: in work, at events or online. In my opinion there is room for more empathy in our interactions with each other and this will not only make working in tech a more enjoyable experience but make our products better.
So, after discussing this with some attendees at Lean Agile Glasgow a few months ago, I found myself giving a talk on Empathy in Tech at the March event. In preparing for this I did some research on the topic as well as thinking about my own personal experiences and those of my friends in tech.
-----------------
So first of all, let’s clarify what I mean:
“Empathy is the capacity to understand or feel what another person is experiencing from within their frame of reference, i.e., the capacity to place oneself in another's position.”[1]
For me that last part is what I am looking for, let’s put ourselves in someone else’s position when we are working with, talking to or criticising them.
The main areas for my talk were broken in to:
- How do we treat developers?
- How do developers treat each other?
- Empathy in recruitment
- How do we treat “non technical” people?
- How do we treat users?
How do we treat developers?
Since I am a developer, I of course think of experiences in industry from a developer’s perspective, so starting here made sense. One recurring theme when speaking to developer colleagues and friends is the feeling of being a “resource”, a tool to get things done, by other areas of the company. Since we are ultimately how the project gets produced, I do understand why this is the case. However, I urge those in PM and other roles to have some empathy for us. Yes, we are in sprints planned out for specific hours and have set tasks to output, but let’s remember we are human. Your developer might be less productive one day, maybe they are ill or stressed or perhaps just having an off day. This is a job where burnout isn’t uncommon, let’s look after our developers and ensure they are given support when showing signs of stress.
I found some interesting articles on developer burnout:
How do developers treat each other?
I started this section discussing the language we use when speaking to each other:
- “Easy”/ “Just”- simple, non offensive words that can have such an impact. We often hear developers sharing their work and saying “uch, it was easy I just {*insert really complicated set of instructions here*}”, this is something I am also guilty of! It’s only easy once you know how, but by labelling it as easy will affect the more junior developers or those lacking in confidence. Trust me, having been that person sitting in presentations like “Oh it’s meant to be easy? But I don’t understand, I have never done that. OMG I am a terrible programmer, better not ask any questions incase I look dumb” <- insight into how quickly the self doubt can spiral right there.
- “Oh, you use *that* framework/language”- We can be quite a judgement bunch of people as developers. We are passionate about what we do and pride ourselves of being knowledgeable, but let’s have a think from the other person’s perspective before jumping to judgement. Maybe they use that tech because that’s what they use at work and it’s out of the developers control to change it, maybe they haven’t had time to learn the new frameworks yet due to family commitments. Yes, we would love to all be using the newest and coolest tech but we also have to pay the bills, so sometimes compromises need to be made.
- “Real developers use X,Y,Z”- I could rant all day about this concept of what a real developer is and I wouldn’t want to offend anyone by giving specific examples of what I have heard be questioned as real developers. So here is a useful XKCD cartoon to make the point:
- “He”- Now, this one is again specific to my experience in tech. I work with mostly men, I attend conferences with mostly men and I imagine most of you reading this have a similar experience… but please, pretty please, when you are discussing hypothetical developers, don’t refer to them as “he”. “So we are recruiting for a front end developer, he will be working on that project”... Before you have even chosen a candidate, you have subconsciously decided they are male. “We are going to allocate a task to each developer and he can report back on research”. Now, imagine being the only “she” in a room of “he’s” and how it must feel being completely removed from the conversation, even if only accidentally.
This led to a discussion on diversity and putting yourself in other people’s position. You may think that little comments like the “he” example above aren’t a big deal or when you make “just a joke” that we are just over-reacting when we are offended of upset. But imagine if that’s several times a week, it can quickly get very annoying and contribute to feelings of self doubt.
Since I am discussing Empathy, I have put myself in the position I am not in: in the majority in tech. I understand it might feel like you are under attack, everyone always says “Tech is all straight white dudes in the 20s/30s” when discussing the issues in tech. Now, it’s not that we don’t want these people in industry, we would just like it to be a bit more diverse. We don’t want to take away from those in the majority, but contribute more to it which will end up in better solutions for our customers.
Empathy in recruitment
Next up was the topic of recruitment and just how intimidating the recruitment process can be for a programmer. Some examples of potentially intimidating/ off putting recruitment phases that could mean you are losing out on some great talent:
- Trials (working in the team for a day/ 2 days etc)- I understand the good intentions of this, see if the candidate likes working with the team and vice versa. However, I personally think this is a red flag of their work life balance expectations, if the company wants me to use 2 of my days off to attend an interview. Also, these companies may be unintentionally limiting their available list of candidates, people have family and life commitments that could make this not a possibility. You could be missing out on an awesome developer due to your recruitment process being too demanding.
- Whiteboard interviews- How stressful are whiteboard tests though?! I have only had to do this once, but I was fresh out of uni and I swear time stopped as I stood up there in front of 2 interviewers while I tried to search my brain for an answer. These situations can be overwhelming for some people and they aren’t really a test of working conditions. Someone who could solve a problem super efficiently at their desk under reasonable conditions may not under pressure at a whiteboard, you don’t want to miss out on them!
- Technical tests- I do understand the need for a technical test, despite some debate in the room when I gave the talk. It lets you see how someone works, prioritises tasks and architects thier code. In an industry where many talk a good game, it lets you see someone’s level rather than their ego! However, I think it’s important to let people do this at a time that suits them rather than having to come in to the office.
- Job ads- There are examples of how (not) to word your job ads[2]. You may be excluding people who would be perfect due to the wording of your job listing.
This was the part of my talk that caused the most questions and debate during the Q&A… Hopefully this is a good thing that it got people thinking?!
How do we treat “non technical” people?
Ok, so this one was a bit of a trap as I asked who had ever referred to themselves or someone else as “non technical”... then sharply said “well, don’t!”. Having read April Wensel’s “If you can use a fork you are technical” article, I often interrupt meetings when I heard the term used.
From the non development side: “sorry but I am not technical” it’s used as way to distance themselves from a situation but also to put themselves down. From the development side it’s used to make their opinion less credible: “but they aren’t technical”. What defines technical anyway? We are all working on a project to deliver an app/ service/ product, each bringing our skills together to do so. What makes our skill more technical than a business analyst, designer, project manager, tester?
As my selection of gif shows, I think this creates an “us and them” dynamic in the team, and that’s not productive:
How do we treat users?
How many times have we heard “users are stupid”, “why would they use it like that?! Idiots!” etc… they aren’t idiots, perhaps it’s bad UX or not accessible.
Bringing it back round to diversity, having a diverse team both devs and non devs, we will have a wider group of society to get opinions on the product before it goes to the public, hopefully making it more suiting to everyone. If an app is built by 10 Scottish guys in their late 20’s, is it going to be suitable for everyone else? Likely not.
There are somethings we can do to try to mitigate accessibility issues: making sure fonts are readable, adding meta tags, including screen readers in your device testing. These are not massive things but will make a big difference to ensuring your audience has the best chance of using your site.
Now what…
So what can we do to have more empathy in tech? Just think how the other person might be feeling! Next time you are about to judge someone: why did they implement something a certain way, why can’t they work over time, why can’t they use the site properly? Put yourself in their position before being quick to judge.
Thinking of others will help us all be happier at work, be more productive, learn more and make better products!
As always, I would love you here feedback :) Catch me on twitter.
------------------
Video of the talk here: https://productforge.io/livestreams/lean-agile-glasgow-march-2018/ and also talks by 3 awesome speakers: Becca, Caroline and Marnie.
When I asked on Twitter for people’s thoughts on Empathy in Tech I was sent so much advice, people to follow and recommended readings. So, I thought I would share this collection!
Who to follow:
https://twitter.com/sharonsteed
https://twitter.com/aprilwensel
https://twitter.com/AdamMGrant
https://twitter.com/DrDanSiegel
https://twitter.com/DanielGolemanEI
Recommended readings:
https://slack.engineering/on-empathy-pull-requests-979e4257d158
https://medium.com/compassionate-coding
https://medium.com/coding-with-empathy
http://www.draconianoverlord.com/2017/08/18/compassionate-reviews.html
https://rework.withgoogle.com/print/guides/5721312655835136/
https://flowchainsensei.wordpress.com/
https://www.pivotaltracker.com/blog/use-empathy-build-software-products/#.WmN2c13YI7g.twitter
[1]https://en.wikipedia.org/wiki/Empathy
[2] http://www.greenhouse.io/blog/ninjas-rock-stars-and-other-ways-to-ruin-your-careers-page