Note: This is my experience consulting with a number of startups over the last 4-5 years. I’ve seen certain trends. I’ve talked with other developers and they have seen similar. This is a combination of the problems I have seen. It is not a complaining about these people, just a reality check that you need to have.
In a recent article, I discussed the general concept of risk and the startup process. This is great information if you are pushing your startup idea forward. We’re not all pushing OUR idea forward. Sometimes, we’ve been asked to join someone else’s startup, attend a startup weekend, or help someone else’s startup that has had some problems. The end result is that we are pushing someone else’s idea forward. Unfortunately, these people may have different expectations to you, and from development reality. In this article, I’ll walk through a few issues that I have seen. This is taken from my experiences in the southeastern US in several locations.
You must be able to manage the expectations of everyone in the startup. You will need to be comfortable in this scenario. Managing expectations is hard, some might say it is impossible. It is also incredibly hard mentally as well as financially. It is hard mentally when you are getting questions on a feature every day. It is hard to say it is weeks, or months away. It becomes especially hard when someone else says that they can produce a feature in some small amount of time. Many people will be willing to try this in thinking that in the short term, it will all work out. Many times it does not work out at all, but that is a much later argument. This becomes a financial issue when the question of you vs. someone else comes up and how any money flows.
The bottom line is that you need to manage the expectations of the others on the team. What happens when the other people won’t accept what you are telling them? That is when you have some amount of conflict. The solution to the issue depends on what the conflict is. Conflict over scheduling can be solved by having a priority list of features. If someone wants something to be done sooner, then the order of the priorities can be changed. That is a simple solution that tends to work out. People understand priorities and can stick with this.
Another issue is that people will not believe you. My favorite one of these was “You should have built this with a web app so that we could not have to deal with paying 30% to the app store.” Another great line that I have heard is something along the line of “My friend’s cousin’s son can do that in a basement in their sleep.” There is very little that can be done in this scenario. No matter the facts, sometimes people will not believe you. Keep an open mind on these issues. They could be correct, however, the possibilities in these scenarios is pretty small.
Another idea that comes up is that more developers will solve a problem quicker. Much like threading, or multiple cpus in a computer, reality is different. Management between multiple threads or multiple CPUs requires time, effort, and cycles. The same is true with multiple developers. The secret I have found is that everyone needs to be in the same location and they need to communicate when there is an issue. This will solve the issue of communication that doesn’t work in a phone call, email, or IM.
In neither of these situations were these necessarily bad people. They had not been successful initially. In their mind, they were trying something different. Unfortunately, they were transferring all of the risk from themselves to the developer. Be careful.
Look for Part 2 of the article shortly.
In a recent article, I discussed the general concept of risk and the startup process. This is great information if you are pushing your startup idea forward. We’re not all pushing OUR idea forward. Sometimes, we’ve been asked to join someone else’s startup, attend a startup weekend, or help someone else’s startup that has had some problems. The end result is that we are pushing someone else’s idea forward. Unfortunately, these people may have different expectations to you, and from development reality. In this article, I’ll walk through a few issues that I have seen. This is taken from my experiences in the southeastern US in several locations.
Expectations
Managing the expectations of other people in a startup is incredibly hard. Most people have no idea what software development is. They don’t understand the unit of work, how to be successful, or how they can contribute to be helpful. To the others, you might as well be working in the back room, standing over a cauldron, and saying some magic spells.You must be able to manage the expectations of everyone in the startup. You will need to be comfortable in this scenario. Managing expectations is hard, some might say it is impossible. It is also incredibly hard mentally as well as financially. It is hard mentally when you are getting questions on a feature every day. It is hard to say it is weeks, or months away. It becomes especially hard when someone else says that they can produce a feature in some small amount of time. Many people will be willing to try this in thinking that in the short term, it will all work out. Many times it does not work out at all, but that is a much later argument. This becomes a financial issue when the question of you vs. someone else comes up and how any money flows.
The bottom line is that you need to manage the expectations of the others on the team. What happens when the other people won’t accept what you are telling them? That is when you have some amount of conflict. The solution to the issue depends on what the conflict is. Conflict over scheduling can be solved by having a priority list of features. If someone wants something to be done sooner, then the order of the priorities can be changed. That is a simple solution that tends to work out. People understand priorities and can stick with this.
Another issue is that people will not believe you. My favorite one of these was “You should have built this with a web app so that we could not have to deal with paying 30% to the app store.” Another great line that I have heard is something along the line of “My friend’s cousin’s son can do that in a basement in their sleep.” There is very little that can be done in this scenario. No matter the facts, sometimes people will not believe you. Keep an open mind on these issues. They could be correct, however, the possibilities in these scenarios is pretty small.
Another idea that comes up is that more developers will solve a problem quicker. Much like threading, or multiple cpus in a computer, reality is different. Management between multiple threads or multiple CPUs requires time, effort, and cycles. The same is true with multiple developers. The secret I have found is that everyone needs to be in the same location and they need to communicate when there is an issue. This will solve the issue of communication that doesn’t work in a phone call, email, or IM.
The Burned Entrepreneur
Developers are typically well meaning people. Not everything works out. Entrepreneurs tend to blame the developers, no matter what actually happened. Developers blame the entrepreneur. The truth is typically somewhere in the middle. Unfortunately, the entrepreneur will try to recoup their investment either consciously or subconsciously. Two examples that I want to share:
- A startup had spent somewhere between $300 & $500k developing several prototypes and the developers would not do any more without additional money. I felt sorry for the developers because they had clearly been given unrealistic goals and had bad leadership. The startup wanted me to come in, fix all the problems, and basically work for free and cut of ownership; basically, an unrealistic request driven by their not having anything to show from the initial investment.
- I spoke with an entrepreneur that wanted me to come onboard of his startup. He had gone through a round of development with very little to show. He had spent about $150k according to him, but with some missing features. He wanted to contractually require an absurd number of hours per week once and was only promising some stock, and no money.
In neither of these situations were these necessarily bad people. They had not been successful initially. In their mind, they were trying something different. Unfortunately, they were transferring all of the risk from themselves to the developer. Be careful.Look for Part 2 of the article shortly.
