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.
Read more on Markessien.com
Some 30 yrs ago in Enugu city,i attended a trade fair,i saw a simple project like an enlarged pipe,and some liquid are coming out of this bloody pipe,this liquid comes out at this specific temperature,at this temperature they got gin(hot strong drinks),menthol spirit,menthane gas.WHAT THEY PUT IN WAS PALM WINE,AND THEY HEATED THIS PALM WINE.this simple pipe was designed by those PRODA at Enugu.
Mrs marie currie and er husband refined unranium in their small shed which they used as their workshop,they poured this mixed and raw uranium into a big bowl and stirred it,with a big stick of which they got polonium and some oter substances,and you can built a big cycleton ,with safety value as unranium is dangerous,even unrefinded.it expand on it’s nuclear,by fussion,t excites all atomic structure,once it starts to expand outside it’s nuclear cell.metals rods are inserted into a mass (container) of refinded uranium to slow it dowm or not allowing this uranium space to expand.
I think,there is a nuclear research facilittyat the university of ibadan