A Project Manager should have good technical abilities

It is very important that the Project Manager for custom software development projects have technical experience; i.e. have programming experience. In fact, if possible, that manager should have a good understanding of the particular technology being used in the project.

The project manager should be the person who works with the customer in order to define the requirements of the project. If that person does not understand the technology being used they will not recognize where there are possible tradeoffs.

Allow me to provide an example.

In the early 1980’s, I worked on a project that was a joint venture with another company based in California. The project was to develop an automated system for testing the heads and disks used in computer hard drives.

Some of the specifications for heads and disks include requirements for things like signal-to-noise ratio and something called “peak shift” which could be best measured by expensive instruments purchased from a third-party. Five instruments costing a total of more than $100,000 were required for the complete suite of tests that needed to be performed. However, no two instruments were used at the same time. In addition some time was spent replacing the head or disk being tested with another production unit. This included the time required for the disk to get up to speed and then stopped. The bottom line was that each of these expensive instruments was sitting idle at least 80% of the time.

A more efficient way to utilize those expensive instruments was to share them among multiple “test stands” containing heads and disks. In that way the utilization of the instruments could be increased significantly. When one of the instruments had completed testing on one test stand, it could be switched over to run that same test on one of the other stands. Moreover the instruments could still be utilized while one of the heads or disks had completed testing and was being replaced.

I managed the project to develop something that we called an “Instrument Bay Controller” (or IBC). The other company developed the test stands where the heads and disks were mounted for testing.

One of the issues that came up is which sort of computer-to-computer communications should be used. Two alternatives were considered: RS-232 and Ethernet. (These can be explained in more common terms by comparing them to methods of connecting to the Internet. RS-232 is the method used for dial-up. Ethernet is the method used for high-speed connections.)

Note that this decision was made about 25 years ago. At that time, the hardware for an RS-232 connection cost $75 per connection. An Ethernet board cost $2000 per connection. In other words, connecting two computers together required two boards – one in each of the computers. So the cost of that connection would be $150 using RS-232 but $4000 using Ethernet instead. There are other costs as well. For example, Ethernet cables were considerably more expensive than RS-232 cables, though that cost difference has gone down considerably. Also because Ethernet technology was relatively new at the time, a larger amount of software development was required to implement it.

I knew two things that affected the decision. First all of the messages exchanged between computers were relatively short with a maximum length of 20 characters. I also knew that the disks were spinning at 3600 RPM which meant that any single revolution of the disk took 16.7 milliseconds. Any message between computers that took less than 16.7 milliseconds to transfer would not impact the overall throughput. RS-232 could exchange such short messages within that window of time.

The company that we were partnering with wanted to use Ethernet. I recommended RS-232. We arrived at a compromise where either could be used. When we put the system into production at our company, we used RS-232. Our partner used Ethernet.

Why did the other company decide to use Ethernet?

The decision was made primarily because their entire technical team recommended Ethernet. I personally believe that they made that recommendation precisely because Ethernet was the state-of-the-art. They all lived and worked in Silicon Valley and, as superficial a reason as this might be, they wanted to be able to tell their peers that they were using Ethernet. Certainly Ethernet has technical advantages over RS-232 (just as high-speed Internet connectivity has advantages over dial-up) and those technical advantages were described in detail to the managers at the other company who made the final decision on which technology to use. However because those managers never understood the actual design, then didn’t understand that in this application there was no real advantage. So that lack of technical understanding cost the company many thousands of dollars.

It is worth noting that about two years later we added Ethernet to the IBC because we needed to send the test data to a database server so that the test results could be analyzed in detail. However by then the cost of Ethernet had come down considerably. Also the technical advantages of Ethernet became very relevant: the messages had many more characters in them and the database server was very far away from the location where the testing was done so that RS-232 simply wouldn’t have worked. But we never had to use Ethernet as the communication methodology for communicating between the IBC and the test stands.

Though it is more of an example of a hardware tradeoff than a software tradeoff, I think that it does demonstrate how important it is for the project manager to have a technical background in order to make the best decisions.

In addition to understanding the tradeoffs better if you have a technical background, if the project manager has to ask a technical member of the project team every single time the customer asks a technical question, the customer will start to lose confidence in the project manager. Surely the project manager shouldn’t be expected to answer every single technical question asked by the customer, and in many cases before the project manager answers the question he or she should say something about confirming the accuracy of the answer with the technical team. But if the project manager can demonstrate to the customer a good understanding of the technical issues of the project, the relationship between the customer and the project manager will improve. Lacking such a level of technical ability, I’ve seen instances where a customer has started to contact members of the technical staff directly without involving the project manager.

That is the path to chaos. If the customer is contacting the developers directly, that customer could be hearing commitments and getting answers to questions that reflect real scope changes in the customer’s expectations of what the solution will ultimately contain. Clearly that should never be allowed. But the customer will be tempted to follow that path if they need an immediate answer to a question and they don’t have confidence that the project manager can provide that answer.

A technical understanding is a valuable asset with any level of management within a software development company. This goes all the way up to the top of the organization.

Joel Spolsky is a software developer, living in New York, who writes about software development, management and business on the Internet. Mr. Spolsky says this:

“If you ask me, and I’m biased, no software company can succeed unless there is a programmer at the helm.”

I wouldn’t go that far. I think that managers who are not technical but willing to take advice of technical people can certainly succeed.

But I certainly think that it is difficult for a software project to succeed without a technical person, particularly a programmer, leading it. (But then, like Mr. Spolsky, I may also be a bit biased.)