Category Archives: Peopleware

My thoughts about being a team manager and managing teams

On Peopleware

Peopleware is a term popularised by classic management book called “Peopleware: Productive Projects and Teams” by Tom DeMarco and Timothy Lister. It was published in 1987, with the 2nd edition published in 1999, by Dorset Horse. I have since been a fan of their management goods including goodies like The Psychology of Computer Programming by Gerald Weinberg and Becoming a Technical Leader: An Organic Problem-Solving Approach also by Weinberg.

Basically what the book talks about are the authors’ experiences managing project team in the software industry. Despite that, many management gems arise that are applicable to most if not all parts of the IT industry and even those outside. Many management books talks about control, delegation, budgeting and managing people, however, “people management” is usually more theoretic and a token sum in their books. Read the rest of this entry »

Leave a comment

Posted by on February 11, 2012 in Peopleware


Tags: , ,

The production line manager

My friend was a bit shocked when his new manager mentioned in a meeting that he would not like to see them taking time reading newspapers in the office, which most of them hardly in fact.

This is the dreaded production line management syndrome.

In a production line, the production operators must keep working to keep the production line running. If any production worker stops or slows down in their track, this will halt the entire production line, downstream and upstream. That is why the priority of a production line manager is to ensure that all their operators are consistently working at the work station along the production line. Slag in a production line is not appreciated nor wanted.

The thing about such mentality is that its easier to implement and to think of your staff as menial production workers, rather than an intelligent being with emotions and needs and as a manager your role is to build a conducive environment and look after those needs. Most if not a lot of managers try to think that they are doing the latter, but still trap themselves in the former. Read the rest of this entry »

Leave a comment

Posted by on March 7, 2010 in Peopleware



Peopleware: Promoting towards incompetency

One of the problem with IT management is that there is no well-paid path, in most firms, for people who are technically competent. Instead, most of the well-paid paths only exists if you are moving through management.

As a result, most people who are looking to get better pay aim to be in management whether or not they are really good as a manager. Hence, a lot of very technically competent persons get, happily, promoted to management, but they continue to run their roles like they are still a technical person, totally out of their competency.

An alternative scenario of technically competent people is that instead of getting promoted, they are kept down in the trenchs, by the nature that they are such an asset to the team. They don’t get promoted to managers or team leads and their pay never ever rises above those in management.

Upper management sometimes tends to recognise people who manages processes very well, but have no inkling how well-liked they are with their peers and promote them as managers. As such, these newbie managers or team leads, start to manage people like emotionless processes and components, which is probably what they are doing before they are promoted! Read the rest of this entry »


Posted by on March 13, 2008 in Peopleware



Troubleshooting hardware: Blind Spots

One thing that I always remind myself of is to be opened to all possibilities, especially when troubleshooting technical issues. This usually works well, but sometimes, when we have already decided on the result or the reason for a problem, it can blind you from thinking otherwise.

The other day at the data center in Japan, one of the HP Proliant servers had a problem and we kept getting the message “hardware error”. So my immediate assumption was that something must be wrong with one of the hardware parts of the server. So in comes the HP engineer to look at the problem. My initial suspect is either the system board or the SCSI board. So I thought that this would be a quick and easy job, 1 hour, everything replaced and we go home.

But NO!! The engineer replaced the system board; it did not work. The SCSI board; did not work. Then we waiting for another 3 more hours for some CPU and memory parts to come in. Replaced the CPU; did not work. Replaced the memory, still did not work! Argghhhhh… it already 8 pm! The good news is that the server was not in production, so we took a break after like 6 hours working on it. Went home and rested.

The next day, a new engineer came in and I expected them to bring in more parts. So I was a little pissed when he did not carry anything with him and I said to myself: “Oh no, what can he do without parts, not another late night!?”

So already I’ve made a decision that this is stupid engineer and was a little bit on the edge (only internally), just waiting to see what miracle he could perform. He ask for a Windows 2003 CD, which we did not have. So I showed him where I got the error and using the exact same hard disks, I inserted it into another machine of the same specs and showed him that it booted up fine. Then I keep repeating (in broken Japanese) that we did this sooooooo many times with all other servers and they worked and only THAT machine did not work. I was trying to impress onto him that he need to CHANGE the whole bloody machine and save my time.

Then he did some that caught me off guard and suddenly and immediately I knew what was most likely the problem!

He took out the PCI network card and the 2 HBA (fiber channel) cards and place them on the floor. Almost immediatly, I knew that the problem must be due to one of the HBA cards and the symptoms makes sense all of a sudden. True enough, it was one of the HBA cards… and it has nothing to do with server, its our own stuff.

I could almost kill myself with stupidity because this is one of the worst sins one can commit in troubleshooting: “Not breaking down and identifying all the variables and eliminate them one by one!” My assumption that the server had to be faulty was so strong that I forgot that other variables, like the cards or even cables could be a source of problem.

Boy did I do a lot of “domo arigato gazaimasu” with him as he was leaving.

Leave a comment

Posted by on June 26, 2006 in Operations, Peopleware


Tags: ,