There is this disconnect that usually exists between a non-technical CEO and the technical team. Often, this results in frustration on both sides – the CEO wonders why the team is not delivering, and the team feels the CEO is asking for things to be done in an impossible time frame.

And many times, because of how little technical knowledge the CEO has, this communication gap cannot be effectively breached – and the company ends up producing a bad product that cost 10 times of what it should cost.

Here is a little guide on how, as a non-technical CEO, you can achieve success when dealing with developers. These principles can be adapted to handling with technical staff in general.

Step 1: Always get a complete design first.

A design is not HTML; a design is done in Photoshop or a similar tool. It’s a bunch of images that show the entire look of the website. Before you start any form of coding, be sure to get the full design.

Step 2: Do not let the developer determine the technology he wants to use.

The technology to be deployed is a business decision; it’s not a technical decision. Most technologies are interchangeable – what you can do in Ruby On Rails, you can do it in PHP. But from a business point of view, Ruby on Rails developers can be 5x more expensive and rare than PHP developers.

So look at how easy it will be to hire developers before picking your technology.

Step 3: Understand the basics of infrastructure.

For example, you should be able to differentiate between hosting your product on a cloud service (like Amazon) versus having your own server. This is a semi-business decision and should not be decided by developers alone.

Step 4: Evaluate developers based on the points they deliver.

Ask them to list out all features in the software and assign them points. Points are usually based on time required to complete the tasks. Then watch how many points each developer delivers per week. Do not just let developers work. Plan. List out features and get estimates on when those features will be delivered.

Step 5: Do not rewrite.

Every time you bring in a new developer, they will always say they want to rewrite. Mostly it’s because it’s hard to understand the old person’s code, not because their code will really be any better. If your platform runs, is stable and it’s just small fixes you need, and then don’t rewrite it. A rewrite will take far longer than you think and will be far more expensive and the output will be exactly the same as the original one.