“What are your goals for this quarter?” It’s the question every manager asks, and one that often prompts a flurry of technical objectives and project milestones.
Jumping into this internship, I knew my answer. I wanted to practice making informed decisions on my project, since that was one of the challenges I faced last summer. As an intern, I struggled to form a strong opinion without as much context as my team members, and I thought that this decision-making prowess would come naturally with increased technical knowledge and familiarity with the codebase. But as I dove into my work with the accessibility team, I realized that many of the decisions I needed to make also required understanding end-user impact and making compromises accordingly.
At first I was intimidated by the need to take all these things into consideration. At school, 90% of the time my code is graded by an automated process, meaning that I never have to be intentional with my choices. I mostly try to fix errors and pray that more green appears the next time I hit submit. The other 10% of the time, I’m given a clear rubric outlining exactly what I need for my project to succeed. With this being my experience, how am I qualified to choose what’s best for the users?
Accessibility in particular is a very special space for user experience, where it is important to eliminate barriers for all users by considering varying abilities and situations. I didn’t want to make the wrong call and I ended up deferring to my team’s PM and designers for most decisions. However, I soon realized that mindset was holding me back from participating in our team conversations, and I wasn’t challenging myself to come up with solutions to problems. So, rather than just focusing on sharpening my proficiency with React, I committed myself to understanding the user experience.
A bit about me
- Hi, I’m Lena! I’m going into my senior year at Duke University, double majoring in Electrical & Computer Engineering / Computer Science.
- This is my second internship with Slack, but I was on iOS Infrastructure last time, so accessibility is a completely new space for me.
- I’m in Seattle right now, but I was in San Francisco last summer. That’s a pic of me wearing my SF jacket on the Seattle-Bainbridge ferry! :)
The importance of empathy
Working on the accessibility team at Slack this summer, I’ve learned that understanding our users—really understanding them—is key to building products that serve everyone. Developing an intuition for good user experience is just as important as writing effective code. While this is especially apparent in regards to accessibility, this user-centric thinking applies to any engineer working on any part of the codebase. The main goal of any product is for it to be used, therefore we need to create something that people want to use. Empathy is about understanding who your users are, what they need, and how they interact with your product. How are features used in real-world scenarios by various users, and how intuitive does the overall experience feel?
The idea is not to turn all engineers into PMs and UX designers, but to facilitate collaboration amongst everyone. Just as product managers and designers need to consider technical constraints when making decisions, engineers need to look beyond the code and consider the human aspect of what they are building. This will enable more meaningful contributions to conversations about the product direction.
I also think knowing who we are developing for and why we are doing so is key for finding fulfillment in our work. It’s one thing to say “I write code” it’s another to say “I solve this problem for people by writing code.” Coming straight from college, where my biggest motivator in completing my projects is my GPA, it’s really exciting to know that what I create is actually helping people, rather than rotting in a Git repo indefinitely.
How to engineer with empathy
Now, you might ask, “that sounds great and all, but what are some tangible steps I can take?” I believe empathy is both a trait and a skill, meaning that we all innately have it, but we also need to practice to improve it. I’ve outlined below some things that have worked for me.
1. Abandon any preconceived notions or attachments
It’s natural to form biases about a feature you’ve worked on: you’ve spent so much time and effort on it, plus you have a preconception about how it’s intended to be used. After all, by testing the feature repeatedly during development, you are its most avid user (and its number one fan). However, it’s important to keep in mind that someone else may have a completely different experience – what makes perfect sense to one person may be confusing and disorienting for another. In these cases, as difficult as it may be, I try to abandon any assumptions I have, and accept new ideas with an open mind. I know I feel a strong sense of ownership over anything I build, and it is tough when I need to drastically change something, but I never want that to prevent me from making the right decision for the product and the users.
2. Engage with actual users
Engineers don’t interact with users on a daily basis. Typically, customer feedback gets passed along a well-established pipeline, with the prioritization and filtration of issues being done before it reaches us. This is necessary and for our benefit, so we don’t get overwhelmed with a constant influx of tickets, but it does mean we have to actively seek opportunities to connect with users of our product.
An experience that has been very informative for me is attending product testing calls with our accessibility consultant. He is a blind individual who uses both screen readers and Slack extensively, and hearing his perspective on what feels most intuitive for him versus what poses a challenge has been incredibly helpful in understanding the screen reader experience. It’s really interesting to see how someone navigates using a feature for the first time, as they may find pain points you never considered, or surprise you by using your feature for a completely unintended use case.
3. Watch the pros at work
I’m lucky to work with an incredible group of qualified designers, engineers, and product managers. Whenever I’m at an impasse, I can always tag someone in the project channel and get their opinion. The key to this is being inquisitive and to think critically about their response. Rather than just accepting their answer and immediately implementing it, I like to ask for their thought process and share my own. “Why do you suggest we choose this over the other option I was considering? Can you explain why this wouldn’t work for this user group? What about this use case?” By understanding how others apply empathy to problem solve, I’m training my own intuition to make effective decisions in the future.
My team also hosts weekly office hours where other teams come with questions on how to improve the accessibility of their features. This has been a great learning opportunity for me, since I can watch how my team members approach a completely new problem each session, and weigh the pros and cons of different options out loud. It’s also been valuable to observe how other engineers actively listen to my team’s suggestions and bring their unique understanding of any technical or logistical constraints to the conversation.
4. Practice raising ideas to the team
This one mostly goes out to fellow interns or newer developers who still find it intimidating to talk during team meetings or in the team channel. At first, I was nervous to “waste time” by suggesting an idea that wasn’t viable, or bring up discussion topics that would take time away from other people’s issues, so I didn’t speak beyond my weekly standup updates. If you have a similar train of thought, DON’T! You never know when a question or idea will spark a great conversation that’s important for either the project or your personal learning.
Listening and observing is key in the previous steps, but actively applying those insights to novel ideas is where I’ve truly grown—and team conversations are the best way to get feedback on these thoughts. As I’ve gained more confidence throughout the summer, I’ve been more vocal, and I’ve noticed I’ve progressed much faster as a result. As much as I have learned from 1:1 chats, there’s something special about bouncing ideas off of each other as a team, bringing in multiple perspectives at once.
The bottom line
You’ll notice most of these points are just generally good practices for working on a team and for career growth. That’s no coincidence: practicing empathy makes you overall a better engineer, coworker, and human! It benefits you and those around you. So next time you’re setting your goals for the quarter ahead, add engineering with empathy to the list.
Interested in taking on interesting projects, making people’s work lives easier, or just building some pretty cool forms? We’re hiring! 💼 Apply now
