Dec 12

Startups: How To Prevent Your Developer From Sabotaging Your Project

 I know most startup development teams are not functioning anywhere near where they should be and where they need to be for a startup to thrive. How do I know this? I know this because 50% of our clients are projects we were asked to take over and turnaround because the current development team wasn't able to deliver.

The pattern is common, i.e., they seem to start off well enough, with a few early successes, but pretty soon, as quickly as 4 weeks the cracks start to appear. The tell tale signs are things like later and later delivery, incomplete features, misunderstanding of requirements, more and more bugs appearing and more and more bugs not getting addressed in a timely way or at all, features appearing that were never requested, or were requested, but as a future item, for example, something for the next release.

The trouble is, once the ball starts rolling, i.e., once the development team starts on this slippery slide, it's usually heading to disaster, such as release dates being moved to an unspecified date, irrevocable arguments, extended budgets, etc.

Before discussing how to avoid this sort of failure, let’s quickly review why the problem occurs. It starts at the very beginning in the way the startup selects its developer, i.e., it’s typical for a startup to adopt one of the following scenarios when picking their developer: 

  1. They select a low cost freelance programmer, or

  2. A programmer, typically quite young, e.g., college age, offers to develop the software for equity only compensation, or

  3. Someone knows someone who is interested in moonlighting, i.e., they have a day job and want to earn some extra tax free money, or finally

  4.  One of the founders / partners is a programmer.

Each scenario has its own reasons for introducing failure; the freelancer, for example, often under bids projects, either deliberately or accidently, which results in them asking for more money until the startup has had enough.

The college age programmer loses interest when they realize equity only really has value when the company exits. They also find out that hard work isn’t as “cool” as Hollywood makes it out to be.

In regards to the moonlighter, after a month or so, working evenings and weekends starts to become a strain and they decide their quality of life has dropped to a pont that it isn’t worth the money. 

Failure caused by the fourth scenario, where one of the founding partners is the programmer is less obvious and is the most severe of the four scenarios. Because this person has such a large piece of the company and being a technologist, they end up doing their own thing and building what they think should be built and thus tend not to be customer driven. It’s not unusual to hear them refer to prospects as stupid or idiots if they don’t see the value proposition. This person can prevent the startup from identifying the complete product, i.e., the product the mainstream market wants to buy, the one that would make the startup successful.

In addition to these scenario specific symptoms, they all often suffer from common flaws that usually cause the startup to fail eventually. Such as poor communication and collaboration, typically there’s no project management, effective feature and bug tracking or a product development life cycle. The programmer should never have the final say regarding quality control and the completion of a feature, etc. Also, they are usually developing in a vacuum, almost like solitary confinement, which is very detrimental to creativity and innovation where true customer value is concerned.

The solution to this dilemma is an agile TEAM where separate people have the responsibility of the following roles:

• Product Manager
• Project Manager
• Senior developer
• System architect
• Senior programmer
• Programmers
• Quality Control (testing)

One person can assume multiple roles, but there must not be a conflict of interest. For example, the programmer should not be responsible for quality control or user requirements. In addition the team needs to follow customer driven development, be knowledgeable and practiced in developing the minimum viable product (MVP) and correctly targeted at the pioneer / early adopter in the life cycle of the product. The team should implement the release early learn quick model of Lean Startups. All of this requires discipline, which is where the Agile Project Manager needs to shine and programmers are so bad at doing.

I’ve been developing software for over 20 years and I find that a group of people willing to work as the team described above, will always outperform and out innovate and will efficiently build great products, with high quality and will be able to attain a sustainable level of high performance. A programmer on his own typically will not. (Although I was PC by using the word 'typically', my expereince is I have not seen a successful product developed and released by a single programmer or if they have, it's taken way longer than it should have and included a million excuses!)


"This article may not be reproduced in whole or part without including the name of the author (James Naylor) and an acknowledgement of the fact the article was originally published in Shoestring Advice for Technology Startups (http://www.KENOVATech.com/blog). Any other use of this material is unauthorized and is a violation of law."

One Comment

  1. such a well detailed article. thank you so much.

Leave a Reply