People Doing Their Work
Unfortunately, people tend to over promise and under deliver. In a corporate environment, there is at least some amount of requirement that people do their work. In a startup, some people just won't do their work. I've seen this across several startups. The most jarring example was a startup that needed to raise money. For whatever reason, the founder would say that they were going to talk to angels and VCs. In reality, they never made the first attempt. People are often intimidated when they are out of their comfort zone. The last thing that they want to do is something that they are uncomfortable with. You have to watch this and hold people accountable. If I am a developer that is expected to give up their life for a startup, I am expecting other people to do the same thing. To push this along, one has to be really careful. Just asking "why haven't you done this yet?" is probably a bad question. Asking what you can do to help move something along is probably a better question.Helpers
Sometimes, you have helpers. As a developer, you have people that want to explain to you how to implement something. They may or may not actually understand what is happening. Unfortunately, they tend to think that they are subject matter experts. I refer to these people as "drive-by subject matter experts." Don't get mad at these people. They are trying to help, however, their help is going to cause more harm than good. The danger of these people is that they will get locked into one thing. They might claim that the one thing they are talking about is an absolute requirement when the feature they are talking about is really just a "nice to have." How do you handle these people? These people are really just looking for something to do. I've always worked on giving them something to do that is helpful to the startup, but not associated with the development. Get them to write blog posts, test an application, or do something else. Just come up with something to get them out of your hair.Money
Financial risk is a major problem. Negotiation to handle this upfront is key. Unfortunately, this rarely happens. People are working their hardest. Money gets forgotten about until it is too late. Unfortunately, the most money today gets spent on development. Unfortunately, development is where the most stress in a startup is. It is unrealistic to put the developers at financial risk in this area. Developers need to protect themselves in this area. I've had this issue come up three times personally. The best example of this is a question on Quora asking for advice on how much personal financial risk is acceptable for a developer at a startup. The question implied that the developer was being asked to indemnify the startup investors against financial loss. Startups are risky, and that is the nature of the beast. Each situation is different. Do your best to protect yourself. There is often the expectation that developers will work for free forever. Nothing could be further from the truth. I don't mind helping people, but my help comes with several conditions:- I'm not doing this for free forever. I don't mind helping you get into first gear with a prototype, but you need to be out there working on customers and funding. I've had this happen. Nothing kills a relationship quicker than "We're going to fail without you, so this is your fault."
- I'm an investor. My investment is my time and my code. Respect my time and my code. Don't bark dates at me.
- Code isn't to just be handed around. Code has business rules within it. I'm not sure why a new "low cost" developer is going to immediately understand business rules, yet I see this a lot, especially for those that do not have software development experience. Writing code for a startup is a two way street and a long term relationship. You want people that you can trust, on both sides. Can I trust you if you want to just ship code around with no thought of the how things work?
Existing Code
Existing code that a startup wants you to take over, wow, is that dangerous. The expectation of the startup is that with a few well-placed corrections, their code will go from a complete mess to a smooth running application that scales. This never happens, and here is why:- Code was written by someone that is no longer in the startup. There is a reason why they are no longer in the startup. The most common reason is that a new feature was needed and the original developer could not deliver. The call for a new feature became deafening. The original developer got tired of this, or the rest in the group go tired of waiting. The end result is that the person is no longer in the startup.
- Code that was written by someone else has business rules embedded in that you are not privy to as well as idiosyncrasies of the original developer within it. You need help in deciphering this, however, that person is not around. Even if you can get ahold of them, that person is not going to be forth coming regarding any ideas or solutions.
- Most likely, the previous developer was not paid for their work. They just want out. They are working on other things now. When you are in this situation, you, and the startup, are better off just starting over. This one is a tough pill for everyone to swallow. To the startup, this looks like they are throwing away their existing investment. They are. Software that doesn't work results in a sunk cost. People have a lot of trouble coming to this conclusion. The non-developers in the group will view this as additional delays and will be against the idea. The attachment to existing code seems to border on the "Stockholm Syndrome." Almost always, there will be too much trouble trying to breathe life back into the code. Don't waste your time
Part 3 of this series will be out shortly
No comments:
Post a Comment