In design, we often call out empathy as one of the core skills a designer needs to have in order to deeply understand their customers and hands on users.

To develop empathy, we spend hours with our customers in their environments to understand the pressures they’re under, the pain points they face, and the solutions we can bring to help them be more productive.

While empathy is our secret sauce, we seem to ignore practicing it as much with our cross-functional partners in our work environments.

Think of the last time you sent an email, scheduled a meeting, or discussed timelines and technical constraints with your direct team or cross-functional partners. Have you truly thought of your cross-functional partners the same way you think of your customers? Did you ask the same type of questions user research teaches us? Did you try to understand the underlying issues of why an engineer is heavily pushing back on your design or why a product manager believes your design won’t meet market needs?

One of the best tips I use as I work with hundreds of engineers, product managers, and other cross-functional partners is to always assume everyone is here with the right intentions, they just need the context to move forward.

In other words, nobody is pushing back because they don’t want to deliver the right solutions to customers. Nobody is there to simply make your life more difficult. They’re here, just like you, to solve customer problems within the constraints of resourcing, underlying engineering systems, and timelines.

I do understand there are some exceptions in some cases. However, until I’m proven otherwise, everyone is there with the right intentions to deliver the best experience possible to customers. It’s my role as a designer and as a leader to give them the tools to succeed, to understand their constraints, and to provide them with the context needed to move forward.

Empathy doesn’t automatically happen. Empathy requires spending hours with your partners to understand the environment they’re operating within. It requires understanding the systems they use and what types of constraints these systems might impose. It also requires understanding the pain points they face. Empathy also requires looking at their point of view from their perspective

Acknowledging these constraints is enough to open a channel of communication. For example, the next time an engineer pushes back on your design, try to deeply understand why. Is it simply because they believe this design is not good enough or is it because they’re under pressure to deliver, just like you, and would like a more detailed experience?

Acknowledging that you understand these constraints and will work with them or help them fight it is enough to make you a partner instead of a dependency.

Even though I continue to fail at this sometimes, I try my best to use empathy as I write my emails, present my work, or provide criticism.

Don’t reserve empathy for your customers. Use it to build trust with your partners and team.