Non technical · Entrepreneurs

How do you save yourself from being fooled by programmers when being a non-technical founder?

Luigi Guarnieri Sales Support Cash&Carry presso Esprinet Italia

October 9th, 2016

This has happened to me. I am sure most of the non-programmer entrepreneurs must have come across such circumstances. Most of the time programmers make excuses when he / she can’t do something. How do you deal with that?

Arthur Lipper Chairman of British Far East Holdings Ltd.

October 9th, 2016

Brilliant question. Code writers fool themselves due to an insufficient understanding of that which is required. the answer may be to pay them only (perhaps fully) on the acceptance of the work they produce. Inevitably, the problem is going to be, in part, the mutual lack of understanding of what is required of the programmers. I have used programs in the U.S., India and the Philippines. the success of the projects has been dependent on the level of my non-technical involvement. It is the same as with much of teaching and learning in that progress to the next chapter or project stage should require a defined achievement. Arthur

David Austin Relentless problem solver and innovator.

October 9th, 2016

Agreed with Arthur. It's generally a function of experience of the programmer, not an intention to fool anyone. Budget programming comes at the cost of risk. There are a lot of ways to hedge your success ... starting with a validated track record ... do the validations yourself .. ask for references. Also make sure you have budgeted for unanticipated cost over-runs. Non-technical people have a hard time with the concept that you actually can't anticipate everything ... but you should expect that they programmer (and yourself) has a contingency plan when things go upside down. Trust nothing ... expect daily updates ... meet often, especially when in a crunch. Like Arthur said, success is dependent on the level of your non-technical involvement. Don't settle for "it's complicated" when things go awry ... get details and force them into putting the challenge in terms you can understand. This often is a good exercise for them forcing them to think outside their little box ... can often spur solutions or workarounds they'd otherwise not consider. When non-technical people complain that something wasn't delivered on time or that the programmer did very little, which they themselves were not on top of it and requiring waterfall charts (or whatever the programmer uses) with a schedule and daily updates on sprints, etc ... I'm not surprised. This isn't a programmer thing ... it's a human thing. People perform better when watched.

Ofer Herman CTO and Co-Founder at Papaya Global

October 10th, 2016

Hi Luigi,

Overall I agree with @Arthur, so if you hear that things you want can't be done I'd suggest that you:

1. Check your requirements - are you asking something like: I want parallel lines but I also want them to meet? It's amazing how often developers get conflicting requirements from product owners. You need to give the developers clear and detailed requirements.

2. Ask your developers what can be done within the given timeframe - communication is the key here and you need to be able to describe to your developers what are the priorities and constraints that you have

3. Require frequent deliverables - as @Brendon wrote, Agile can help keep you in control over the development and let you adjust course if/when things aren't as you expected. for that you need to see the progress once a week or every couple of weeks

4. Create a detailed mockup - start with a designer that will create a mockup of your product using invision or marvelapp, it will help you deal with logical issues before a single line of code is written and when developers get into the picture it will give them a better understanding of your product then any document or other description can.

5. Keep open communication channels with your developers - encourage your developers to ask questions and involve them as much as possible in the reasoning for your decisions, a developer (or any employee) that understands why he's doing something will do a better job

At Papaya Global we have a remote team and we help other companies find and manage remote teams so I can tell you from experience that working with developers local or remote is doable.

Kawal Arora Technologist , AI/ML,Blockchain

October 9th, 2016

Best is to have a tech co-founder , tech manager u can trust and they know how to manage programmers , it could be that they could be also telling u the truth and you could not be trusting them , it can be frustating for them as well .

Brendon Whateley Founder at Kugadi

October 9th, 2016

Being a technical guy, I can tell you that development people have little to no idea of how long things they have never done will take.

I'll say it again: "We really have almost NO idea how long something we have not done before will take."

The problem is that the unknown items can't be known, until they are. That basically means that no matter how carefully you plan, short of actually writing and testing the code, you don't know all the hidden traps that will eat hours or days!

How to deal with that? Set things up so that you can deal with the uncertainty and then keep the pressure on. Read up on Agile Development -- there are a host of similar techniques that all revolve around short sprints to goals, incremental improvements and daily SHORT update meetings. Simply having everybody in the team participate in a daily "standup" meeting where each in turn mentions what they did yesterday, what they plan to do today and what obstacles may be blocking progress. After that brief (we keep it less than 15 minutes) anybody that has no need to follow up with others leaves and gets back to work. People with blocking issues or a need to coordinate discuss in smaller groups as needed.

As a non-technical manager, you should easily be able to monitor the commitments for the following day, see who misses often, notice the issues, etc.. In other words, you will never be surprised at what is happening. And by focussing the team on doing "good enough" for this iteration on the most important features, you can move things forward nice and quickly. What is "most important?" Tasks that help move business goals forward. Engineering should not be doing anything "nice to have" that doesn't materially help the business. 

Christoph Ranaweera validate early, pivot and kill fast instead of feeding a zombie

October 9th, 2016

that is always a case by case approach but some of the following might help.

pay for delivery: 
Decide on particular milestones and functionality and pay only once those are delivered in the way defined.
disadvantage is that agile (check and change) is not possible without extending the milestone and thus the pay but if you know exactly what you want that would work.

check references.
Request references from programmers and check with people the programmer worked before.
Of course the programmer will rather tell positive past cases as reference but you still might be "lucky".

If you really want a continuous agile approach you will have to get somebody on board who has a tech background like a product owner.

good luck

kraig Into ICOs, fintech and saas

February 22nd, 2017

You don't need a developer. You need a "technical project manager". While there is some overlap the skillset is not the same. They need to be able to tell you that your project is undeliverable "out of spec" and you can either change price or method to get what you want cheaper. (E.g. Moving from native to web app in this use case can reduce costs by a third) a developer isn't likely to tell you that unless they want to lose money And can see it themselves. A cofounder will. They talk to you in terms of vison and what you imagine your users doing. Then they talk to the developers in terms of APIs/functions/subroutines for/while loops, new objects,etc. (the developers here will know what those mean) :-)

Arindam Bhattacharya Strong Ideas, Big Opportunities...Found, Co-found & Re-found.

June 8th, 2017

You perhaps need to engage with them and understand why they are avoiding certain tasks. Boost them up and making them realize their pride in profession.

Luvon Dungee I am a dreamer, inventor, creator, artist, writer

February 22nd, 2017

This question is so relevant in space I now occupy. By profession I am a Realestate developer who created with the assistance of an oversees programmer, who took forever to complete task.. Now that the project is complete I feel lost. The site functions and does everything I designed the site to do but now I need to find a tech co-founder who I can trust and depend on to continue the journey; any suggestion of where to start?

Joseph Wang Chief Science Officer at Bitquant Research Laboratories

October 9th, 2016

You need some sort of technical co-founder. 

One thing about programmers is that they tend to be absolutely terrible at time and scope estimates.  Also without some sort of technical knowledge, it's hard to tell if the objections of the programmer are real or not.  If this was a developer forum, you'd have story after story of managers that have unreasonable/unrealistic requirements.

Also one thing that you can do is to accept bad news upfront.  One reason programmers tend to be terrible at time/money calculations is that there are strong disincentives for being good at it.  What often happens is that company X gets five or six bids.  Some of them are highly unrealistic.  Some of the are rational.  The trouble is that people then take the highly unrealistic bids, and then what happens is that people get the contract and then take a long time to do the project.  You can help a lot by not automatically taking the lowest bid when it comes time to find a programmer.

I disagree with a lot of the comments here.  It turns out that programming jobs can be managed on time and on budget.  Yes, the unexpected happens, but the unexpected happens with any sort of project, and one of the things that you can do is to go with and mitigate risk, and but in reserves.  The problem is in the Jack Nicholson "you want the truth, you can't handle the truth!!!"

One thing that worked beautifully well with a company that I worked at was the concept of "business time" and "business money."  What the company did was to statistically track estimated completion times/costs with actual completion times/costs.  It turned out that the two ended forming a very nice function, so when someone gave an estimate of two months and $2 million dollars to compete a project, we knew that it would actually take six months and $4 million dollars.