How Disagreements on a Software Project Lead to Better Outcomes

“The customer is always right” is an axiom that’s traveled the globe since the 19th century and is deeply ingrained in our subconsciousness. It’s become a guiding principle in today’s ever more service-oriented world; a phrase uttered in nearly every industry at one time or another. With all that being said…

Disagreements happen.

They can happen on any project, with any team. Now, we can certainly take steps to mitigate the likelihood of disagreements such as defining the project’s business needs early on and having clear expectations for outcomes. But the simple fact is, they still happen.

That’s not necessarily a bad thing, though.

Quite to the contrary, disagreements on a project expose weaknesses and often result in a greater end result.

Disagreement Doesn’t Mean Disappointment

The word “disagreement” often carries a negative connotation. We tend to think of a heated argument. A disagreement doesn’t have to be negative though. And it certainly doesn’t need to be a cause of disappointment on either end of the conversation. Instead, disagreements lead to discussions about how to improve the project and achieve a better outcome.

Let’s take a look at an example.

A client came to us needing a mobile app. They were set on having native apps for both iOS and Android. But, they had a very limited budget which meant that the app’s feature set would also be constrained. We talked through their business needs and goals and really got to the center of what they were looking for. Their feature-set didn’t need the granular level of integration that a native app offers.

After talking through all of this, we steered them towards a hybrid approach. They were able to make their budget go further and get a slightly more robust feature set. Now, we could have certainly honored their original request and just built them two native apps. We could have done it within their budget and their feature set.

Had we done that though, we would have been doing the client a disservice. They wouldn’t have received the most bang for their buck and possibly wouldn’t have been as happy with the work that we did for them.

Another example actually happens fairly often: saying no to scope creep.

One case of this that comes to mind is when we were adding search functionality to a client’s website. The system was a relatively simple marketing website with an admin panel for publishing articles, news, events, etc. In other words, it was a marketing website plus a small social network.

The initial requirements for the search functionality were not complicated and we implemented it on time. When the client saw it though, they wanted us to make changes. Since it wasn’t a major change, we all agreed we could still meet the deadline of the MVP release. The developers managed to do it quickly, and the search was ready with all the new requirements implemented a week before the release.

But the client had a few more changes they wanted to be implemented.

Up to this point, our team had agreed on every request the client made, and this trend continued with changes not only in the search but also in other functionalities. Five days before the release, the client was still asking for updates to the design and wanted us to add a voice command option to the search.

We’d reached a point where we could no longer make the requested changes and hit the deadline. While a flat-out “no” wasn’t realistic, our team spoke up and explained that we didn’t consider all these changes essential during the MVP phase. After we explained our point of view, the client agreed. We pushed back the secondary features and released a working and successful product on time.

So, what was the result of our disagreement? The client was pleased and became a lot more conscious when requesting new features, which eventually led to multiple new releases after MVP. In the end, they had a product that they were very satisfied with.

In both of these examples, our team had the client’s best interest in mind and the disagreement resulted in a better outcome for the project. This is something that we take a lot of pride in as it really sets us apart from many other offshore software development teams. We often hear from clients that other offshore teams they’ve worked with did everything exactly as it was asked of them without questioning it — even though it was wrong and resulted in an unusable piece of software.

The Subtle Art of Effectively Disagreeing

It’s not an exaggeration to say that disagreeing with a client or team member is an art form. There’s a particular nuance to disagreeing in a way that makes the other party understand how their wishes and requirements could potentially harm the project.

With that in mind, here are some steps we take to ensure that we are expressing our concerns and disagreements in the most effective way possible.

Show Respect and Give Credit

Subconsciously, disagreeing with someone is synonymous with showing disrespect to one’s views and desires. But that’s not necessarily the case. In a business environment, if our opinion doesn’t correspond with someone, it by no means indicates that the other party doesn’t know what they’re talking about.

When voicing concerns, we start by acknowledging the good points from the opposing perspective. A strong argument against a certain standpoint should be based on a perfect understanding of the other’s ideas.

In other words, we must give credit to the positive elements in someone’s idea before disagreeing with other points. A humble, yet firm, presentation helps make ourselves heard without sounding accusatory and aggressive. Thus, we’ll stand a good chance of persuading them that it’s beneficial for them to change course.

Don’t Judge, Use Facts

For disagreements to lead to a consensus, the discussion must be based on reasoned arguments. Facts supporting our opinion are much more valuable than judgments of the other’s view. Reasoning and hard facts not only help cool the conversation down but place greater emphasis on the merits of our position.
It’s important to show that our disagreement is not a personal attack but a neutral invite for collaboration and in doing so, we must be mindful of the language we’re using. Adjectives are really not welcome in such conversations as they carry an emotional connotation and often an air of subjectivity.

Zoom Out

Let’s imagine a software development project that has been going for months. We’ve had numerous meetings with the client so far and both sides are deeply engaged in the whole process. At some point, however, we see that the direction we’re going is not quite right, and we must express our concern. But instead of starting off by disagreeing with, for example, a certain functionality the client requires, we should step back and put this functionality into perspective.

Simply put: bringing up petty issues doesn’t add anything to the conversation. Instead, we point at a higher purpose that the client can achieve if they change the course of action. They’ll be more interested in taking part in a larger-scale discussion that touches upon important aspects of their business and overall performance in the future.

Establishing Trust and Communication

Human nature is structured in such a way that we naturally try to stay away from friction. In a typical business environment where a client has hired a team to do certain work, there often tends to be an unspoken hierarchy. This hierarchy can negatively impact collaboration if there isn’t a sense of trust and open communication established.

In our collaboration approach, we strive to achieve that trust and communication right away so that any disagreements between client and team members aren’t seen as negative or disrespectful. The client ultimately makes the final decision but by providing an alternative perspective, we’re ensuring that all ideas and approaches are at least considered.

Final Thoughts

Disagreement is unavoidable in any professional setting, but we shouldn’t see it as an elephant in the room. When conveyed in a respectful way, it introduces new angles and approaches to the work process which ultimately leads to a better end product. But remember, respectfully disagreeing with a client or team member takes a specific nuance and is a skill that must be honed.

Image Source: Christina @ wocintechchat.com on Unsplash