In this social media age I am often surprised by the reaction to what I say online. Usually this is not by the reaction to what I say but rather the lack of reaction. I’ve lost track of the number of times I’ve written what I think is a killer-blog post, or a super meaningful tweet, pushed it out in great anticipation and…. well…. nothing.
Just goes to show: what you think is good and what your “customers” think is good can be two completely different things.
And once in a while the reverse happens. I push out a something I think curious, of minor interest, something unobjectionable and bang! A week or two back I put out what I thought was a slightly humorous tweet which would be agreeable to many:
“If you manager doesn’t know what technology you are using then they probably shouldn’t be your manager.”
And bang! People – techies! – took exception and rushed to defend managers – usually that is my job!
In a way I was delighted that so many people rushed to defend managers – and to say how managing wasn’t about technology. Most of the IT community damn managers without a second thought. Thanks guys!
Well I feel the need to reply and explain myself more fully. First lets clarify what I mean, then I’ll explain why I think its important.
A friend of mine recently delivered an Agile Introduction course to a client. Before the course the team leader/manager couldn’t tell him what technology the team were using. That is: which language (C#? Java? PHP? Scala?), which operating system (Windows? Linux? MacOS?) or which database (SqlLiite, MySql, SQLServer, Oracle?). Sure we could guess because we knew it was a web development but beyond that…. Anyway, not critical.
This confusion continued at the course itself. Apart from the coder (and possibly the tester) none of the others involved with the work knew which technology was being used.
My interpretation of this situation is: those who didn’t code were disconnected with the work of the technical staff. A gap existed, if they were ignorant of the central technology then what else might they be ignorant of? (I once heard of a UK Government/BigConsultancy project where when asked “Where are the coders?” a project manager replied “I don’t know, Bangalore I think”. It later transpired they were in Newcastle-upon-Tyne.)
I also take it as a sign that those people do not have a technical (specifically coding) background. I can’t imagine a former coder who doesn’t have some interest in what technology is being used.
The situation clear?
So why is it important?
Lets point out: I’m not for one minute claiming the manager, or requirements analysts etc., need to be able use these technologies. An appreciation of the technology can be useful, and if they can code they might be able to help, but, too much knowledge can be dangerous. It can lead to the non-coder trying to second guess the coder and tell them in too much detail what they need to do.
I once managed a C# team: as a former C++ and Java coder I could understand and join in the conversations but if I ever felt the urge to reach for the keyboard or tell them how to do their job I knew I would make a fool of myself.
The first reason I think management types should know the technology is exactly as I’ve said above: it shows they understand what is going on. One of the big problems faced today is disconnected managers. This is the reverse of micro-managing, this is what Professor Henry Mintzberg calls macro-leading: ‘people in senior position who try to manage by remote control, disconnected from everything except “the big picture”.’ (Simply Managing, 2013)
That is what I was getting at in my original tweet. If managers don’t know what technology is being used they they are simply too disconnected to be able to manage it. But I will go further….
The second reason is I think management types absolutely do need to understand programming and technology if they are to manage such efforts. I’m fond of saying: “In software development work the devil is in the detail.”
If managers don’t understand the nature of the coding process I don’t think they can manage it. And if they have never coded I find it hard to understand how they will know the nature of coding work.
If managers don’t understand how software is developed – in the real world – then they will impose models of development and management which undermine the work.
If managers don’t appreciate the difficulties that can arise in software development then they will not be in a position to use their authority to help the technical staff. Indeed they may have problems even talking to their technical staff if they are lack knowledge.
I don’t believe “if you can manage you can manage anything” – it is a lie. Such advice is a recipe for the kind of mis-management we see all too often in the IT world. The fact is: if you are developing technology you need to get your hands dirty with technology. I’ve long been guided by the words of Fred Brooks:
“In many ways, managing a large computer programming project is like managing any other large undertaking – in more ways than most programmers believe. But in many other ways it is different – in more ways than most professional managers expect.” (Brooks, 1975)
(Indeed I chose these words to open Xanpan 2: The Means of Production.)
When I studied management I found much of the advice and good practices were highly applicable to software development. Indeed my Masters dissertation is an examination of how some management ideas map directly into Agile software development. (And yes, that dissertation opens with the same words from Brooks, “Software Development as Organizational Learning” is available to download and formed the beginnings of “Changing Software Development: Learning to be Agile”.)
There is a lot of good management practice and advice out there that many people inside IT and software development would benefit from knowing. But asking a generalist manager to manage a software development effort (always a complex effort) is going to result in problems.
Let me quote again from Henry Mintzberg:
“Managers deal with the messy stuff – the intractable problems, the complicated problems. … put together a good deal of craft along with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context.” (Simply Managing, Henry Mintzberg, 2013)
If you are managing a software development team I do not see how you can have the requisite experience and context if you have not programmed yourself. Managing does not exist in a context of its own, all management is rooted in the thing being managed.
| Reference: | How much does your manager need to know? from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
