I recommend reading all five posts if you work in an engineering or technology related field, especially if you are a manager who works in one. The fifth article argues that technical leaders need to be technical and able to write code:
All external management hires must be able to write code and show a high level of technical proficiency, up to and including the head of the technical department. If the company is a technology company, this should also include the CEO.
There is an odd misconception that this is not a necessary requirement for an executive or manager, as though programming were just a fancy form of typing. No other specialized industry seems to feel this way: banking executives are expected to be able to read a balance sheet; an automotive executive would never be hired if they didn’t know what a catalytic converter did.
This article hit home because I’ve worked at places where the technical leaders weren’t technical. I discovered that this often worked out the detriment of the company, but I couldn’t quite put my finger on why until I read this post.
A “technical” organization whose leadership is non-technical fails in one or both of the following ways:
1) Leaders are unable to tell when the technical staff is not performing up to snuff, because they cannot reliably differentiate between excuses for poor technical performance and true obstacles that arise when contending with difficult technical challenges. Performance management then becomes impossible, leading to mediocre work and eventually, outright and repeated project failures.
2) Business needs cause leaders to override the suggestions or opinions of the technical staff. Today’s harsh business environment requires that business leaders push their organizations continually beyond their old boundaries, and sometimes this means that a leader has to tell their staff to “damn the torpedoes” and stretch further than they are comfortable. Unfortunately, a non-technical leader has no personal ability to gauge the actual risk profile of overriding technical suggestions (i.e. shrewdly exceeding old limits in certain special situations) and is then prone to eventually overriding technical advice which should not be overridden.
Wow. In two points, Mr. Wong has articulately explained what I felt long ago. And for that I thank him.