Submitted by jsimmons on
I'm beginning to read the book "Leading Geeks" by Paul Glen. It talks about how the relationship between managers and techies is different than the relationship between mangers and non-techies.
In the pod-casts that I've listened to so far, and I have not caught up on all of them yet, I don't recall any distinctions being made about how managing a staff of programmers is any different than a staff of non-programmers. I did hear that most programmers are high 'C' in the DISC model and that needs to be kept in mind during communication.
From Manager-Tools I've heard a lot about managing the behavior of directs. However, this books says that "Geekwork is less about behavior and more about thought, ideas, and the application of creativity"
Any comments on how managing programmers is different from managing non-programmers?
These are some generalization that I have found (this thread is probably going to get me in trouble?!?): [list]Regularly review programmers progress. They tend to under-estimate what it takes to really complete tasks assigned.
Realize that programmers may have a tendancy to not see the whole big picture (this is the job of senior systems engineers, team leads, mgrs, etc to make sure this doesn't happen)
Programmers love to blame schedule slips on others - sometimes warranted( sysadmins, users, security, etc)
There are sort of two types of developers: some that really love change/new technologies (very fluid) and others that can not stand the thought of moving from FORTRAN (very stuck in their ways)
Never consider a development effort without a vetted requirements document (generally a good IT policy)
Programmers using a highly managed IT system will be extremely resource intensive to sysadmin staff (installing tools, system policy restrictions, resources, security, etc)
Programmers should be highly encouraged to share unique or single point of failure information with others on the team (they don't seem to do it without prompting)
Programmers will work long and non-standard hours to meet deadlines (not everyone in IT will be supportive)
Programmers can be very creative and need regular feedback/recognition when they do something successful
Programmers can be very matter of fact (High C) and non-communicative to others (ie. seem rude)
Programmers are not always very good at being given dual responsiblities like testing, or documentation/training material
[/list:u] How is that for a start?
Your comments help me recognize that the behavior that I'm seeing is normal. I need to practice the feedback model and give frequent reinforcing feedback.
I am a former programmer and am now managing programmers and this list is extremely accurate. In my current work I have especially noticed several things as being true:
Lack of seeing the big picture - programmers tend to focus on the peice they have and will do that extremely well and then find it doesn't fit in to the big picture.
Blaming schedule slips on others - it is always someone else's fault.
Lack of communication - this is a huge issue and is my biggest challenge right now.
Dual responsibility - the programmers can do testing and documentation but NEVER at the same time as programming. You are much better off getting separate people to do those types of things.
Thanks for this list! It was extremely helpful to see some of the things I've witnessed put into words so concisely.
Thanks for the positive feedback. You all made my day (seeing that it was a very low day ... it is much appreciated).
This is a great discussion. Steve, well done.
And... I generally disagree with the premise of the book, and I'll summarize this way:
Managers who manage groups do a disservice to everyone in that group. Manage the individuals. We love the DiSC, but only to start, to avoid disaster. When someone works for a manager, the effective manager is spending hours with that person.
[b][i]Get to know the person, not the label.[/i][/b]
Yes, "geeks" (ugh) tend to skew towards task focused and reserved in GENERAL... [i][b]but that's an oversimplification if you are their manager.[/b][/i]
Mark wrote: "Managers who manage groups do a disservice to everyone in that group."
I can not stress enough how important this perspective is. My first big development effort that I lead probably more than likely went up in smoke because I tried to manage the group and not the people.
What a powerful lesson to learn.
I am currently reading this
I am currently reading this book and finding that allot of points stated in it are accurate but it falls short of suggesting innovative ways to manage the performance of IT professionals. I have ended up using a combination of project management techniques as well as MT tools such as DISC and feedback to manage my team but nothing seems 100% percent effective especially when dealing with late stage performance issues or individuals who simply lack the basic skills you need. This is especially true of soft skills which I find very difficult to test for during a standard lenght interview.
This thread really belongs in the books review section.
I could take these listed attributes and apply it to any social/work/ethnic/economic group at all. Go ahead, try it. Replace "Geeks" with marketing people, sales people, young people, old people, homeless people, rich people and read aloud each of those statements a few times and they begin to ring true in your mind. You begin to see it as accurate. The human brain goes to great lengths to make statements like this make sense and eventually tends to act upon these suppositions. You actually look for confirmations of your prejudices and ignore anything that dis-confirms them. This is why these forms of opinion wrapped in pseudo-science that promote prejudicial judgment paradigms sell so well and are so prolific. This is also why things like this are so dangerous and silly. There was recently a thread like this on managing Gen Y'ers that made me quite upset. Why is this any different?
What good does any of this information actually do for you? What good is the information that "Most programmers tend to blame schedule slips on others"? Are you going to sit all the programmers down for some kind of "how not to blame schedule slips on others" meeting? Is your awareness of that going to prevent those schedule slips? No, you are still going to address the issue individually using the feedback model or whatever passes for it in your management purview.
Mark is too kind here. Managing by "groups" isn't a disservice. It's an insult to your staff, a waste of time and human resources and in some instances it's even considered a crime.
This is quite an interesting topic. I am a former programmer who has very sucessfully managed development projects for many many years.
The main point is that the general characteristics you discuss are true but it does not mean that they are shared by all of the team or that as a team geeks are unmanageable.
The challenge to a manager is to understand the individuals and then mold the team into an effective unit. This can be done by directing assignments into an individuals strengths. What I have found most effective is to find what motivates the individuals (it is rarely money) and then use that motivation as a key to moving the development forward.
In general a software developers estimates are not bad if you consider the 'time on task'. The problem is they never translate 'time on task' to wall clock time. A factor of 0.6 works quite well.
Timely decision making is a very key issue. Software developers as a group are not very good at this and will discuss technical points like religion. The main trick I used was to have a one hour meeting that would result in a decision. The ground rule for the meeting is that all of the technical people involved were invited to the meeting and could discuss the point freely for 55 minutes. If a decision was reached in less than 55 minutes that was great. If not I, as the chair of the meeting, would make the decision based on the discussion and then close the meeting. In the first meeting I was forced to make a decision and everyone was upset at me. The second meeting the discussion was much more focused and at 54 minutes a decision was reached because no one wanted me to make another decision. After that the 'technical religion' was left at the door and the project was the focus and the project ran well.
It is our job as managers to put everyone on the team into a position to succeed. To do that you need to understand the individuals and how to motivate them in a positive manner. If that is done properly what can be accomplished is amazing.