If you can’t load a rifle, don’t be a general.

I firmly believe that technology management should come from within the ranks, not from non-technology areas like sales, finance or marketing. Although this doesn’t seem to be that important a requirement for more generic roles like Operations or Infrastructure leadership, it is an absolute essential for the management of software developers and engineers.

My first example of how a non-technical leader created large problems in an organization is a time when a sales and marketing executive was appointed to the office of CIO (Chief Information Officer). This CIO even told me he had no technical skill and would rely on me for such. Generally, this is acceptable because a CIO’s job is more politics than anything else, except this CIO did not have the technical background to discern who was telling him the truth. This culminated into a huge problem when the CIO began experiencing relationship issues with an employee responsible for the maintenance of the department’s source code control system. Since this employee maintained the system, he was the sole possessor of the source code control administrator’s password. However, when the CIO eventually forced this employee to quit, he was not aware of this password and thus did not secure it before the employee’s departure. A day later, I discovered this mistake but it was too late. The system was no longer manageable and even from the time I left the organization, no solution had been found.

Although the above experience highlights a specific problem created by a non-technical leader, I think the best example of why the general needs to know how to load their own rifle should be drawn from my experiences at another company. The CTO (Chief Technology Officer) didn’t understand technology anymore as he was near retirement, so he hired a young management team to head things up, with me brought in as the manager/lead developer of a smaller unit. Now one of the managers he hired was a consultant who previously worked for smaller companies in senior leadership roles, so the CTO made this manager, who was Director of Web Solutions for 1.5 years, the Director of Development and placed all the application development teams under him, including mine, in order to complete the Documentum implementation for the business. During this time, I discovered that the Director of Development had very basic knowledge of scripting languages and installers, and lacked the technical competence to lead the implementation of a Documentum system. Ends up, this Director lacked the skills to manage the web solutions team he was originally hired for too; this became public knowledge when 6 months later, the company’s main customer web site suddenly began crashing continuously after outsourcing the operations aspect. The President ordered an investigation of technology, which resulted in identifying all the problems to be resulting from the web solutions team. Further examination showed their productivity to be one third that of my department, and that their code produced twice as many production defects as custom applications I was responsible for. It was concluded at an executive meeting that the web solutions team had been completely unmanaged since the Director of Development took over. At this point, the Director of Development and CTO left the company.

I, on the other hand, was an experienced developer and software engineer from EMC (a computer storage company) before taking the leadership role, and therefore was able to read the code and extract the inner workings of the systems on my own, with minimal help from hostile staff. In order to lead my department, I had to replace the original team and keep it running based on my own knowledge. Despite all this, I was three times more productive then the entire web solutions department. Why? I knew how to load my own rifle, so I could pick up the tools and learn the publishing system on my own. Plus, by understanding the internal workings and source code, I was able to successfully identify architectural problems and make releases to fix and/or mitigate those risks, saving myself from the embarrassment of having my production systems crash continually at the data center.

Therefore, I firmly believe in the statement: “If you can’t load a rifle, don’t be a general.”