Conflict is a part of all human connections, and business relations—more specifically in startups—are no different. If we want our startup venture to have the best shot at success, we need to be prepared to not only deal with conflict, but prevent it altogether. And with the tools I have for you today, you’ll be able to do just that.
As a startup founder, you have to deal with all sorts of people. Dealing with providers sometimes proves to be specifically challenging, since there is so much expectation involved from both ends of the relationship. As a startup founder, you have to communicate your idea to the provider, in hopes that it will be completed as you imagine.
The thing is, developing something innovative is hard. It means you have to bring something abstract into reality. The provider knows that and takes it into consideration when setting a price, e.g. charging you $12,000 instead of the $10,000 he calculated. That’s risk management. The extra money covers any anticipated conflict with the client and the extra tasks to be developed along the way.
However, conflict still arises, and by identifying what causes startup founder-provider conflicts, we can understand the rules to prevent them.
Problems with the source code?
I have heard the whole, “My provider bailed mid-project and I don’t have anything to show for it,” ordeal too many times. There is a reason for this: providers tend to invest too much in the product. And by staying on board, they risk losing ownership. However, the founder needs to have access to the source code, in case the provider bails. This creates a very tense atmosphere and ultimately leads to success-threatening conflict. So, what should you do?
Prevention rule #1: “Make sure you get the source code from day one.”
Also schedule regular meetings where you check that the product being developed fits your requirements and needs. This will keep your provider on-track, keep you informed of what you’re paying for, and avoid time- and money-wasting misunderstandings along the way. Which brings me to conflict source number two:
And ultimately driving your provider to the breaking point. Let me paint you a picture:
At the beginning of the project your provider estimated 100 days of work, but for every task considered, 5 extra sub-tasks popped up that weren’t accounted for in the initial proposal. So, your provider complies and complies, 100 days turned into 140 days, you don’t have the deliverables on time, your provider is working crazy hours, and he even ends up losing money.
Sound familiar? A lot of startups have struggled with this, and it can in fact be prevented.
Prevention rule #2: “Define deadlines and milestones for better time management.”
Be as specific as possible, and allow time for hiccups along the way. If you want more specific help with this, I actually have an entire course about it here. Overall, having a clear path will help determine how long things will actually take, and make the whole thing easier and less stressful for both parties.
Things are still getting tense, what do I do?
Okay, so maybe you read this blog post too late and didn’t follow our prevention rules. Or maybe, for one reason or another, you still got yourself into a pickle. Not to worry, there are three principles you can both follow to improve this situation and come out better on the other side.
Problems arise when either one, or both, hold something in. Both you, as a startup founder, and your provider should share honestly and with empathy problems and shortcomings on both sides, that means no lies, cover-ups or excuses. It is the provider’s responsibility to let you know the moment time starts being wasted. If they they are stuck in a feature or can’t make the deadline, you should know right away.
For example, if the job hasn’t been finished by the scheduled time, it’s either one of two things: it turned out to be more work or more complex than anticipated. In both cases, both parties need to know what’s going on in order to fix it. It can be even more frustrating not having the results you both expected without knowing why.
You have a startup venture to get off the ground, with investors, accelerators, partners and users, all counting on you succeeding. Your provider might have employees, family, rent, taxes, personal projects, and other clients to take care of. You should both be aware of how your actions affect the other party.
This might mean, as a startup founder, being open to investing a bit more, if a big task comes up that wasn’t accounted for in the beginning. In turn, your provider should also understand the negative effects he might have on your startup when certain conditions aren’t met, and strive to minimize them.
After communicating your issues and understanding the positions you are both in, focus on what’s left to be done. If you’re somehow stuck, look for solutions outside the box, like bringing someone else to the table who has previous experience in the area you are stuck in.
If we go back to our previous example: your provider hasn’t delivered on time, and he communicates to you that he has been struggling with an AI feature which turned out to be more complex than expected. It’s not only the provider’s responsibility to tell you this. In this particular case, talking to an AI expert for a couple hours might save days of development.
Things still exploded in my face, how do I fix this?
First, I will ask you to recur to Prevention Rule #1: “Make sure you get the source code from day one.”
This is the best strategy to deal with the consequences of a conflict once it erupts badly, and your provider leaves you stranded. Legally speaking, the source code belongs to the provider until you pay him/her. Asking access to it during a conflict is the only way for the situation to move forward.
This will allow the startup to move on with the produced code with another expert and complete the final part on its own, and just pay the provider for the initial work. The negotiation will then be just on the cost of the extra development required to finish the product.
When a provider locks the source code until they get paid is usually where things go bad. You then need to quickly make a decision and consider redeveloping the product or even creating a new version with another developer, then impose penalties (for business lost) on the old provider for not providing the deliverables on time.
Another option is to ask an expert to evaluate the value of the source code, which will also help determine the cost of payment to the provider.
Speaking of experts, if now the conflict you have is with your CTO, you might want to take a look at the post, Your CTO is leaving, what should you do?, where you’ll learn how to deal with the transition and keep your startup striving during and after it.
If you have any comments, questions or anecdotes, feel free to post them here. And if you found this article useful, make sure you share it with friends or colleagues. Until next time.