Tips for Managing Technical People – Respect Your Team

12 June 2014, by

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.

Unilateral Goal-setting Won’t Work

Someone who chooses a technical path is someone who is inquisitive about their environment. For a technical person, every fact about the world can be questioned with a corresponding ‘why?’ Once someone has lived through years and years with this attitude, they get to see the benefits. They realise all the things that they have learnt by taking an interest. They appreciate the decisions that they would have got wrong if they hadn’t been inquisitive.

So the first thing that will happen when you tell a developer to do something is that they will stop and think. They will consider whether it is a good idea or not. If you have a healthy culture, they will want to ask you questions about the task, about the aims and about why doing this particular thing will achieve those aims. If you don’t encourage questioning then they might not ask you explicitly – but they will still consider the idea, and make up their own mind about whether what they have been asked to do would be useful. If you don’t have a culture of questioning, then you probably don’t have a culture of open defiance. But open defiance is not the only way to avoid doing something that you’ve been asked to do. If someone has not bought into completing a task, then they are much more likely to ‘forget’ to do it or to be ‘too busy’ to do it.

Communicate the reasons for your request

On the other hand, if you give a techie a good reason for doing something, the picture will be completely different. Because communication is so difficult in general, you will do even better if you let your developer challenge your assumptions: you may think that you have given a clear and compelling case; they may think that you are just fobbing them off and you have a nefarious undeclared reason hiding underneath. That’s leaving aside the hidden advantage that you may be challenged in a way that leads to a better outcome or a new way of achieving the same ends. By having a discussion with a smart technical person, you might end up getting them to do some of your thinking for you.

A good example of this is reporting. Most people find reporting tedious. If you’ve only ever been on one side of the reporting divide, you don’t have as good an understanding of just how useful good reporting can be. If you can ask with clear reasons for the exact information you need and no more, you have a much better chance of getting exactly that; a long and pointless status format is much more likely to be avoided or rushed.


Categories: Technical


Leave a Reply

* Mandatory fields

8 + = fourteen

Submit Comment