Should IT Managers code?
-
It's actually a good question[^]. If managers doesn't what his/her underlings create, does that make them a worse manager?
Wrong is evil and must be defeated. - Jeff Ello[^]
One of the best bosses I worked for was a developer who got promoted to VP of Engineering and no longer had time to do what needed doing. Another good boss I had had become Director of IT and only had time to work on the UI. I worked on everything else. But it seems that to a great extent, that article applies mainly to small teams, where the loss of one developer is a high percentage of the force. For larger teams, it seems less critical that the manager be able to code, but ease of bringing new members in is still important.
This space intentionally left blank.
-
It's actually a good question[^]. If managers doesn't what his/her underlings create, does that make them a worse manager?
Wrong is evil and must be defeated. - Jeff Ello[^]
I'm just changing my job role from developer to a more management-y position atm; one of things I'm really happy about with my new employer is that it's mandatory for me to maintain my development skills. For me, I don't think that management need to be writing 'production' code as a matter of course - but they need to be capable of doing it [competently], and able to function at that level. Learning a new skillset doesn't mean abandoning old ones!
-- What's a signature?
-
It's actually a good question[^]. If managers doesn't what his/her underlings create, does that make them a worse manager?
Wrong is evil and must be defeated. - Jeff Ello[^]
Define IT. IT in inside parlance, is typically not engineering, but handling the company infrastructure, in which case, the best I've worked with can code scripts and that's about it. They could, however, make VMWare and routers proverbially dance and sing. I believe Engineering managers should have done some engineering, though simply respecting engineering may be good enough for a rare individual. The best manager I've ever had by magnitudes was a former hardware engineer. The second best I had couldn't write code if his life depended on it, but could close sales like no tomorrow and the customers loved him. The third best was a working software engineer who spent most of his time coding, but he was a rare creature. ALL respected engineering and the time it takes, could quickly grasp the core of issues and, most importantly, enabled us engineers to do our jobs and shielded us from the bullshit of upper management. (Thinking more about this, I believe the qualities that make a good manager and a good developer are different. Great managers not only need to see the big picture, but need to know how to handle people. They need to know how to digest information given them and be able to distinguish priorities. Most importantly, they need to have a really good BS meter. I've worked with few engineers, and even fewer brilliant engineers, who show these qualities. On the flip side, the one common trait amongst the terrible management I've had is that they didn't respect the engineering process. In general, they thought that simply demanding results was sufficient.)
-
I'm just changing my job role from developer to a more management-y position atm; one of things I'm really happy about with my new employer is that it's mandatory for me to maintain my development skills. For me, I don't think that management need to be writing 'production' code as a matter of course - but they need to be capable of doing it [competently], and able to function at that level. Learning a new skillset doesn't mean abandoning old ones!
-- What's a signature?
Good luck to you. I made the transition years ago, and I still code and manage. I cannot imagine managing developers without understanding the process, the people, the style. Although I have to recommend learning about management, like you do a language. You need to determine your management style, and approach to handle your team. I still like the "One Minute Manager" book. It shaped me when I was young, and just after having had a terrible Software Development Manager. You know, the one that teaches you what you WILL NEVER Do if you ever manage people!
-
Good luck to you. I made the transition years ago, and I still code and manage. I cannot imagine managing developers without understanding the process, the people, the style. Although I have to recommend learning about management, like you do a language. You need to determine your management style, and approach to handle your team. I still like the "One Minute Manager" book. It shaped me when I was young, and just after having had a terrible Software Development Manager. You know, the one that teaches you what you WILL NEVER Do if you ever manage people!
Thanks for the advice, that's very useful :)
-- What's a signature?
-
It's actually a good question[^]. If managers doesn't what his/her underlings create, does that make them a worse manager?
Wrong is evil and must be defeated. - Jeff Ello[^]
I think the size of the group is the determining factor. I manage a software development group that has 25 members. I started as a hardware guy, became a programmer and eventually moved to management. Being a good programmer will no longer advance my career. But being a better programmer and having new programming opportunities are essential to the careers of the other members of the group. Every time I code, make architectural or design decisions I am taking opportunities away from my staff. I have to trust that they will make the correct decision and will not be afraid to say they made a mistake and correct it. If experience shows me that I cannot trust their decisions then I need to remove them from the group. Sometimes it is like teaching your teenage child to drive. Very scary. But when you get good programmers who are not afraid to make decisions and implement them when and where they need to be made the results can be magical.
-
It's actually a good question[^]. If managers doesn't what his/her underlings create, does that make them a worse manager?
Wrong is evil and must be defeated. - Jeff Ello[^]
My Former Bitch Supervisor From Helltm was a prime example of promotion to get her out of the way. However her lack of understanding practices and principles was a continual drag on our productivity. When I temporarily took over her position during her leave of absence we kicked ass and took names. I viewed myself as a facilitator to give everyone what they needed and as a load leveler. We set up a weekly cycle of Monday thru Thursday to do bug fixes with Friday spent preparing documentation while the dedicated compiling machine produced the next image. Monday morning we'd present the package to QA and continue work. Towards the end, the QA department was begging us to slow down, they couldn't keep up with testing of the scripts we gave them and their regression testing. Unfortunately I didn't have any time to program. My current position as manager has me programming and until some of my new hires I found myself teaching the staff as well. We had one guy who used to snow his previous manager by defending his poor code with the phrase, "...unless you know a better way..." Unfortunately for him, I did. He eventually came around and still used the same phrase, but this time he was looking for help. I don't limit my staff to what I know like my Former Bitch Supervisor From Helltm did, but I at least try to get rational explanations of how the code works from them. One former worker used to give status reports that had me sniffing the air and wondering if it was bullshit I was smelling. I think I succeeded in not smiling when he gave me his resignation. He had worked on a project for over a year without producing anything under the previous manager because the manager couldn't smell what I did.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
It's actually a good question[^]. If managers doesn't what his/her underlings create, does that make them a worse manager?
Wrong is evil and must be defeated. - Jeff Ello[^]
IMHO, managers got promoted because they could NOT code, did NOT want to code, or for some other similar reason -- why is it necessary? If you follow some kind of Agile/Scrum development model, why not make the manager the "product owner" if they need to feel more involved and part of the team? There is a reason for "division of labor" even in software development. :cool:
David
-
IMHO, managers got promoted because they could NOT code, did NOT want to code, or for some other similar reason -- why is it necessary? If you follow some kind of Agile/Scrum development model, why not make the manager the "product owner" if they need to feel more involved and part of the team? There is a reason for "division of labor" even in software development. :cool:
David
I believe you're referring to the Dilbert principle[^]
Wrong is evil and must be defeated. - Jeff Ello[^]
-
It's actually a good question[^]. If managers doesn't what his/her underlings create, does that make them a worse manager?
Wrong is evil and must be defeated. - Jeff Ello[^]
My best manager did not know how to code at all. He discussed target dates and requirements with me before committing to anything, then let me manage my own development process. My worst managers knew how to code once to some degree, but did not keep up with current development processes or capabilities with our systems, so often made unreasonable demands and "standards" that they would not budge on, because they thought that they understood things that they really didn't understand. In spite of my experience though, I would like a manager who understood what I was talking about, but flexible enough to see that things change and that it would be best to adapt.
-
I believe you're referring to the Dilbert principle[^]
Wrong is evil and must be defeated. - Jeff Ello[^]
-
It's actually a good question[^]. If managers doesn't what his/her underlings create, does that make them a worse manager?
Wrong is evil and must be defeated. - Jeff Ello[^]
Whenever possible why not code, but the manager side of the role has to come first. By this I mean that if someone in the team has a problem or a question, you have to deal with that first, because by resolving that problem you are freeing them up to do their work. And that is where the difficulty lies, because if as a manager you are working on a critical coding task, you have to leave that to deal with the problem or questions or help that is needed by team members. I therefore find it best when I am working on non critical coding tasks that are of lower priority of that than team members are working on. This way I keep my coding skills up to date and am able to put the coding task on hold when a team member needs help.