Fantasy characters face each other in terrible combat. Just how typical stakeholders on a project fight about how best to build their software product. Credit: Me.
Turning product managers and engineers from frustrating foes into advocating allies
DESIGNERS! TO ARMS!!!
Each and every one of our UX compatriots on every software production team is in conflict. We’re being hit from all sides. Factions of men and women are fighting tooth and nail to destroy us designers, to come out on top and rule over our software products with an iron fist.
There are three factions bent on each other’s destruction: Product management, engineering, and design.
Let us beat our pens into swords and our keyboards into spears. PM is overstepping their bounds, dictating our designs. Engineering roadblocks our features and cuts down our flows to the slimmest of MVPs. We’re combating fools and nincompoops; all of them are our enemies to be crushed, defeated, and trampled.
At least, that’s the story we often tell ourselves. But what if we started telling ourselves a different story?
The real story
Let me ask you something, how do we stop conflict?
We do it the same way African American jazz musician, Daryl Davis, gets members of the KKK to hand him their white cloaks — we get to know our enemy. We learn to love our enemy. And we make them our allies.
Jazz musician Daryl Davis. Photo: NPR
Fortunately, we have it way easier than Daryl does. Instead of overcoming years of cultural, familial, and institutional racism with the spirit of God and a blues saxophone; we need to realize that the people we work with are on our side. They just need a little help to become better partners (we may need it too).
Everyone wants something a little different.
It’s what makes working with people so difficult. Even when you’re working with your friends. At the end of the Hobbit, Smaug, the horrible dragon who’s been plaguing the locals and keeping the dwarves from their ancestral home has been defeated. His vast treasure was completely unguarded. And, as is typical when valuable loot is on the table, three armies made up of men, dwarves, and elves have gathered together to get what’s theirs.
Each army wanted something a little different. And none of them looked at the needs of the others. The dwarves wanted their treasure and old home in the mountains. The men wanted compensation for slaying the dragon after it destroyed their lake house. And the elves were just being jerks.
But before they began duking it out. They’re forced to tell themselves a different story. One that unites them.
A forth army, made up of goblins and riding their emotional support dogs, appeared. It required all the other armies to band together, aligning themselves to bring about the destruction of evil.
I would rather not be over run by an evil horde before I start telling myself a story of unification. Nick Craig discusses this idea in his book, Leading from Purpose (by the way, any links used in this post may be affiliate links, to help support my work). By reminding our partners of our shared purpose, we can start to unite. Because the truth is, as product managers, designers, and engineers, we all work at the same company. We’re all on the same team. And there are some really big problems out there that we need to solve…together.
Get to know your enemy (future ally)
Even if we decided to tell ourselves a story of unification, conflict will still arise. It happens every time two or more people are in a room together. Conflict is very common, particularly at work. The Center for Management & Organization Effectiveness found that 85% of individual contributors and leaders experienced some amount of conflict at work. Half of the people surveyed say it’s clashes between personalities. A third said that it’s from poor leadership.
If we want to build great products, we designers will have to use our design thinking and empathy to lead. And, in my work, I’ve found that the best first step to resolving conflict and creating alignment is by understanding what everyone your working with wants.
Luckily for us, there’s a mental framework that we can use:
An infographic displaying three circles: product management, engineering, and design. Each circle has it’s representative, advocating for their particular part of building a great software product. Credit: Me.
Product management is advocating for the business.
Engineering is advocating for technical feasibility.
Design is advocating for the user.
If we want to build successful products, we’re going to need to work together. Each member of this triad will have to advocate for their specific area of ownership while also making compromises.
A product manager represented by a human battlemaster. She has a rapier, cloak, and thigh high boots. Credit: Me.
Product Managers
A product manager needs to make a software product that sells. If they don’t do that, they lose (we all do). There are a variety of functions and tools that they use: capturing customers’ needs, monitoring the market, defining the product vision, and prioritizing potential features. They’re working to cast a vision and influence project stakeholders to create a successful business strategy for thee product.
An engineer represented by a dwarf artificer. He’s got glasses, a blacksmithing hammer, and dirty boots. Credit: Me.
Engineering
An engineer needs to build something that works in a technologically feasible way. They take the PM’s business strategy and the product designs from yours truly to build something interactive. They are making ideas real, implementing appropriate testing, and maintaining the things that they build. They’re focused on building software in a scalable and efficient way.
A designer represented by a half-elf wizard. He has a staff, pointy hat, potions, and a sachel bag. Credit: Me.
Design
It’s our job as designers to make a software product that is user-friendly, intuitive, and addresses customers’ pain points. We are facilitating user research, building interaction designs, creating high fidelity visual designs, all while understanding the implications of good accessibility. We’re designing things that make our users feel heard, understood, and supported.
Love your enemy (future ally)
We are all going to lose if we’re not working together to address user’s needs, build things well, and sell our work. But oftentimes there is an issue with parties not understanding what the other’s roles are, and how to speak their language. Leading well requires listening well. And being able to listen requires that you understand the language of the people you’re talking to.
When I ask myself, “what does this person want? What do they need?” It fundamentally changes and guides my interactions and responses.
Let’s stop talking about work for a second. Are you familiar with the Five Love Languages? It’s an old book that reduces down expressions of love into five actions: words of affirmation, quality time, gifts, acts of service, and physical touch. Let’s say my wife and I have conflict and she tells me that I’m not loving her well. If I know that my wife’s love language is words of affirmation, then I know that doing the dishes isn’t going to help her feel anymore loved. I probably should change the way that I speak to her by affirming her with my language.
When I know my partners wants and needs, I’m better able to listen and understand her.
This is true for the people we work with. As designers, we can strive to understand what our collaborators need, which allows us to better understand them.
Product Management’s love language
PMs want to build a product that sells. If we want our product managers to hear what we’re saying (and feel like we have their backs), then we need to speak the language of business, timelines, and deliverables. When we get pushback from them, we need to be able to defend our work, not with the language of design, but with one of business. How does our work impact the bottom line? How are our designs cheaper? How are we avoiding future issues? How are we solving the real pain points of our customers?
Engineering’s love language
Engineers want to build things. They speak the language of construction, and technical implementation. If we, as designers, take time to learn how things are built (I’d suggest breaking out a free course on CodeAcademy), we can begin speaking that language.
The best way to avoid engineering slicing our work to pieces is by bringing them in early. If we can work collaboratively with our engineering partners, speaking their language, and understand the technical limitation of our designers, we’ll be able to produce something awesome that’s also technically feasible.
Make them your enemy (future ally)
Understanding our collaborators needs and speaking their language gives us the ability to solve our collaborator’s problems. And by doing that, we increase our influence. One of the six principles in Robert Cialdini’s book, Influence, is reciprocity. By solving other people’s problems, we’re encouraging them to want to solve ours.
Here’s a really useful tool that we can use (I’ve found this to work both in work and marriage):
Listen
Pay attention to the speaker without interrupting. Focus on understanding their message, feelings, and perspective. Think about what they’re hoping to accomplish. Show empathy by acknowledging their emotions and validating their experience.
Reflect
Paraphrase back what you’ve heard them say in your own words. This helps them understand that you were listening and actively engaged in the conversation. Ask any clarifying questions you might have if you don’t have full understanding.
Respond
After listening and paraphrasing the speaker’s message, respond thoughtfully. It might be agreeing, offering your perspective, or suggesting an alternative solution. This is where you should advocate for your position, but do so without blaming or criticizing.
An example: Your product manager, Sara, says that we can’t hold back designs for further user research because we’re operating on an extremely tight deadline and need to have this feature out by the end of the quarter. However, you feel like there needs to be more research done to validate a new design pattern you’re implementing.
Here’s how I might respond: “Hey Sara, I hear that you are concerned about delivering this product on time. That totally makes sense. But I also know that you want to deliver a successful feature that our users will love. This is a brand new design pattern, and I’m concerned that any time we gain by moving quickly will be lost by the poor user experience and bug fixes after it’s released. Is there any way we could take two additional weeks to do proper user testing before moving into implementation?”
But understanding Sara’s need (and her ultimate goal of delivering a successful feature users will love), you’re able to redirect her towards a better path. It may not turn out exactly as you want it to. You may need to make compromises. But Sara will know that you understand what she needs, and will want to reciprocate when you start asking for things.
Conclusion
Building great software products is all about leading, influencing, and working well with people. It’s a relationship problem. Let’s figure out how we can advocate for our work, understand each other’s needs, and collaborate to build a way forward together.
Resources
How One Man Convinced 200 Ku Klux Klan Members to Give Up Their Robes — NPR. Please take 10 minutes to listen to this interview. I heard it years ago, and I still think about it. Daryl is an incredible human being and peacemaker.
How to make people feel heard — Clip from Simon Sinek
The Five Love Languages — Book by Gary Chapman
Product Manager: The role and best practices for beginners — Sherif Mansour, Atlassian
What is a Software Engineer? — Aha!
UX in Software Development — Brainhub
Influence: The Psychology of Persuasion — Book by Robert Cialdini
Affiliate Disclosure: Any Amazon links are affiliate links and help support my writing and drawing.
Hey y’all! I’m Trip Carroll, a design leader at Cisco and aspiring cartoonist.
I write and publish a new article on design, leadership, and software development every other Monday. You can see more of my work on my website, check out my drawings on Instagram, or subscribe to my newsletter on Substack.
Let’s make work great!
The software development war was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
