Business Contracts

Business contracts are often executed when two companies work together. At the most basic level, a contract should describe a common understanding between the two parties. The contract should assist and aid the relationship. However, many contracts are written by lawyers with the primary goal of covering every legal loophole and taking every legal advantage possible for their clients. This often results in contracts that are very long, filled with legal jargon, benefiting only one party, and in general, a burden to process.

For a business relationship to be successful and sustainable, there has to be value for both parties and there has to be trust. If these two key ingredients are lacking, there is little motivation to continue the relationship.

We can look at business relationships as a positive-sum game, or a zero-sum game. A positive-sum game is where the relationship is structured as a win-win — both parties find good value in the relationship and are motivated to continue it. There is a belief that the “pie” of opportunity will grow through their combined efforts. The engagement is voluntary and not constrained by force or compulsion. Zero-sum thinking is where one party is always trying to gain the maximum advantage over the other party. This is the “fixed pie” mentality where we think the resources in business are fixed, and if anyone else gains something, it is my loss. This attitude is often found in purchasing departments where they are trying to obtain the lowest possible price for a good or service, net 60 payment terms, etc. I recall in one case a manager of a company exclaiming, as we went into a meeting with a vendor, “Let’s go beat ’em up!”

Business relationships are more complex than getting the lowest price or the greatest legal advantage. The people/companies you want to do business with are likely already busy. They likely have plenty of opportunities. They will seek engagements with those who play the positive-sum game. If a company plays the zero-sum game, they will end up doing business with second rate companies who don’t have any other choice. They won’t get good service, and trust in the relationship will be lacking. They will be forced to hop from one vendor or customer to other. There will be few long term relationships. As Bob Metcalfe once wrote, “First, don’t “hire” anyone. B people hire C people — they collect resumes and choose the person they want to honor with a job. A people recruit A people.” The same applies to business relationships.

With this background, let’s examine the topic of contracts a company may present to an independent contractor or consultant providing services to the company.

Again, the best developers (the ones you want) are successful and busy. They will not mess around in business relationships where people are playing the zero-sum game. They are successful because they are trustworthy and expect the same in return. They are generous with their time and knowledge because they understand the universal law that the more you give, the more comes back to you. But they also expect the same in return. They are confident in their abilities and do not take measures that lock their customers into their services, but on the contrary, make themselves “easy to fire.”

A fundamental problem with trust is that people generally don’t tell you when they don’t trust you. Actions that damage trust are likely unintentional (otherwise you would not do them), but you never get feedback on this. So, I’m giving you a hint now — an onerous contract, with one-sided indemnification clauses, damages trust. It tells the other party that “I might take advantage of you.” It implies that if bad things happen due to a product flaw, “you could be on the hook.” It sows seeds of doubt. Most often, this is likely not the thought of the company presenting the contract, and the contract language is just the result of lawyers trying to do an exceptional job of protecting their client from any possible liability. However, a contract is still a contract. If disaster strikes, the contract will be used in court by various parties trying to recoup damages. Products are often sold over a long time (5-10 years or more). Companies often change owners. Therefore, it is very important that a contract be fair and just. When a developer is presented with an onerous contract, immediately the question arises — can I trust this company? Is it worth it? Even if the project goes forward, it will be with some reserve and guard. It will not be with the wholehearted attitude that is an ingredient for success.

As we consider indemnification phrases in a contract, we need to establish who should assume liability for a product: 1) a consultant/contractor who is billing by the hour, or 2) the company selling the product over a span of many years? Risk should be proportional to reward. A hourly contract developer has no reward for a product’s success, other than the baseline costs of doing the development. The company selling the product is the one who will potentially reap the multiplying rewards of a successful product. Therefore, they should be the ones who bear the risk as well. It is not just to expect otherwise. In the situation where a developer is providing consulting or contracting services to a larger company developing a product, it is important that the contract clearly state that:

The Company assumes sole responsibility for all testing of the Work, including but not limited to software and hardware, and also assumes sole liability for any use or misuse of the Work developed by Contractor for the Company.

An argument may be made to the developer — you are not a lawsuit target because you are not a large company with deep pockets — so just sign the contract. This may be true, but what if the consultant does grow the business to the point where there are more assets? Products live a long time — a lot can change. As mentioned before, a company can change hands. If there is a lawsuit, then anything is possible.

An individual developer has limited control of the development of a complex project and the resulting product. (We are not talking about fixed-bid turnkey product design where a larger company designs the entire product, but rather hourly development services). Typically, there is extensive involvement from other developers. The contract developer does not control how the product is manufactured, marketed, sold, supported, or even how other parts of the system are developed. In complex systems there will be bugs, and often there are time to market pressures that prevent extensive testing and verification. These are all factors that are out of the developer’s control and are choices made by the product owner. Again, this further illustrates that those who are ultimately in control of a product (the owner) should be responsible for any liability the product might bring.

This brings us to a common concern of the company — they want to be sure the product is developed to professional standards. A contract phrase might be: “Contractor hereby warrants that its work shall be of professional quality and performed consistent with generally accepted industry standards” Who defines these standards? How will they be defined in court? The reality is that few developers have the time and resources to really do the job they want to do. Schedules are always pressing, forcing compromises. Ultimately the product owner makes the decisions concerning these trade-offs — not the developer. Time to market is critical. Therefore it is difficult for a developer to warrant any work will be at any particular industry standard — as the product owner is ultimately in control. The universal laws of reality apply: “Good-Fast-Cheap” — pick two — all three do not exist. In any product development effort, there are compromises.

There is a very practical way to handle the concern that a company’s product is being developed to their standards, and that is to encourage collaboration and openness between all developers on the project. Make sure all source code and design files are shared in Git repositories that are easily accessible to all developers — both employees and contractors. Encourage all developers to work on any part of the system needed to get their job done. Google does it — maybe you should, too. Discourage engineering “turf” where developers feel they “own” something in the sense that no-one else should mess with it. This is essentially the process used in Open Source Software, and successful companies have adopted these practices — the results speak for themselves. If this works in a large company, is there any excuse for not doing this in a small company? Open source projects don’t have contracts that specify all contributors have to do a good job, yet open source projects contain some of the highest quality code available. Peer review and doing your work in public (even if only within a company) is a powerful motivator. Because the development is in an open environment, it is quickly evident who is going a good job and who is not. The same dynamic can happen in a company. If there is open collaboration, frequent integration, and early testing, you will soon get a good feel if developers are efficient and are generating work that is of “professional quality.” Share weekly reports with the entire team of what each developer did and how much time they spent on the project. This will produce a level of accountability among peers that will far exceed what any manager can force. If someone is spending excessive amounts of time and not getting anything done, other developers will start to question it. And you will know of problems early in the project at a time when you can do something about it, rather than after a product has been sold in quantity and some horrible defect arises that results in lawsuits. Which is the better option? To summarize:

If a company wants to ensure quality work is being done by their developers, then they must foster a collaborative, transparent development environment where:

All development is done in the “open” in Git repositories that the entire team has access to.
Any developer can contribute to any part of the system required to do their job.
Integration is done often.
Product testing, by the owner, is started early in the development cycle.

No amount of contract legalese can come close to being as effective as the above.

Whether you intend it or not, your legal contracts are both a reflection and driver of your company culture, and its resulting success. They impact the people you will attract — both employees and contractors. Do your contracts reflect a fair and generous mindset where you are willing to take responsibility for the things you should take responsibility for? Do they turn away or create reserve in people you need the most? This is a serious issue because the best people often come through referrals. Will a developer recommend their talented and busy friends if they are required to sign uncomfortable contracts that must be negotiated to even approach an acceptable level? Any friction in this process is slowing you down. Yes, a one-sided legal contract that takes everything you can get may save you some liability in the unlikely event of a product lawsuit. But it also has the effect of introducing friction in relationships that are key to your product being completed in the first place. Which is more important? Which should have priority? In summary, a contract should:

clearly represent the concerns of both parties
document what is expected
not be one-sided
be fair
avoid complex legal jargon as much as possible
aid, not hinder the business relationship
include provisions for how the relationship will be terminated, if needed

I’ve been working as a consultant for 20 years. My most successful and longest relationships have been with companies where I have never executed a single contract. Is this a coincidence? Is it cause or effect? I don’t claim to know, but my experiences resonate with the words of Seth Godin:

A handshake deal, on the other hand, is about the future. Either side can claim loopholes or wriggle out of a commitment, but the consequence is clear—if you disappoint us, we won’t be back for more. The participant in a handshake deal is investing in the future, doing more now in exchange for the benefits that trust and delight and consistency bring going forward.
from: https://seths.blog/2014/10/handshakes-and-contracts-the-future-and-the-past/

Somehow an essay about contracts has morphed into a discourse on company culture, development practices, and ultimately success. This is the power of writing — it helps you connect concepts that you did not previously realize were connected. In the end, everything is connected. Your contracts, your company culture, the type of people you attract, etc. It all matters.

References: