“Engineers like to solve problems. If there are no problems handily available, they will create their own problems.” — Scott Adams
Here are my top three great engineers’ excuses and what to do about them.
- This new technology is cool – we should use it
Your development guys will sometimes get bored with what they are doing. They will chat to their pals, watch a TV programme or discover a new technology or trend on the Internet. Before you know it, they may convince themselves that the business will fail unless in embraces this cool new technology.
Now, they may even be right, the technology may be cool and give you great advantage. I would certainly entertain a culture that allows these discussions to germinate, however you do need to get the guys to convince you as a team that this is the right thing. So, get your engineer to present to you why this will ultimately benefit the customer and to highlight any pitfalls they envisage. Also, if it’s a new development language or technique, ask how many others are using this. If it is a few, then it might be expensive to find developers to maintain the solution later.
Be prepared to reward them if the idea is good, but let them know that the responsibility to ensure this does not damage the business lies with them.
- The last guy who wrote this got it all wrong
Now, they may say something like ‘we need to re-factor this code’ or ‘I would not have done it this way’. To dis-arm this statement you need to have more than one person involved in the decision. Your product manager and team leader need to agree that this code needs to be re-factored (if the effort level is high). It needs to be balanced with the other activities the team is engaged with, therefore you need to keep your team up to date with what you are trying to achieve. Sometimes, if it’s not broken you should not try and fix it!
- I think I can improve this by adding these neat features
Engineers are perfectionists. They will keep engineering until the cows come home. Don’t let them! Unless there is a clear differentiating function for the customer you should not build it. Period! I have seen many occasions where an engineering approach has developed useless functionality that is not only not used but complicates the system on behalf of the customer.
Again, to keep control over your team remember to update them regularly about what the company is trying to achieve and how well it is doing in it’s objectives. Encourage a less is more attitude and ask your team to balance customer benefits against build cost as a matter of course.