Do Managers Need Deep Technical Skills?
Do Managers Need Deep Technical Skills?
[From the Archive: Originally posted at Amplify.com May 7, 2010]
Jurgen Appelo asked me yesterday to clarify my (tweeted) position that requiring managers of technical team to have deep technical knowledge (within the same technologies as the team) is “senseless” (i.e. not very clever).
So here’s my response:
There are some (few) advantages to a manager possessing deep technical knowledge in those technologies being used by the team. However, these advantages are significantly outweighed by the concomitant disadvantages.
- Easier to win the (early) respect of the team.
- Fount of knowledge on hand when the team get stuck on technical issues.
- Better early inter-personal communication, as the manager and the team have a more congruent understanding, vocabulary, etc.
- Technical skills imply, at least, that the manager in question may have an engineering perspective and understand the software development (e.g. coding) mind-set.
- Superior knowledge makes for less effective coaching, as the “expert” is often sorely tempted to provide a quick answer to move the work along, rather than allow the team to stumble and thereby learn and grow their skills. Aka “micro-management”.
- People coming from a technical background do not often have the coordination and interpersonal skills necessary to help the team achieve a highly-effective state. Consider the perspective of Deming et al: “The Team works in a System. The job of the manager is to work on the system to improve that system with the help of the team”. (Personally, I’d describe it the other way around: The team owns and improves the way the work works (the system) with the help and support of the manager).
- People with a deep technical knowledge have generally acquired that knowledge by dint of love of technology and long hours spent practising their art. Many such folks find it very difficult to set this love and these skills to one side on those occasions when the exigencies of the situation demand more focus on the development and application of their coordination and interpersonal skills.
To recap: Whereas the advantages listed above are more numerous, they are, in my opinion, far outweighed in significance by the stated disadvantages.
Personally, I would generally exclude people with deep technical knowledge from consideration for management positions, as both a favour to them, a favour to the team, and a favour to the work and its customers. Of course, there are rare exceptions. 😉
Amplify’d from twitter.com [original source no longer available]
@flowchainsensei I would welcome an explanation why our policy is “senseless” 5:21 PM May 6th via Twitter for Android in reply to flowchainsensei
[Mar 2, 2012]
Lest anyone slip into the notion that I favour non-technical managers over technically-skilled managers, please note that in the bigger picture (i.e. of organisational effectiveness), we would not have managers at all. The issue then becomes moot.
Pingback: Five Blogs – 3 March 2012 « 5blogs
When you’ve established agile processes (e.g. kanban), you still need some one-time activities to think about new requirements, especially if they are large and with long-term impact. Therefore, maybe projects are more for product owners, while all the other can skip it?
Thanks for joining the discussion.
By “thinking about new requirements” do you mean “considering new product ideas”, e.g. before deciding whether to commit to them or not? If so, then yes we could call this a potential “large and long-term” impact. But how many organisations just do this once? How many organisations don’t have a continual stream of new ideas for consideration? Of course, a lot of organisations approach this in a near, or totally, ad-hoc way. It’s almost as if they expect that every new idea will be their last. The “project” concept only serves to perpetuate this habit.