Tips for managing technical people – There is never a substitute for using your brain.
9 March 2016, by Zoe Cunningham
The following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.
In most organisations, when there is a problem with quality or productivity, the answer is to introduce a new process. Too many faults in your widget output? Introduce a quality check or refine the widget-head-putting-on steps. Customers not buying enough? Give your checkout staff an upsell script.
I‘m not saying that there isn’t a place for process in software development. For any mechanical steps, such as those required to make a software release, process – or better still, automation – is essential. But process can’t help with the basic process of software creation.
The reason for this is very simple, and apparent to anyone who has ever done the job (if you’re not technical yourself, your team will find it bizarre that you don’t understand this). For all that we are working with logical, rational, calculating machines, the process of controlling those machines is a creative endeavour. Trying to do it by rote is like trying to paint a picture by rote. You’ll get an outcome, probably much more quickly than you otherwise would, but it quite simply won’t be very good.
The processes that do exist tend to be aimed at keeping arduous administration away from the developers, and allowing them to get ‘into the zone’ – a place where their creativity can be unleashed.
The problems that software developers have to solve are not mundane or routine. There are almost always dozens of different ways of approaching the same problem, and the subtleties of the situation will mean that a solution that may be the correct approach to take in one case could be disastrously wrong in another. So, while you should make sure your developers are aware of best-practice approaches such as dependency injection, you shouldn’t be trying to get them to apply them formulaically.
As a developer, some of the least constructive conversations that I’ve had have been those in which I’ve been trying to discuss what approach to take with someone who’s following a rulebook. One of my colleagues, working on a client site, was terrified of explaining the correct way to do something to the client’s tech lead – open debate wasn’t welcome, and if he didn’t give the answer that fitted with the tech lead’s learned architecture patterns he’d be accused of insubordination. The project that they were working on is now three years behind schedule, and still hasn’t been released.
Tags: galvanizing the geeks