Mark Essien: 5 tips for non-technical CEOs when dealing with developers

There is this disconnect between a non-technical CEO and the technical team. Often, there is 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 the CEO knows, this communication gap cannot be effectively breached – and the company ends up producing a bad product that cost 10x of what it should cost.

Being a software developer, I usually have a pretty clear idea of what the technical team is working on, and can understand the issues they face. Here is a little guide on how you can achieve the same as a non-technical CEO.

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 its hard to understand the old persons code, not because their code will really be any better. If your platform runs, is stable and its just small fixes you need, 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.

This post first appeared on Mark’s personal website, MarkEssien.com