You’re about to learn a skill you’ll use in every tough discussion with stakeholders, teammates, or anyone blocking your progress.

And the best part, it’s very simple.

As developers, we are not just writing code. Big part of our job is the communicating
with your peers, business analyst, product managers, stakeholders.
And whether we like it or not, people judge us by how we communicate, not just the work we deliver.

Most of us don’t want to come across as demanding or difficult. We want to be seen as someone who can be trusted, someone who helps move things forward, someone who genuinely cares about the outcome.

But when you’re frustrated, especially by something repetitive or unclear, keeping that mindset is tough. And things only change when you talk about them.

Which is why preparing for those conversations is so important.

One question that helps me a lot is:
“What would be the best outcome for everyone?”

I like to write the ideal outcome down before the meeting. Something simple like:
“I would like to explain what is bothering me about X. And I want to understand why they are doing it this way. Maybe there’s a better way?”.

This way you have a specific goal to achieve, and you’re more willing to listen to others because you set your mindset to it.

This isn’t random advice. This is something I had to learn myself.

Recently, I was getting tasks from stakeholders that looked different on the surface, but when I zoomed out, they were basically the same thing. And after seeing this pattern repeat again and again, it became frustrating.

I mentioned it casually to my manager, and he offered to set up a meeting.
At first, I didn’t feel like talking about it. It felt like “just another annoying thing developers are supposed to swallow.”
But then I realised this was a real chance to improve our process.

So before the meeting, I set my intention:
Find a positive outcome, find a win-win.

And that’s exactly what happened.

We had a great discussion and discovered the frustration existed on both sides. I proposed a few solutions, everyone agreed on them, and once they’re implemented, the main source of frustration will disappear. The service will improve.

A genuine win-win.

Strong communication is part of the debugging mindset too, it helps you remove friction just like you remove bugs.

And that’s why I’m learning to communicate better too. A great book for this is Supercommunicators by Charles Duhigg.