Big News: FounderDating is joining OneVest to build the largest community for entrepreneurs. Details here
Latest Notifications
You have no recent recommendations.
Name
Title
 
MiniBio
FOLLOW
Title
 Followers
FOLLOW TOPIC

Question goes here

1,300 Followers

  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur

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

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?

9 Replies

Sheshan G
0
0
Sheshan G Entrepreneur
Entrepreneur | Business Engineer
Hi Luigi . Ifyourexperience problem in handling your IT team . To make the work flow better , Try to replace charge of the design division . Feel free to contact me if you need any help , i have come across the same problem with successfully . How do you save yourself from being fooled by programmers when being a non-technical founder?@media screen and (){#yiv1216122932 #yiv1216122932featured-advisors-left{width:45% !important;padding:0px !important;}#yiv1216122932 #yiv1216122932featured-advisors-right{width:54% !important;padding:0px !important;}} | FD:Discuss | New Discussion on How do you save yourself from being fooled by programmers when being a non-technical founder? | Started by Luigi Guarnieri Sales Support Cash&Carry, Esprinet Italia. 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? FOLLOW DISCUSSION or Reply Directly to this email to participate in the discussion Manage your email notifications
Christoph Ranaweera
1
0
Christoph Ranaweera Entrepreneur • Advisor
Product Lead
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
Arthur Lipper
2
0
Arthur Lipper Entrepreneur
Chairman of British Far East Holdings Ltd.
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
Kawal Arora
1
0
Kawal Arora Entrepreneur
Founder at Smartefy
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 .

David Austin
1
0
David Austin Entrepreneur
Entrepreneur
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.
Brendon Whateley
1
0
Founder at Kugadi
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 obstaclesmay 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.
Joseph Wang
0
0
Joseph Wang Entrepreneur
Chief Science Officer at Bitquant Research Laboratories
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.
Joe Walling
0
0
Joe Walling Entrepreneur • Advisor
Experienced software developer, software architect, owner of custom software development shop
To avoid this situation in the first place, make sure that you hire trustworthy senior developers with proven experience in the specified technology. If you hire junior developers because you think they are cheaper, you will often run into this because solving the problem may not be possible for them. They also may have painted themselves into that corner due to lack of experience.

If you have already hired a junior developer and this happens frequently, you either need to get a technical adviser or a senior developer to be on standby to help resolve these types of issues.

If you have any specific issue you would like to talk with someone about, PM me. I'd be glad to spend a few minutes discussing if the technical issue is real or imagined.

Ofer Herman
1
0
Ofer Herman Entrepreneur
CTO and Co-Founder at Papaya Global
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.

Join FounderDating to participate in the discussion
Nothing gets posted to LinkedIn and your information will not be shared.

Just a few more details please.

DO: Start a discussion, share a resource, or ask a question related to entrepreneurship.
DON'T: Post about prohibited topics such as recruiting, cofounder wanted, check out my product
or feedback on the FD site (you can send this to us directly info@founderdating.com).
See the Community Code of Conduct for more details.

Title

Give your question or discussion topic a great title, make it catchy and succinct.

Details

Make sure what you're about to say is specific and relevant - you'll get better responses.

Topics

Tag your discussion so you get more relevant responses.

Question goes here

1,300 Followers

  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
Know someone who should answer this question? Enter their email below
Stay current and follow these discussion topics?