Can a Manager Be a Techie and Survive?

theodp writes "Some say that good managers should not be technical at all. Over at Computerworld, 'C.J. Kelly' takes a contrarian position, arguing that managers should keep their hands on the technology. The ability to tell the difference between fiction and reality, says Kelly, is priceless." From the article: "If you don't know the difference between fiction and reality, you've got a problem. By being technically informed while managing people and projects, no one can blow smoke up my skirt. I can tell the difference between a lame excuse for a delay and a legitimate reason why something can't be done." Where do you fall on this issue? Is it nice to be able to flim-flam the boss once in a while? Or is the valuable input of a boss with a technical background worth the occasional all-nighter?

Comments

It depends on your perspective

[Amehcs]

Of course it's "nice to be able to flim-flam the boss once in a while," but that doesn't make them a good manager. I'm sure that the their boss wouldn't see it that way if they knew what was going down.

Re:It depends on your perspective

[iocat]

Good managers should be able to tell when they're being flim-flammed, regardless of their technical expertise, by the way their team responds to them. That said, they should also be able to suss out when they should let something go, because they're being flim-flammed for a reason (such as: the original request was retarded, and it's easier to flim-flam than actually implement something dumb, or some other reason).

Not at all saying I'm a good manager, but I once asked someone to do something, and they explained to me very earnestly that it couldn't be done until some other guy did something (and that guy was gone for the weekend). Since "other guy" was way more junior, and this guy was very talented and generally very eager to tackle any task, I knew something was up, and it was -- his girlfriend was coming in from out of town about 20 minutes later and he wanted to get out of Dodge. That was when he was new (now he'd be like "dude, gf coming to town, can't do it now") but it does illustrate the scenario I'm presenting.

On the larger issue, I always like it when my managers have at least a vague clue about what I'm talking about. They don't need to know details, but they should get the general idea of what we do and how we do it.

Re:It depends on your perspective

[ray-auch]

Say what ? You hire techies who have girlfriends ?

Why ? Why take the productivity hit when there's such a massive pool of talented geek labour* that is never going to have this problem ?

*large parts of it reading right here...

Re:Obviously, Yes!

[brad-x]

I've been here. My experience is the same - when a manager is technically minded, he or she involves himself far too deeply in the details of projects they should simply be overseeing.

Sometimes, in the case of managers with particularly stunted emotional makeup, you'll find them attempting to use their managerial position to prove themselves as technical geniuses, to the detriment of the people on their team.

While it may be beneficial in theory to have a technically savvy manager, in practice it's very dependent on the person. Most tech people don't have the emotional makeup required to successfully manage.

The boss shouldn't do the coding.

[khasim]

A little bit of a problem there: the microsecond the boss lifts his hand to actually perform any technical task, the rest of the management team classifies him with the toilet-cleaner and never listens to him seriously again.

The manager should be sufficiently aware of the organization's culture to know that ahead of time.

It isn't necessary for him to do any of the actual coding. But he needs to be able to explain to the other managers why, with the current people / money / time / equipment / deadlines / other projects, the IT team will not be able to hit the deadline of the new project.

Then it gets into negotiating with the other managers for more people / money / equipment ... or pushing out other deadlines ... or dropping requirements (for the new project or existing projects) ... or re-prioritizing the projects ...

The manager's job is to understand the business and the technology sufficiently well that he is able to communicate the business's IT requirements to the coders and provide them with the resources necessary to achieve those requirements in the time allocated.

It's a simple definition, but it's been useful for me. It also allows you to see where the "bad" managers have problems.

#1. They don't understand the business and the team gets stress for delivering tech that isn't appropriate.

#2. They don't understand the tech and over-promise what can be delivered.

#3. They don't understand the business or the tech.

#4. They don't communicate the requirements to the coders.

#5. They don't provide the resources the coders need.

etc.

It's difficult to fail if your manager is competent at each of those steps. But not impossible. There can still be personal issues that cause conflicts/problems.

But the chance of failure goes up dramatically with each step that the manager fails.

Re:Obviously, Yes!

[griffjon]

I've been nodding my head to almost every contradictory post so far, and that means there's something more here. I think it's obvious that you can have a good manager who's clueless at tech, or a horrible manager who stays afterhours to rebuild his kernel. I'll take a manager who matches my in brains with whom I can establish a mutually-trusting relationship, regardless of their area of expertise, any day. I should be able to explain my problems and such to someone that smart, and our trust and relationship should let us both fudge a bit on whatever side we feel needs to be fudged, with tacit and/or even explicit knowledge of the other. Most importantly, I want an advocate who can and will go to bat for me at the managerial/executive/funding agency levels. Now, it's nice if I don't have to show them how to do column-sums in Excel, but not necessary.