Phil for Humanity Phil for Humanity
A Guide for the Survival of Humankind and Helping the World, Society, and Yourself.

Signs your Engineering Department is Too Big

I have been in the software engineering business long enough to recognize the most common signs that your department has become too large and thus has problems that smaller organizations would never have.

The first bad sign is when upper management, who are not technical, requires certain tools or processes to the engineers. Typically this is because other departments report that they develop their products faster and with higher quality because of their unique tools and process. Unfortunately, engineering tools and processes are not one size fits all. Depending on the type of work being done, the tools and processes should be different. Furthermore, it is not uncommon for other departments to embellish their quality and productivity reports thus making their tools and processes look better than they actually are. My advise is to let your process experts and most experienced developers investigate all new/recommended tools and processes, and they have the final decision if new processes and tools will be used.. and not management.

Another bad sign is when a common tool is used for the sake of commonality and comparable metrics. Even though having common in-house developed tools does save money on the front end, it typically costs more money on the back end. Usually, engineers have to spend extra time with workarounds that are never estimated in the cost of the tool. Next, accountants and business managers love common metrics to help compare projects, even if these projects are of different types and therefore should not be logically compared. In my experience, local tools or at least tools that are heavily customized per project are best for each project and engineers, however these types of tools do not benefit management as much as common tools. Hence, I have found it is best for the project when management supports local tools that engineers prefer and not force their management requirements above engineering's requirements. It is my experience that engineers always select better tools than management for project, because they select tools with the highest quality, streamlined utilization, ease of use, and high speed performance in mind. This is because it is the engineers who would be feeling the pain with using the inappropriate or bad tool, so they have motivation to select the better tool for development.

Additionally, another bad sign is when a tool dictates the process. If this happens, then engineering ends up with an inflexible process that can never completely satisfy everyone's requirements. In other words, when a large number of different teams are forced to use a common tool, the processes for using the tool are also forced to be common too. Unfortunately, this causes the usefulness of the tool to decrease for each time, and never fully satisfies all the requirements for all the teams. The only logical solution for this problem to only use fully customizable tools for each project or different tools for each project. In other words, each team should have their own processes, and each process should define the tools. Not the other way around when the tool defines the process.

Finally, the last major problem for large organizations is bad middle management. It is my experience that people who appear to be suave, good looking, smooth talking, and/or seemingly politically correct, yet who are less technical than other engineers, are more likely to be promoted to middle management. Also, the good ole boy networking, for instance people who play golf with their bosses, are more likely to be promoted as well, since they socialize more with management and have more opportunity to talk negatively about their peers. And finally, nepotism or the hiring/promoting of family members to be quite common too. If you noticed, all the problems with middle management is based upon promoting people who do not deserve it. In my opinion, middle management, those who directly manage engineers, can not be idiots and must have significant technical background of what the engineers are actually working on. If there are enough bad middle managers, then all the projects will suffer. The only solution is for upper management to take notice and enforce demotions.

In conclusion, most of the problems that I have written about are common for large companies with large engineering teams. While they are all addressable, they are often not resolved and an organization get buried with the burden of red tape and process for the sake of process. As a result, smaller companies have a much better chance to more quickly develop competing products that are more innovative too. In the end, the bureaucracy of large engineering teams is their downfall. That is why I recommend working for much smaller and dynamic companies or engineering teams where management stands out of the way as much as possible.

by Phil for Humanity
on 10/16/2010

Related Articles
 » The Use of Artificial Intelligence for Program Development
 » The Dangers and Pitfalls of Software Engineering Measurements
 » IT Self-Destruction by Management