Cultivating Empathy in Tech: Not Just a Pipe Dream
An increase in empathy across tech teams can result in streamlined product delivery and a boost in engineer morale.
Every developer has faced an all-too-common scenario at least once during their career:
You are sitting at your desk, headphones on, lines of code in front of you, deep down the rabbit hole of problem solving, building, architecting, when suddenly you feel an abrupt TAP, TAP, TAP on your shoulder. Not only does it likely scare you out of your pants, but it immediately breaks that very critical concentration you worked so hard to obtain. You glance over to see a product manager or QA engineer or fellow developer standing there, and you knock your headphones down to talk to them. They offer some small apology for the interruption and ask a question along the lines of, “Hey, you know that thing you’re working on right now? Well, when will it be done?” You give them a curt answer and they thank you and go about their merry way. You sigh, put your headphones back in place, and dive back into code, only to find yourself lost in a sea of “Where on earth was I?” So you work diligently to put the puzzle pieces back together and get back in the zone, at least until the next time you’re interrupted for a seemingly unimportant reason.
Sound familiar?
Coding is complex, and it takes just the right concoction of solitude and focus to do your best work. There is so much to consider — not only are you attempting to build out a new feature or fix a complex bug — but you’ve also got to do it in a way that is clean, scalable, testable, and up-to-date with the newest language and syntax conventions. A brief interruption may seem like a small inconvenience to a developer, but it’s one of the many symptoms of a tech team — or even an entire company — that does not function in an optimized, empathetic, cohesive way. And situations like this are so prevalent people have stopped trying to fix them. An article published by Forbes entitled “Why Don’t More People Work As Programmers?” states:
“Programmers are often treated like factory workers. People with no programming talent (and less business sense) are often in charge of projects. They think programmers are cogs in the machines.”
Anyone who has worked on a tech team for even a small amount of time understands this all too well. Though developers are at the absolute core of product development and software creation, they are among the most misunderstood of corporate employees, simply because their jobs are so complex that those outside of engineering struggle to obtain even a basic grasp of what programmers do and how hard it is to do it. The end result is, unfortunately, the same frustrating scenarios repeated again and again.
Let’s review some of these situations and attempt to dissect them.
Scenario #1: “Don’t give me excuses, give me results!”
An exec or manager calls an impromptu meeting and presents a dilemma: Due to unforeseen circumstances, a new feature must be built out.
Regardless of what’s already on the roadmap.
In a much shorter period of time than it would realistically take.
Without any extra resources.
No excuses.
The engineer sits with their team on the opposite end of the table, gathering as much information as possible to get started, while internally screaming with rage: Why did no one know about this sooner? Why are we being punished for a lack of communication and planning from outside departments? How can we possibly be expected to get this done?
The exec is feeling panicked. The engineer is feeling misunderstood and disrespected. But at the end of the day, work must get done. So the engineer digs in, works extra hours, and releases the requested feature. And a few months later — like any other toxic and unhealthy relationship — the scenario repeats itself.
Scenario #2: “It’s your problem now.”
Regardless of where a company falls on the spectrum of product development methodologies, the habit of throwing work over the fence seems to prevail. Developers are given half-scoped features, no mock-ups or requirements documents, or worse — they are given a high-level idea of a feature in a meeting and are asked to begin building immediately.
So the engineer tries their hardest — making a slew of assumptions about expected behavior and UI, taking a lot of time to try to fit the vague puzzle pieces together, and produces a feature that they themselves don’t even fully understand. The buck then gets passed to QA, who has no user stories or requirements to base test cases from, and must make the same assumptions engineering made when building the feature. The result is a jumbled, fumbled feature that is nothing Product envisioned, nothing Marketing can stand behind, and nothing Sales can sell.
How did the train cars get so far off the track? Because somewhere along the line work was not complete before continuing down the assembly line. The PM is pressured to deliver. The engineer is confused and frustrated. So, a half-conceptualized feature goes out to users, and the cycle begins again with another uncooked idea chucked over the fence.
Scenario #3: “Shoot the messenger. It sends a message.”
Tech teams are growing bigger and bigger as the software development field booms and new technology start-ups are popping up every day. As teams expand, the necessity for middle-management roles becomes a sensible requirement. Engineering tech leads manage programmers working on similar projects or services, and they become the ambassadors for their teams. Unfortunately with this great power does not always come great responsibility, and many times the lead is not actually allowed to make executive decisions for those they manage. Instead, they are given orders from higher up the food chain — be it regarding new security policies, a change in tools or process, or an upheaval in their current roadmap — and they’ve got to simply pass those instructions on to their subordinates.
Team members receive these directives defensively — feeling as though they’re being worked at instead of worked with. And because they don’t have the footing to push back against the Powers That Be, they lash out at their manager: Why weren’t we part of the decision-making process here? Does our experience in this field mean nothing? The engineers feel micromanaged. The manager feels trapped in a situation where they have no influence on product or process decisions. Ultimately all parties involved become bitter and resentful toward each other.
Lack of Empathy — The Root Problem
All of these frustrating scenarios — though very different from each other — all have something in common at their core: a giant, glaring lack of empathy from all sides. Collaborating on product delivery requires empathy for all stakeholders involved. This means everyone from the CEO down to the junior developer should feel heard, understood, and respected.
In an article for Inc., Mayra Jimenez writes:
“…part of being a leader is understanding that in order to succeed, you need to build a team comprised of vastly different individuals. From the artistic/creative minds to the uber-technical, an e-commerce company runs the gamut when it comes to employee personalities, and the types of minds that make them tick. Challenge yourself to find new ways to problem-solve.”
So what’s the solution?
In order to avoid the situations mentioned previously — and many, many more that are prevalent across tech teams — managers and leaders need to stop trying to slap a bandaid over the symptoms and get to the cause of the bleeding. The idea of cultivating empathy among team members may sound sweet and silly, but ultimately every engineer is a human being. And building an understanding and appreciation for that humanity should be at the forefront of product development.
Now, if you are an engineer or work closely with them, you know that offering vague advice without clear instructions or actionable steps is as useful to them as a fellow employee selling vaporware to a customer; it feels useless and impractical. So how can we take this fluffy idea of cultivating empathy and actually measure progress toward it?
Step 1: Educate
In any kind of tech-related field, continuous education is par for the course. There’s always something new to learn — be it a change in programming conventions, a useful tool, or a new language altogether. Programmers have to be very good at teaching themselves new tricks and keeping their skills sharp. That said, there is often a lack of emphasis on educating others, or educating themselves about what other people do. What does a typical day in Sales look like? How does the Support team troubleshoot issues with customers? What are the quarterly goals for Marketing? What tools are they using to track success?
These may seem unimportant on the surface, but gaining a better understanding of how other teams operate will not only allow engineers to see a more high-level, holistic picture of how their company functions, it will also coax them to step into the shoes of someone else and see things from their perspective. Animosity and frustration with other teams may cool after watching an overworked Support team member struggle with a difficult customer, or talking with a Marketing team member who is struggling with how to best advertise a new feature to potential customers.
On the other side of the Educate coin, it’s important that developers teach others about what it is they do. There’s no need to get into the nitty-gritty ins and outs of how to write a good helper method or the importance of unit testing, but speaking with those outside of engineering about high-level programming concepts can go a long way. Hold a lunch-and-learn about the company’s product development lifecycle; train others on bug reporting conventions and procedures; teach Support how to use basic developer tools to diagnose a problem. The more those in non-technical roles understand how programming works fundamentally, the more they’ll appreciate and empathize with the work engineers do.
Step 2: Define
Many of the issues mentioned previously — and especially the throwing-work-over-the-fence problem — are caused by roles not being clearly defined across teams. When department expectations are fuzzy and ambiguous, it’s easy for someone to drop the ball without even realizing it. In order to ensure everyone is doing their job, they’ve got to know precisely what their job is. What documentation and requirements are needed from Product before a new feature starts being built? What user stories will QA need before they can begin testing? At what point in the conception of a new product change should each team member be involved? Being as detailed and specific as possible when forming these definitions will not only make clear to all stakeholders what their responsibilities are, but it will empower them to push back when commitments from other teams aren’t being fulfilled. Everyone is held equally accountable, and no one is left attempting to catch (and frequently fumbling with) what is chucked over the fence at them.
Step 3: Compromise
This is likely the most difficult step toward cultivating empathy, for the very reason why as children we threw ourselves on the ground and sobbed when we were told we couldn’t do what we wanted: Everyone wants to get their way. All the time. You can see it every day by peeking into a conference room where important decisions are being made — people sit gruffly across tables from each other, arms folded, firmly planted in their ideas and refusing to see anyone else’s point of view. One employee needs something done by a certain deadline. Another explains again and again why it’s not realistically feasible. Back and forth they go, like a tennis match, until ultimately there is a loser and a winner. One party gets their way, the other stomps back to their desk with their proverbial tail between their legs. This is no way to build a product, no way to run a company, and no way to place focus on humanity.
Instead of this daily dog fight, take the time (and patience!) to find common ground, and build from there. What is a solution both parties can agree on that would satisfy all stakeholders? Can all involved give a little more, take a little less, and reach a satisfactory compromise? When an agreed-upon solution is cultivated, empathy comes along with it. Everyone involved feels understood and respected, instead of tromped over.
We’re All In This Together
Working in tech can be incredibly rewarding, but also tricky. Stereotypes about “geeky, socially-awkward programmers” still prevail in our culture, and it can cause a lot of unnecessary communication issues and frustration across teams. By working to cultivate empathy for all stakeholders responsible for product delivery, engineers can feel acknowledged and appreciated for the hard work they do, and the work that is done outside the tech team bubble. And maybe they’ll be able to do what they really love — focus, swim around in code, and keep their headphones on.
