Peet Brits

Hmm, but that doesn't make any sense…

  • Categories

  • Archives

  • Advertisements

Why developers cannot be managed.

Posted by Peet Brits on August 9, 2008

[Article related to the IT industry]

Certain IT companies have policies where they require the employees to log their work time, sometimes even on an hourly basis. Why is it that almost every developer I have ever met is utterly frustrated by this? Regardless of these strict processes, why is it that most IT deadlines are still late?

These and similar questions have been bothering me for a while, and I could never quite place my finger on it, until recently. I am going to attempt to give you a very stereotypical view of what I believe the typical developer/architect/engineer is like. I would just like to mention that this article is not purely from introspection, I used external sources as guidelines.

Your (stereo)typical developer

1. Value their own opinion over that of others.

At first this might sound like a weakness, but with regard to their work and self-critical nature, it can in fact be their strength. This also result in them not being so much impressed by authority, rather by that which is useful.

2. What works over what is right.

They don’t care that much about political correctness. Here is an example. The company has a policy that every alien USB device must be scanned before it can be inserted into a computer. It is, however, Saturday morning, and the logistics team is not around. Since the work needs to get done, the developer is not going to think twice about inserting it.

This might sound rather negative at first, but as it is the developers who will eventually be responsible for creating a better wheel for tomorrow, there are times when they need to break away and follow their own minds and instincts.

3. Abstract, not concrete

This abstract manner might be to blame for the late deadlines. They are so much focused on new possibilities that the existing ones are not always turned into reality. They often leap between ideas and possibilities.

Your typical manager (those not from a programming background) are usually far more concrete and structured. They love making lists and follow it to the dot. In their minds it not only makes perfect sense to log work records on an hourly basis, it also give them a sense of fulfilment. They believe in the evidence of the facts of here and now rather than wasting their time on new ideas and endless possibilities.

As you can see it is clear why managers became managers and developers became developers. Sadly, a lot of times the managers want to force their ways down onto those around them, but just because it works for them does not mean it is going to work for everyone else.

Note that I am not saying that developers are not goal driven. Some are more and some are less, and usually it is a good idea to combine them accordingly to make up for each other’s weaknesses.


They need freedom and room to operate. Do not tie them down with needless administrative processes; leave it for the people who are good at it. As a result you will notice that overtime will no longer be a problem. This is because the important thing to these types of people is long uninterrupted sessions of quality work. Most of them even have an insatiable hunger to accomplish the goals they set their minds to.

Of course, you need to make sure that they are passionate and faced with enough challenges. A lot of them have got short attention spans and are thus easily distracted once bored. As I also mentioned in a previous article, it is very important to recognise the gems from the shiny stones, otherwise the above suggestion will instead become an easily exploitable loophole.


7 Responses to “Why developers cannot be managed.”

  1. Brandon said

    Ohh, very insightful. They started doing timesheets a few months ago as well. Oh Joy. /sarcasm

  2. peetbrits said

    If only the people with real authority could read this. *sigh*

  3. Edd said

    I agree with you that managers can’t manage developers, or putting it a bit differently, most managers can’t manage programmers. I worked at UCSSM at the beginning of the year for about 2 months, so I more or less know who your managers are.

    Management at UCSSM might be good at managing their processes and making sure that their developers log their time, but they have absolutely now knowledge of “recognizing the gems from the shiny stones”, and how could they, they recruit new staff members and let them generate source code for an application that by Industry standards are far from perfect.

    It would be a good exercise to go around asking the head developers a couple of questions on patterns and then after they answered to ask them to go and show you where they implemented it in their system, which they more than likely can’t or if they can, they did it wrong.

    So how does a manager separate the gems, if any person that starts their can’t really do any real good work as they are bogged down with processes, code generation and a manager that has absolutely no idea of what good software engineering standards are. I would say don’t stereotype managers, you do get real good managers and those are normally the ones that have development experience. The more development experience they have the better managers they make.

    And that is my 2c on management.

  4. Peet Brits said


    The point of this article is not attacking managers, they have their place and purpose. The point is suggesting a better method by understanding the nature of the problem. Then, instead of trying so hard to control, rather guide in the right direction.

    It is useless to have a great high-level vision while the big shiny stones are causing the small gems to get thrown away.

    One day when I am in control of my own company I will do things the right way, or at least go out trying.

  5. Edd said

    Hi level vision is fine as long as a company can align the implementation of the code base with their vision. A company’s high level would most definitely include a small turn around time for customer request i.e. Customer A needs their invoicing to be done in a totally different way than the system does at the moment.

    Now if the code base was done catering for change (Loosely coupled) it would be easy for the development team to make the change. But managers don’t think that way; they want results as soon as possible. Now what I’ve seen happen many times, the more management pressures the team to deliver the worst the code gets. Go thru a couple of quick change iterations on a code base and the code gets bloated and more complex.

    The more complex the system gets, the more tightly coupled the system becomes and the longer it will take to make a small change. This is something that mangers can’t understand, they think that we as developers are just suppose to sit at our desk and hack away their request.

    I would suggest that companies should employ managers that have technical background. But background alone will not be sufficient; the manager should also stay clued up with current trends in development. We all know how fast the industry changes, and what was good 1 years ago, is considered totally outdated now. So for a manager that had technical knowledge 10 years ago, but did not stay up to date with trends, managing a team effectively would be next to impossible.

  6. Peet Brits said

    > i.e. Customer A needs their invoicing to be done in a totally different way than the system does…
    I recently wrote an article on that very topic, should post it within the next week.

    I agree completely with what you are saying. The big problem with this situation is that the people at the top, those ranking higher than all the managers, are under the impression everything is fine! It is not because they are ignorant, but rather because they are misinformed. All our suggestions are great at a lower level, but it will usually be ignored coming from someone without authority.

  7. Peet Brits said

    And as promised, here it is.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: