Slashdot Mirror
Do Non-Technical Managers Add Value?
New submitter Kimomaru writes "Ars Technica asks, 'How does a non-technical manager add value to a team of self-motivated software developers?' IT Managers have come some way in the past decade (for some). Often derided as being, at best, unnecessary and, at worst, a complete waste of budgetary resources, managers in technology today can add significant value by shielding developers and systems engineers from political nonsense and red tape. From the article: 'Don't underestimate the amount of interaction your manager does with other departments. They handle budgets, training plans, HR paperwork. They protect the developers from getting sucked into meetings with other departments and provide a unified front for your group.'" Has that been your experience?
Project managers come in two flavors:
Those who put check-marks next to items on SOWs, and those who can bring people of dissimilar skill-sets together to complete a complex project.
Those in the former should be shot.
Those in the later should be praised.
I think the problem is the same most IT professionals find about their own job. When you have a good manager, they are almost invisible and you don't realize what is going on behind the scenes. When they are a problem, then you notice and complain. It's how most of the other departments in a company see IT. Completely ignore them unless something is wrong, and then complain about them.
I will shred my adversaries. Pull their eyes out just enough to turn them towards their mewing, mutilated faces. Illyria
A good manager deals with the paperwork of requisitions, financing, and getting "buy in" from "customer" departments and management.
A good manager makes sure your projects have visibility, and that their successes and ROI are broadcast through the company so your department doesn't end up downsized.
Having technical knowledge is good for a manager to understand what their team is doing and what they're saying in meetings, but "technical knowledge" is not and never has been what the manager's job is about. A good manager doesn't need to understand the details, because they're not micro-managing their staff.
I do not fail; I succeed at finding out what does not work.
TPS reports / middle man / just reading a script (getting in the way of one team talking to an other team) / micro managing people even when they are waiting for some other team to do there part so you can do you next step.
Two of the best bosses I've ever had could be described as "non-technical managers". They made sure I had what I needed to get my work done, they were very clear about the objectives, and they kept the rest of the organization from distracting our team.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
My current non-technical manager is my first stop when I need corporate permission to do something, or if I need a resource that isn't directly given to me. He manages most of the non-technical aspects of being employed here, so I can do my job without wasting my own time on the paperwork.
Since I'm currently working in a very large company, it's very valuable to have someone who knows and understands the full layout of the corporate hierarchy, and has the rapport with all the "friends in high places" to call immediately and get things done.
You do not have a moral or legal right to do absolutely anything you want.
Managers that know nothing of programming, may have extensive industry experience.
But a truly 'non-technical' manager brings nothing but lack of understanding to the the table. What use is a TPS report reader?
Again though; Project management is a skill. Someone with no programming knowledge can still recognize when something is on critical path. Having no programming knowledge they might be tempted to split the critical path workload by assigning some of it to an air thief.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
"shielding developers and systems engineers from political nonsense and red tape"
Yup, plus shielding users and clients from those of us whose interpersonal skills aren't as great as we think they are.
Sometimes, though, this same role can be filled by a Team Leader who actually does have great people skills.
ObAnecdote: I had a coworker and friend who was a great developer but who always managed to get people mad at him. He was so oblivious to this fact that he'd occasionally comment about how well he got along with users and customers. One day, he came in laughing about the previous night's Big Bang Theory, telling us how clueless Sheldon was because he pissed everyone off and had no idea he was doing it. Yeah, he was that oblivious. And our manager protected many users from him.
You ever duck your head down, put the earphones on, and cut a swath through the feature list, barely realizing that you've missed lunch and it's already 7pm? You'd leave but you've just thought of a really elegant optimization routine and it's so obvious, but you need to see it work before you go?
A good manager can provide coordination between project members, act as an insulating buffer between customers/requirements and devs, fight for resources, push back against poor requests and push forward agendas like refactoring, internal tool development, or library updates (ie, the Good Fight). Really though, this boils down to the simple goal of letting the devs do their job.
Without all the other context switching, we're free to descend into code mode, shut out the outside world, and make beautiful code that we're proud of. In practical terms, that means less bugs, better security, efficient code, lower cost of maintenance, and so on. That's the biggest thing a manager can really provide; an environment where we're free to excel.
That doesn't require any sort of technical chops.
I made the jump from developer to team lead and now on to management. Good management is very very hard, keeping people on task, motivated, and managing burn out is really more of an art than science and I'm not even including dealing with different personality strengths/weaknesses and the various combinations thereof.
If you have a good manager or even just a not-bad manager let them know. It's a difficult position to do well and lots of folks who you respect see you as worthless.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
At IBM, the manager's job is to figure out a way to keep their developers from being laid off, or to aid in that process. The employees are pitted against each other, so that instead of working as a team, they work to keep their job over their teammate. The manager has to divide the group into 3 levels of "performance" where the bottom tier is in danger of going on "a plan." If a manager likes his/her whole team, they rotate everyone in and out of the bottom tier. If there is someone they don't think is performing well, instead of realizing it's probably due to their poor management skills and the toxic environment of pitting employees against one another, they flounder about instead of finding work that would interest the person and end up having to let them go.
So, to sum it up, at IBM you don't need management or technical skills to be a manager, as neither skill is used.
I think the most important work for a manager is to :
a) Find, Recognize and Hire talented people.
b) Make sure that the talented people figure out how to work together.
c) Improve and optimize the processes and the organisation ( continuously and in small steps.)
d) Arbitrate discussions and help making decisions, but do not take them on your own
e) Especially in larger organisations, evangelise about skills and every good thing that has been done by your teams.
f) Have an eye on the horizon now and then. Engage the teams in strategic discussions and long term planning.
To do these things well a deep knowledge about software development is required. ( Or about teaching, or medicine, or whatever it is the organisation is doing.)
It's not possible to get this sort of insight without having practiced the trade for some time. Yes, it possible to manage without, but then there is a high risk that things go wrong in some - and then maybe all - of the above areas, simply because it is easy to misunderstand some things and fail to recognise others.
Another risk is that the important things are replaced with less important things:
v) Make sure that everyone is aware of deadlines, project plans, priorities. ...or even : Handle and approve vacation requests
x) Order stuff that is needed.
y) Make budgets, and report progress.
z)
Sure, these things must be done, but it isn't exactly rocket science and everyone and their dog is capable of handling these tasks.
Less knowledgeable managers and project managers tend to focus a lot on status reports and reminding of deadlines,
sadly adding about as much value as an automated mail could have done (I'm looking at YOU tick-box-guys) while missing the important stuff.
One problem with non-technical managers is that they may 'accidentally' accept unfortunate (technological) decisions made outside the team without challenging them, or even worse make their own, perhaps because they fail to see the implications. They will then end up defending senseless decisions or policies against the team, generally having to revert to "just because" arguments, and since the decision may not be easy to back from once committed, everyone involved will become angry or whiny and the team will become generally obstructive and unhappy.