Estimated reading time: 4 mins
I am not going to take credit for all of this post… I was inspired by Esther Schindler ‘s article on CIO.COM titled ‘Managing and Motivating Developers: Tips for Management Cluefulness .’ The subject is close to my heart as over the last 8 years I’ve been doing exactly that. I’d also say that Esther’s wisdom and my own experience is transferable across geographical boundaries, as developers show very similar characteristics whether they’re in India, South Africa, Australia, the UK or the USA. Only culture dictates how extremely they are applied.
If you haven’t been a developer yourself then developers can seem like strange beasts. Indeed they are not conventional animals. I don’t think you need to think like a developer though to get the most from them, and for them to do it willingly with passion and commitment. It takes a little understanding of how a developer works, that’s all.
Developers need the space to think and be creative. A developer is an interpreter and a problem solver. Therefore they need room to do their thinking. This means that a developer may behave unconventionally while interpreting requirements and creating the solution to the problem. To the casual observer, the developer might look idle or as if they are loafing, perhaps playing solitaire or chess online. This is part of the problem-solving process! So IT leaders must allow it to happen. One other thing; the problem-solving process doesn’t end when the developer walks out of the door. It continues whilst they drive, whilst they shower, whilst they sleep. So don’t be on their case about the number of hours worked. The crux of it is, trust them to work their preferred way. Measure their productivity on results, not on time sat tapping code.
Developers must develop, nothing else. The most successful IT leaders responsible for development teams don’t ask their developers to do anything else, such as write up reports, manage projects or attend meetings. Developers as a whole don’t do well at these things, so you’ll be disappointed. It’s much better to do it yourself or use a systems analyst competent enough to perform these tasks. The problem solving process uses up so many brain-cycles, developers aren’t able to focus on other kinds of tasks not involving code.
Involve developers early in the design. Many organizations like to use gated or waterfall methodologies where a developer is given a spec to build and not much else. I’ve found these approaches to miss so many opportunities to optimize the product and reduce development life-cycles as they don’t involve the developers early enough. Now I am not contradicting my above point. But influencing the requirements, architecture and design IS part of the problem-solving process. Developers know your system more intimately than anyone else, so who better to make sure any opportunities for efficiency and effectiveness than these guys?
Developers are ‘high-touch’ employees. To get the most out of developers, I’ve found it absolutely vital that you constantly give them your ear, respond positively to them, follow-up with them on any issues or opportunities, and praise them constantly. It must be something about their personality type but developers need to receive continuous confirmation that they are adding value. Developers like to talk about the problems with their environment that disrupts the problem-solving process, so listen and deal with the issues quickly. Developers also like to see leaders walking the floor and showing an interest in the problems they are solving as they tend to be very proud people; their creativity is their motivator (see my article on using the Power of Pride to motivate .)
Pay well, through the nose if you have to. Developers are not cheap. The very best developers are very expensive. But you get what you pay for. Moreover I have strong evidence to suggest that the better the developer, the more value you get. To illustrate by an example, say Bill is paid 50K, Ben is paid 50K, but Sally is paid 100K – I have experienced many cases where the productivity of Sally outweighs that of Bill and Ben combined.
Developers are not commercial. So don’t expect them to think that way. It’s rare to find a developer with commercial or pragmatic qualities. I would question the quality of code of a developer who did. Only a few exceptional individuals I’ve met were strong developers but had solid commercial experience.
For the IT leader new to running a development team, I strongly urge you to consider the above points, and to take a read of Esther’s article I’ve mentioned above. It could save you a lot of frustration and resignation letters on your desk!
