note: We originally posed his question to our community via email as part of our Dispatches series of content. The response was amazing, thoughtful and smart, so we decided to update this post with a few select replies. Read on!
The middlebrow answer to this question is, “Most of the time, but not when they’re difficult.”
Internally, this is a question we’ve wrestled with repeatedly. Since we enable a freelance workforce, each one of our freelance teams has a slightly different temperament and communication style. We try our best to match these styles with the client project on which they’re working.
There are trade-offs
The upside is the flexibility to meet the client where they in terms of work culture, communication style, or business stage. The downside? We have no consistent or canonical answer to the question of who should yield and who should push when there is a disagreement between client and consultant on a technical decision.
Admittedly, I struggle sometimes to find the right answer.
As a manager, my instinct is to side with clients. I’m quick (perhaps too quick, if you ask my colleagues) to challenge the opinions of our freelancers because I believe that human beings will default to pursuing the easier path if two are available. For the same reason that a coach is important to force one to get the last few reps in the gym, I believe that most managers’ initial reaction to, “This client is difficult,” is, “Deal with it.” You can blame my parenting.
On the other hand, I can credit the growth of our business to simply listening to what freelancers want. One prospective client even said to us, “I chose you guys because this is where I would want to find contract gigs if I were a freelancer.” Too many technology staffing agencies take a commodity view on labor and don’t allow for compromises in their process, their methodology, their way of doing business to accommodate the needs and desires of their professional network.
It’s a tricky question, but we have found a way to improve incrementally over time.
The Decision Log Approach
I stole the following from Ray Dalio: I keep a decision log of most decisions I make in a simple Evernote document. I don’t get overly specific, I simply record:
The decision (this, that, or the other thing)
The data I used (usually experiential, sometimes quantitative)
The expected outcome
And later, whether I was wrong or right. If I was wrong, I write down why I think I was wrong.
The challenge is in the analysis.
The difficulty in porting this (admittedly slightly creepy) model of dispute resolution to client and freelancer relationships is two-fold: most importantly, the market that the client’s product is in determines what’s right and what’s wrong from a product and software standpoint — we don’t. Secondly, product development is messy, so by the time the expected outcome occurs (or doesn’t), it’s impossible to evaluate a single decision as the root cause of success or failure.
However, once a client has gone through a few product release cycles, we start to see very high renewal and satisfaction rates (91%~ across the portfolio).
I suspect our teams have reached the right equilibrium of “when to push and when to yield” intuitively for that specific client because domain knowledge between clients and freelancers shards into specific areas of expertise.
So, per usual, there's some gray area
Long-term relationships aren’t perfect indicators of an optimal answer to this question, but they’re pretty damn close to suggesting that once people find their roles, the project is set up for success and people know when to argue and when to yield. As a client or consultant, how do you solve this question? How do you know when to push against your consultant or your client, and how do you know when to yield?
Responses from the Gun.io Community
From Mr. Danny Graham, Senior DevOps Consultant
When is the "customer" (client) right? Always!
"No shoes, no shirt, no service."
"We reserve the right to refuse service to anyone."
"Theft will be prosecuted to the full extent of the law."
Customers that are abusive, inappropriate and/or disruptive to workers, business continuity or other customers should be removed quickly, calmly and quietly. It is unacceptable for a customer to refuse payment for services rendered, whether or not they dispute the quality of service or even that service was actually rendered. It is a form of theft and, as a matter of law, is viewed as a preventative or punitive effect that would preclude the worker from defending their right to be paid. California, for example, has very specific laws stating that if there is a dispute in payment, payment must be made — and then the dispute can be made to get a refund.
When it comes to _how_ a job is to be done, the quality of deliverable, the process and procedure - unless a customer is asking for something illegal or unethical, it is their money and their decision. It is outside of a worker's scope of practice to refuse to follow the customer's decisions and direction — even if the worker feels certain that is a bad course of action. When a worker is concerned about customer decision making: document, document, document, document - oh and document some more; leave a trail for other workers, supervisors, management and the customer to follow that show the decision to be made, the options available, recommended solutions, trade-offs, benefits, costs, consequences, side-effects, stakeholders and the ultimate course of action.
Ultimately, the client is right — even when they're wrong.
At Animal Ventures, I find two methods that help determine who is right throughout the rush of product development.
My first point is that I believe disagreements are actually desirable. Disagreements between clients and customers are inevitable in almost any industry. This is especially true in professional services and doubly so with the complex service of building software.
Now to address the primary question you posed, when is the client right? The answer is quite simple actually: who turns out to be right is less important than the process used to determine correctness. In concept, having 2 opposing viewpoints making vociferous arguments to a neutral adjudicator results in fair, even-handed decision. This is because each side has the opportunity to present their best case and support their opinions using all available data. The judge arbitrates by weighing the strength of each argument in light of the rights of defendant and society at large.
I've found myself in both positions (litigant and judge) in the world of technology. As a litigant, I'd make the case for a particular vendor or framework by using logic arguments combined with my knowledge of technology and business. As a judge, I'd weigh choices in light of what really matters (e.g. execution, performance, stability, security, profit, etc) It is important to note that "what matters" differs from one client to the next and even from one project to another with the same client. The point being that, assuming the process was sound and the decision was fair, we had a high degree of confidence that we made the right choice.
I've found this type of approach in practice at all my best clients and on all my most enjoyable projects. I recommend the approach to any customer with sufficiently complex and important deliverables.
From Ms. Sunita Guyadeen, Agile Delivery Lead
I think a client or anyone really is “right” when there is a conflict or disagreement when the decision that is made is an “informed” decision. So, it's not really about who is “right” and who is “wrong” — it is about having and understanding the facts and making a choice with this information.
I believe it is management's responsibility not to side with the client or freelancer but instead create a framework that enables Team Gun.io to arm clients with the data to make an informed decision.
It is about creating a culture of non-unanimous consensus building amongst Team Gun.io which requires everyone to understand that it is okay to not agree with a decision but it is important that everyone understand the rationale for the decision.
What's your take? Hit us up sometime to chat about it - hi @ gun.io