Do Non-Technical Managers Add Value? 249
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?
Valuable source of proteins but especially lipids (Score:5, Funny)
Two Flavors (Score:5, Insightful)
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.
Re:Two Flavors (Score:5, Insightful)
Even without acting as a bridge to external people, simply having an educate but non-technical resource on hand is useful.
If you can't explain your project to your manager in terms they can understand, you have no hope of explaining it to the end-users, upper management, budget committees, etc. If your non-technical manager sees through your bullshit, its your clue you are doing it wrong.
Just as the act of merely explaining a problem to another programmer will often yield insight into the solution (without the other programmer saying a single word, or perhaps paying all that much attention), explaining stuff to a non-technical manager often helps with the design and implementation. The questions they ask will also be asked by others.
Re:Two Flavors (Score:5, Insightful)
I have to agree with both you and the GP.
A good manager without a technical background can be a boon simply because it forces you to examine the project from another angle, and can thus increase the likelihood of spotting pitfalls etc.
Also, in terms of skills and abilities, there's a skill and a personal knack good managers have that is WAY more important technical skill: The understanding of logistics and planning ahead. Especially since it's a trait many developers themselves lack.
Working as a freelancer, in many projects I have to do the logistics, time management, all the paperwork etc myself, which is quite complicated, and makes me value managers even more. It's often a thankless task even when the manager is good but events are beyond their control(Such as "I ordered that shipment a month ago, it arrived in-country a week ago, but it's still stuck in customs...").
Re: (Score:3, Insightful)
Where oh where are my mod points.
In the end it is all about communication. A person who makes communication easier is an asset to any project. If they are called a manager, whatever. I know I will listen to colleagues as they discuss their issues, and watch the light bulb moments as people answer their own questions by listening to themselves.
A good manager will run interference for the team and make sure they are supplied with what they need to get the task done.
Re:Two Flavors (Score:4, Insightful)
In the end it is all about communication. A person who makes communication easier is an asset to any project. If they are called a manager, whatever.
Yeah - usually these people are called "project managers" - and they generally manage the project rather than the people. Though hopefully they are at least technically conversant, if not technically trained. It's hard to explain how useful a project manager can really be to a project until you actually work with someone truly competent in the role (because that seems to be a minority of the project managers out there - at least in my experience - so there are probably many more developers who have had only bad experiences).
If your *personnel* manager is non-technical, on the other hand, then good luck on your reviews and career advancement, as it's just going to be a crap shoot as they make shit up...
Re: (Score:3, Interesting)
Think your problem mate
Is futile's one syllable
Though your point still stands
Re: (Score:3)
Even without acting as a bridge to external people, simply having an educate but non-technical resource on hand is useful.
If you can't explain your project to your manager in terms they can understand, you have no hope of explaining it to the end-users, upper management, budget committees, etc.
This is 10x as true if you're doing UI design/implementation (which is why I still get a laugh out of whoever let Windows 8.x through...)
Re: (Score:2)
It's not just that. Us technical people have a tendency to see a technical solution to every problem. It's just another aspect of the old saying "when all you have is a hammer, every problem looks like a nail".
More often then not, purely technical, and even mostly technical solution is a bad one. This is where non-technical manager comes in. If he's good at his work, he'll be able to provide non-technical insights that will benefit the team greatly by pointing out solutions that are obvious to him, but may
Re:Two Flavors (Score:5, Interesting)
Even without acting as a bridge to external people, simply having an educate but non-technical resource on hand is useful.
If you can't explain your project to your manager in terms they can understand, you have no hope of explaining it to the end-users, upper management, budget committees, etc. If your non-technical manager sees through your bullshit, its your clue you are doing it wrong.
Just as the act of merely explaining a problem to another programmer will often yield insight into the solution (without the other programmer saying a single word, or perhaps paying all that much attention), explaining stuff to a non-technical manager often helps with the design and implementation. The questions they ask will also be asked by others.
I agree with what you say, but the problem is giving this person authority over the group. You could have such a person who is within the group but not over it. My wife actually fulfills that role for me in my business, with a couple of select customers filling in if other knowledge is required that she doesn't have.
In my only actual "job" I had a non-technical manager who was good for most of the reasons that you say, but her cluelessness seriously held our group back in various ways. Her inability to understand at any level what we did and what a reasonable way to do it would be caused endless frustration. The "interfacing with other groups" and all that didn't work as she was too clueless and the rest of us had to carry on that responsibility. We were the internal IT department for an IT department within a larger organization, so all of these problems were amplified as the rest of the department was a bunch of nerds, also.
On the other hand, she did take time to teach me how to write project proposals and stuff like that in which she excelled. However, that means that in the end I had acquired her extremely limited skill set myself and added it to my otherwise very marketable skill set in programming, which made her of even *less* value to our team.
In case you think I'm pissed because I got burned, quite the opposite. She fought for me like nobody and even mentioned when I quit that my pay increase (as a percentage) during my time there was the highest in our department. I liked her as a person and think that she would have been highly effective in the right job. She had the motivation, was physically attractive (say what you want - it matters), and intelligence to be great at a lot of things. Tech just wasn't one of them.
Re: (Score:2)
In large corporations, a large function of managers is to be a "Bullshit Barrier", and when it's not done well you notice right away.
Re: (Score:2)
I think most of the replies to my post said this, and I agree.
I'm your basic guy who sits in a cube and produces technical solutions. Above me, I've got a manager and a PM. Since I'm not solely a task worker, they have, for the most part, assigned me the scope of what needs done, and I return to them where I am in that body of work. I work with them in prioritizing objects in that scope, and they, in turn, act as a communications conduit to The Powers That Be around here, apprising them of my team's stat
Re:Two Flavors (Score:5, Insightful)
However, I also believe that management at every level is at least as obligated to the people lower on the reporting hierarchy as they are to him/her, so I might be in the minority in saying that your internal customers include people who report to you.
Re: (Score:3)
He's above me in the way that a 1st Lieutenant is above a Master Sergeant. :)
We work together, but I owe him dates and deliverables. He "owes" me the job of getting me the resources I need to do my technical job.
Re: (Score:3)
If you're doing actual work, you're on the bottom of the corporate hierarchy. The only thing that's really valued is the ability to lead. If you're not leading anyone else, you may be a highly-paid interchangeable worker bee, but you're still an interchangable worker bee.
Re:Two Flavors (Score:4, Insightful)
If you're doing actual work, you're on the bottom of the corporate hierarchy. The only thing that's really valued is the ability to lead.
Not entirely true - at least not where I work (a giant, soulless telecom megacorporation). On the non-technical side (where I work), yes, you need to become a manager of more and more people to progress "up the ladder" in terms of pay and perks. But in our technical organization, it's well recognized that there are people who have increasingly valuable skills and insight who have no interest in management (or, frankly, should not be allowed within 100 feet of managing others). There is a whole separate track of Individual Contributor titles on our technical teams (lead architect, principal member of technical staff, distinguished member of technical staff, etc.) which run "parallel" to management titles and allows technical staff to progress in pay and perks while not technically being managers of other employees. It seems to work out well for everyone involved.
Acronym abuse (Score:5, Funny)
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 assume you mean the first item on this list?
Seriously, I'm getting sick of having to look up acronyms every five minutes. Why can't people just spell out WTF they're talking about these days? SMH.
Re: (Score:2)
Proper grammar used to hold that the first time something is referenced, it should always be spelled out, but is OK to abbreviate from that point forward.
Problem is, a lot of people seem to take that statement, "the first time something is referenced," to mean the first time ever.
SIG (So It Goes).
Re:Acronym abuse (Score:4, Funny)
What acronym? I was referring to adult female hogs, and got the caps key stuck.
Re: (Score:2)
Those who put check-marks next to items on SOWs
I assume you mean the first item on this list?
At least the use of upper case let you assume that the items in question aren't attached on the backs of female swine.
Re: (Score:2)
Just like the "TPS reports" in Office Space, it doesn't really matter what the TLA actually stands for. Just from the context, you can infer enough about it to understand the point.
Re: (Score:2)
Managers (Score:5, Insightful)
Re:Managers (Score:5, Interesting)
Before retiring I was an IT manager. I can tell you my presence was a great benefit to my employees. In addition to isolating them from all the politics and idiotic suggestions from other department heads, I also was a mentor. My staff had varying skill levels and I worked with each one to help them improve their skill set. I also prevented those less qualified from being assigned tasks better handled by someone else.
In addition, I fought the rest of upper management to make my staff's working environment enjoyable. No overtime when I was there. I knew enough to know that overtime is, generally speaking, non-productive when forced, and forced often.
I also instituted incentive plans for those of my staff that tried hard. They didn't have to be superstars, they just had to try to improve themselves. And my staff loved me. All our software was developed in house and we did a major conversion on one of the pieces, probably the most important piece in the chain. We did it on time, minimal roll out issues and no overtime. And everyone had fun along the way.
Problem was, the owners couldn't see the benefit I was bringing to them. Most projects like that are late, over budget and don't work right out of the gate. They fired me :)
Wonder how they like things now?
Re: (Score:2)
In addition, I fought the rest of upper management to make my staff's working environment enjoyable. No overtime when I was there. I knew enough to know that overtime is, generally speaking, non-productive when forced, and forced often.
I also instituted incentive plans for those of my staff that tried hard. They didn't have to be superstars, they just had to try to improve themselves. And my staff loved me. All our software was developed in house and we did a major conversion on one of the pieces, probably the most important piece in the chain. We did it on time, minimal roll out issues and no overtime. And everyone had fun along the way.
This is pretty close to the ideal I aspire to as a manager. And it's not that hard, if you keep your priorities straight.
On the other hand, sometimes you end up fighting with management for these things, and a certain percentage of the time, you lose (your job).
Re: (Score:3)
new manager here - interested in what you're saying, thanks.
I'm confused though - you say that you had good support from your staff, you completed projects on time with no overtime etc. How come you got fired??
I'm also interested in knowing more about the incentive plans you used. Can you elaborate? Thanks!
Re: (Score:2)
Did all your office tech equipment work today?
Your Welcome, IT dept.
Re: (Score:3)
s/Your/You're/
Re: (Score:2)
s/Your/You're/
FAIL.
Re: (Score:2)
Re: (Score:3)
What I learned over my lifetime is this:
A good manager does:
1) Define clear objectives (what to achieve);
2) Define a "strategy" (how-to in general terms) to achieve it;
3) Create the right team with the right, complimentary skill-sets to reach the objectives;
4) Provide all the resources needed to the team so they can achieve the objectives;
and the most important:
5) Clear the path for the team to run towards the objective - on an ongoing basis - so that the team doesn't need to bother with anything like polit
Re: (Score:3)
While I agree with you that your 5 points define one type of good manager, I disagree with your last sentence. For items 1-3 (like defining a "how to" or understanding different technical skill-sets), it is usually important that the manager HAS at least some technical background.
But a missing technical background is no problem if the manager in question is aware of it and instead accepts (technical) input from the team.
Re:Managers (Score:5, Interesting)
When you have a good manager, they are almost invisible and you don't realize what is going on behind the scenes
This is so, so true. At some point in my career, I was working for a large vendor's Advanced TAC. I had a manager who occasionally would come up to my desk with some hot escalation which needed immediate attention. I was wondering what he was doing all day.
Then came the day that he left. He got the Silicon Valley escort out of the building right after his resignation, and I got a temporary manager. All hell broke loose. That's when I realized the true value of my former manager: he was shielding his precious TAC engineers from unnecessary political escalations and made sure that we only got cases which needed our attention, and made sure we actually have some time to analyze the case before coming to a preliminary conclusion. My workload tripled.
I have also been on the other side of that coin. Not so long ago, I was working as a team lead for another large vendor, on a project for a new product. I had a couple of engineers in my team and they would sometimes jokingly ask what I was doing all day. Coming in at 11am, delegating a bunch of tasks and leaving at 4pm. What they did not see is that I worked at home from 8am until 10:30am, and usually until late at night. When I left, I spoke my best engineer a few weeks later. He confessed that he sometimes thought that I was a slacker, but that he now got my workload and was suffering badly. Best compliment I've ever had.
Re: (Score:2)
Agreed. I'm not a developer but work in I.T. on the support and sysadmin side of things, and this is pretty much the case. The best way to avoid the problem of being "almost invisible" (whether you're I.T. staff or an I.T. manager) is regular communications. The fact that our I.T. manager has a weekly video conference meeting with all of us for an hour or more, once a week, really helps remind everyone what's going on beyond our day to day challenges and keeps everyone working as more of a unit. (Despite t
Re: (Score:3)
No (Score:2, Interesting)
No, it has been the opposite. They come out of these meetings, not knowing what they have agreed to. They cannot translate what the developers need, and what the business needs either. They end up being a man-in-the middle mess of Chinese whispers.
Re:No (Score:5, Informative)
Depends on the manager. I had one recently (re-org. He's still around but I don't report to him anymore) who was excellent at exactly what the summary stated: shielding us from red tape and political BS. He was mildly technical - he could code if he had to, but it wasn't his strength, and (this is probably what made him good) *he knew it*. He would do requirements gathering, secure resources when necessary, and stay out of the way on technical stuff. He'd also take my estimates and grossly inflate them, which generally made them more accurate. Good managers exist, but it's an odd niche sometimes. If we swapped jobs, we'd probably both be much worse at it.
A good manager deals with the paperwork (Score:5, Insightful)
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.
Re: (Score:3)
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.
But at the same time they need to understand the skillset of each team member just enough to know who to bring with them to a meeting with the client. Never, EVER let a non-technical manager go discuss product features with the client without any qualified developers/designers around.
Re: (Score:3)
I understand the point you are trying to make but I've also had plenty of managers who did not understand what the team was doing and as a result agreed and committed to projects that were completely outside the scope of possibility. Since those same managers tend to have achieved their level in spite of their competence not because of it the whole thing turns into a finger-pointing game where the manager is trying to find who to blame for the managers over-commitment.
Re: (Score:2)
But that's not a good manager.
A good manager gets input from their team before making commitments.
Re: (Score:3)
I know a guy, Mr. M, who's a retired computer programming project manager. One of his proudest accomplishments is keeping the rest of company A away from two of his employees, Messrs K&R, who were developing a project, U, which went on to become a foundational technology for the Internet.
So, yeah, it can happen.
On the other hand, the average effective project manager (and not all are) adds a 10% productivity boost to a team of 9. And that's real data, look it up. Hierarchy's value has diminishing ret
TPS reports / middle man / just reading a script (Score:2, Insightful)
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.
Comment removed (Score:5, Insightful)
Re:I've had a few in my time. (Score:5, Interesting)
This. Rule number 1 for managers: have clear goals, and communicate them. Rule #2: make sure the team has what they need.
The best boss I ever had was an ex-Israeli commando officer. No, no, no, he wasn't a "do it or I kill you" manager. He was good because: 1) there was never, ever, any doubt in your mind whatsoever what he wanted accomplished. 2) When you told him what you needed to accomplish that, he either got it, or adjusted the goal. When you think about it, no good officer sends in a team of commandos with a fuzzy objective and poorly equipped. To do otherwise it to spend too much of your life writing unpleasant letters to parents.
I'm lucky that's been my experience (Score:2)
Re: (Score:2)
You could stick to the "gold" metaphor as they usually still get paid as they were golden but are as usefull as a golden life buoy.
If they're necessary, yes. (Score:2, Insightful)
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 cal
How non technical? (Score:4, Insightful)
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.
Re: (Score:3)
Your subject question was the first thing to pop into my mind. The best software development manager that I have had was a mathematics Ph.D., with very little programming experience. He was great in abstracting and explaining problems, and excellent in team and people skills.
An anecdote: He was given a guy who just wasn't good at programming. Instead of booting the guy out, he put the guy in charge of builds, verification, and regression testing. These were all things that nobody else wanted to do. T
Re: (Score:2)
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?
Sometimes, what a non-technical manager brings to the table is a lack of understanding. The biggest source of failure in software development, among other large IT projects, is consistent and almost institutionalized miscommunication between the producers of the project and its consumers. Most developers are not user-centric when it comes to thinking about the requirements of a software project, and most users are not sufficiently competent to request what they want with technical precision. So you have
Re: (Score:2)
What you describe is the 'industry experience' guy.
The problem with people who don't understand is that they rarely understand how much they don't understand. Nobody can know all the things they don't know, but should.
Good systems analysis skills often amount to playing real stupid with the customers. Make them explain in detail; do the job, for a day or an hour. Don't rush the process. Assume it will take you as long to understand the system as they normally take to train new staff to full competence.
Betteridge's Law of Headlines applies (Score:4, Funny)
The answer clearly is no
http://en.wikipedia.org/wiki/Betteridge's_law_of_headlines [wikipedia.org]
Does Betteridge's Law of Headlines apply here? (Score:3)
Non-technical managers are technical (Score:5, Interesting)
They're technical, but in another discipline: organizational management.
Unfortunately, most companies treat this as if it were not a discipline, which allows them to promote either (a) cronies or (b) droids who went through the project management courses that are short of an MBA.
Your "non-technical" managers specialize in planning projects, keeping people off your backs, and keeping you from falling into common developer pitfalls.
Keep them -- just insist on having good ones, so you have fewer of them.
Worked with all kinds (Score:2)
I've worked with managers that did nothing but get in everyone's way and make their subordinates' lives hell, and managers who were masters at building esprit de corps and getting their subordinates the resources they needed to do better work. So, they come in all flavors.
OP Has It (Score:5, Insightful)
"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.
No (Score:2, Informative)
Just ... no.
Best article I've seen on managing techies is here, http://www.computerworld.com/s/article/9137708/Opinion_The_unspoken_truth_about_managing_geeks?taxonomyId=14&pageNumber=1, but it takes another techie to recognize it.
Re: (Score:3)
And for those too lazy to copy & paste it, here's the link [computerworld.com].
Personally, I think it's spot-on, but I don't necessarily think that non-technical managers are a problem. If they know what their deficiencies are, and are willing to ask for help at the appropriate time, they might be just fine.
But I've also had 'technical' managers who were from different fields -- one only dealt with mainframes, and when our departments got merged, didn't understand that the unix team oversaw dozens of machines per person a
Law of headlines again (Score:2)
Easy wasn't it!
Good managers allow for code mode (Score:5, Insightful)
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.
Re: (Score:3)
If I'm your manager, I'm sending you home.
I want you to grow as a professional and as a person, not burn out. Letting you work excessive hours isn't helping you.
God forbid (Score:2)
Oh, please spare the developers from having any contact with the outside world. It's not like the clients or individuals in other departments ever discover any bugs or have anything relevant to say about design features or the future of the product.
Re: (Score:3)
Oh, please spare the developers from having any contact with the outside world. It's not like the clients or individuals in other departments ever discover any bugs or have anything relevant to say about design features or the future of the product.
That's a good point, but it can get ridiculous. One manager I worked for required a kaizan (with A3, presentation, followup, the whole works) from every individual employee once a month, on a new topic each time, on the theory that if he made continuous improvement a job requirement, he'd be able to show a huge amount of improvement in the department, and catch the eye of the higher ups. Problem was, after all the low hanging fruit were gone (which, admittedly, some really needed to be fixed) the requirem
not have tech people in meetings can be bad when (Score:2)
Where the mangers is answering questions when those questions need technical people to answer them.
Re: (Score:2)
Where the mangers is answering questions when those questions need technical people to answer them.
Agreed. Absolutely true. On the other paw, having development attend non-technical meetings are often a waste of the developers' time. One strategy that seems to work is to have the on-call developer attend all the management meetings, as his life is ruined for that week anyway.
Re: (Score:2)
A good non-technical manager recognizes situations where such questions may arise and:
1. Predicts such questions or gathers them from informal talks before the actual meeting, asks the team, makes sure that he/she understood the answer well enough by rephrasing it in front of someone from the team... and is ready to give a technical answer.
2. Is very good at delaying the answer to consult the team first and at recognizing situations where this is not enough and the person asking must be redirected to the ri
political nonsense (Score:2)
Isn't that actually generated by managers in the first place?
Sure they might shield developers from it, but if you got rid of them all, you wouldn't have it in the first place...
Re: (Score:3)
My experience is that most of the political crap comes from outside the technical organization. Sales. marketing, business development and all that shit.
A good manager will shield you from that. A bad one will add in his own political crap and dump the whole wad on the developers. In meetings scheduled at 7 PM.
What is needed is good managers. Bad ones are a waste of fucking skin plus they suck up precious offices with windows.
new respect for good managers (Score:5, Insightful)
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.
Re: (Score:2)
Where are the mod points when I need them?
Relatively flat management structure in my department puts me in a weird position - direct management of a relatively small team, but high enough on the chart to have to deal with a lot of high-level stuff. That means I get to do a lot of both technical and non-technical management stuff on several layers.
The technical management is very, very easy in comparison. If you have the right people, projects mostly do themselves, your job is just to steer them and solve de
Maybe, maybe not (Score:2)
It really depends on how good a manager they are (technical or not).
A good manager (as others have alluded to) is there to make sure their employees are able to get their work done. If that means doing back-end stuff to make sure they get the equipment/staff/priorities to meet the deadline, then that's the job of the manager and it doesn't matter if they've never written a line of code.
Yes, a technical manager can understand the lingo and be of use. Then again, people who are technical and became managers
Re:Maybe, maybe not (Score:4, Insightful)
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.
Depends, obviously (Score:3)
Management is inherently interrupt-driven: phone calls, meetings, other interactions with the organization
Development is generally NOT interrupt-driven; in fact each interruption has a productivity cost. You want your developers 'in the zone' as much as possible. A phone call, a question, a meeting, not only take time in and of themselves, but in the time it takes for the developer to get back in the zone, which could be much longer than the "quick" question you just interrupted them with.
A good manager (technical or otherwise) keeps interruptions away from their developers as much as possible, A non-technical manager MAY be at a disadvantage, if they cannot do their job without a technical 'guide dog'; but if the organization is structured in such a way that technical proficiency is not required (i.e. not expected to estimate tasks or understand or explain the internal workings of a particular subsystem), then they might be able to manage just fine.
So... depends. Duh.
Product Managers vs Worst Non-technical (Score:5, Interesting)
Salespeople
- To be good in sales, you have to be able to lie to yourself about the quality of a product, because the customer will not be able to believe it's a good product unless you believe it's a good product.
- To be good in sales, you have to be able to convince yourself that a customer has a need for something that they in actuality have no need for.
- To be good in sales, you have to have the belief that "the product is awesome because I am awesome."
- To be good in sales, you have to do anything you can to get a sale
- A good sales person can sell sand to arabs and ice to eskimos.
Product Managers
- To be a good product manager, you cannot lie to yourself that a product is superior.
- To be a good product manager, you have to design a product that people will really want and really need.
- To be a good product manager, you have to be able to say "I am only decent if the product is decent".
- To be a good product manager, you have to have to be willing to push back against a change that will harm the long-term usability or usefulness of a product for everyone else at the cost of getting a short term sale for one specific customer.
- To be a good product manager, you have to make sure your company won't be selling sand to arabs or ice to eskimos, but rather selling ice to arabs to cool their drinks and sand to eskimos to give their cars traction.
With the rare exception of someone like Steve Jobs who's good at both roles, promoting an outstanding salesperson to do product management is like hiring a convicted arsonist to run your fire department. .
Re: (Score:2)
I've seen it both ways (Score:2)
A really good non-technical manager serves to shield you from company management drama. Developers are allowed maximum practical development time because the manager is handling all the non-development stuff. A really bad non-technical manager acts as a conduit of bureaucracy. After awhile, all the developers are doing the manager's work, while the manager fulfills the function of finding more mindless procedures to heap on his direct reports.
I've worked for both kinds. Recently.
I should say, a technica
In my experience.. (Score:2)
I don't think it has to be this way, but unfortunately that's my personal experience. But really, that's just poor management and brown-nosing more than anything else, even a good non-technical manager should listen to his subordinates and make sma
Correlation does not imply causation (Score:3)
The best manager I ever had was non-technical.
The worst manager I ever had was non-technical.
The best manager was best, because she was a superb manager of people.
The worst manager was worst, because she was a crap manager of people.
My own experience (Score:2)
Speaking as one of those semi-technical managers (Score:2)
Seriously (Score:2)
Wow! What a genius! (Score:2)
ARS Technica asks, 'How does a non-technical manager add value to a team of self-motivated software developers?'
Ars Technica asks the rhetorical question, "what use are the non technical managers?", then finds the answer as, "they solve non technical problems". They might do further research and find that adding technical managers to projects will solve technical problems too!
Abstraction layer (Score:2)
What makes a good manager? (Score:2)
Bidirectionally, this means understanding (of the needs of each group) and communication (both listening and answering). To the outsider, this means understanding their issues and communicating meaningful replies in terms they understand. It means making appropriate requests and supporting the requests using concepts that the outsiders understand. To the insider, this means understanding their needs and be
Management is never Value Add (Score:2)
Good management is good for the organization. But, there is no customer that will pay more to a vendor because they have good management. Irrespective of what the inflated compensation packages of various members of management may suggest.
Short and complete answer: (Score:2)
Short and complete answer: Depends on the manager.
It's only bad if he thinks he can tell the developers how to do the technical part of their work.
Absolutely (Score:2)
Mythical Man Month (Score:3)
Of course, managers are of all quality levels, as are programmers. A bad manager slows things down, just as a bad programmer does.
She DOES come in handy... (Score:2)
Would you... (Score:2)
Would you put someone in charge of a legal department who was not a lawyer?
I'm guessing the answer in both cases would be no. These are specialist areas that require specialized knowledge to ensure that the organizations are working correctly and effectively. Information Technology is also a specialist area and should really be treated in the same mode as a finance or legal department. Leadership wit
Management is a myth (Score:3)
As far as a bunch of idiots all sitting around in cubicles, waiting for their daily instructions, yeah they need a manager. And for that, any manager will do, as long as the manager can understand the overall project, and is able to explain (each's part of it) to the ones doing the work.
Re: (Score:3)
Management may be a human-contrived concept, but that doesn't automatically make it invalid. Man has created all sorts of things that never existed in nature and we're far better for it.
I agree that management becomes more of a necessity when the workers being managed are brought in with lower expectations (and pay). But my experience has been, the places filled with cubicles full of idiots waiting for daily instructions are the places that never valued the rank and file workers to begin with. They just nee
Why not just address the nonsense? (Score:3)
If there are too many meetings address that issue. If there is political bullshit address it. If the processes are all fucked up and you have guys jumping through hoops just because some process document says to, fix it. Fixing the actual problems will benefit the company way more than hiring a guy to shield the engineers from it. The last non technical manager I had just invited me to all the meetings he went to because he wasn't able to answer anyones questions. He literally did nothing and when he quit after being denied a promotion he applied for his position was not backfilled
In my opinion you want the engineers to interface with the rest of the company. That is how problems get solved. Engineers getting feedback from customers, tech support, manufacturing, and ops. Then engineers figure out how long it would take and how much it would cost to solve the issues and present that data to marketing and project management. Then you get representatives from each group together to decide based on marketing data and project management input what features to prioritize, what features to drop, and so on. ( I know this never happens in the real world)
All too often marketing draws up some Marketing Requirements Document, which is usually fucked to begin with because marketing doesn't present the engineering group with the customers problems, instead marketing presents the engineering group with marketing's (usually poor) solutions to the customers problems. Then some project management people get together with the non technical manager and agree upon some crazy timeline based on no input from the actual people responsible for doing the work. Then the engineers get a product spec document that basically says to invent a perpetual motion device in a couple of months. When they don't do it everyone blames the engineering group for not following through once again. Set up to fail from the start... In my experience non technical managers don't do anything but add additional noise to the signal.
No, they have no passion for software! (Score:2)
I have never met a successful manager of a software development team who did not have a technical background. I have even met a few liberal arts majors who learned to develop software on their own. They had passion, they achieved a technical background on their own.
I have met plenty of unsuccessful software development managers that do not have a technical background.
I waste 6 hours of my day, on average, dealing with non technical managers of technical teams. Much time wasted explaining the technical aspec
Depends on the Developers (Score:4, Interesting)
Most of the developers who I have worked with do not want to deal with all of the process and paperwork (change requests, scheduling pushes (dev to test, dev to prod), etc). In cases like that, the manager is useful because they let the team focus on what they are good at (writing code). The managers are also helpful because they free up the devs from having to deal with the frequent requests for status updates.
Having recently started managing people in an operational capacity, I find that most of my time is now spent making sure that other people understand what their priorities are, making sure that they are getting the work done, and helping to set priorities for the department. The reality of it is that there are only so many hours in a day. While I still get to work on PoCs, and do the more risky technical tasks (like planning migrations, application deployments and upgrades, etc), I now have to "waste" time managing people. I say waste because honestly, it was not until I became a manager that I had to deal with the fact that a lot of people are not motivated. A lot of people need someone there to make sure that have done their homework. That mindset sucks, but I am not sure what to do about it. I enjoy what I do for a living, so I do not mind working. A lot of people out there just want to collect a paycheck. Managing people takes away from time that I would rather spend working with the systems or learning new technology.
I think that I am different from the typical manager because I was given a team to help me handle my work. I had more to do than there was time in the day to get it done with. The tasks that I have to get done directly affect the profitability and operational capabilities of the organization. I know what I need to do and can set my own priorities. Given that, I have been allowed to hire some people to help me out. Therefore managing them is fairly easy because I get to set the priorities and do not have many people above me telling me what they think I should be having my team do.
It is possible to have a good project manager who knows next to nothing about technology. We always joke that one of our PMs could be running an automobile plant just as well as she helps run our projects. She knows practically nothing about what we do, but she can build project plans, set timelines and most importantly, keep people on task. When timelines start to slip, she is great at gathering feedback about why deadlines are being missed. That feedback then helps the rest of the team realign and keep things moving forward. Again, she knows next to nothing about the feedback she is being given, but that is not her job. Her job is to keep everyone in communication with each other, and ensure that everyone has visibility into the status of the project. Lastly, she is a great resource because every project she runs is run in an orderly, predictable kind of way. In the tech world, especially among developers, it is all too common to make things up as you go. (After all, that is what developers do. They develop things that were not there before. An inherently creative process). Our devs know what when they are done with their latest build, it will get pushed into test. They do not have to spend time pushing it to test. They do not have to build the process to push it to test. That process is already there for them. Same thing with soliciting UAT feedback. They do not have to gather the feedback. The PM gathers it, orders it, prioritizes it, and then makes it available to the manager(s) and developer(s) whose code needs to be refined.
Re: (Score:3)
I agree. In my opinion, a technical manager should be able to do some, if not all of what their employees do. The manager should be the manager because they have enough experience doing what those who they are managing, are doing. That might be my own bias because in my own career, I have been fortunate enough to have a number of very good bosses. My own IT experience has been more of a traditional master / apprentice experience where I have been able to learn from people who are very good at what they
Sheepdog (Score:2)
The answer (leaving aside the contradictory point that members of a team can't be self-motivated they're either motivated by the team, or by themselves) is that the job of a manager is to manage them, so technical skills are unnecessary.
Management is a separate discipline, with its own skills. It's not being a sort if super-programmer who's been promoted. They are almost always the worst sorts of managers. In this case it is th
We are undergoing this at my company (Score:3)
Once, managers were alpha technicians who got promoted. In the last couple of years, someone had the idea of adding a layer of non-technical management. This led to red tape and processes be shoved down the technicians' throats. The newly hired managers are so non technical that they cannot recognize a skilled technician and choose appropriate experts when facing a problem. So, they hire external consultants. Also, they are those people that were the nerds' bullies in middle school. A mix of technical incompetence and past personal history made the engineers turn against them.
Now, those managers report to the CEO (they are his experts) and shield him from the technicians, as is should be, but due to their technical incompetence, their reports are incomplete. So, the technicians are starting to bypass all the red tape and the managers and address the CEO directly (or the CEO is contacting engineers, I did not follow).
We had a big meeting lately where the engineers mumbled "can't you just let us do our job in peace".
The situation was bad before, but has worsened with the introduction of non-technical managers. We have reached a point of disruption, and the best engineers threatened to quit so loud that the CEO may reverse course. Next year will be interesting.
My best boss ever.. (Score:3)
We were the R&D group of a major corporation
Our boss, the VP of R&D, was non-technical, but he did a great job
He handled the politics
He got us the budget
He got us our own purchasing guy and receiving dock
He isolated us from the bullshit of the rest of the corporation
He gave us freedom to handle the technical side as we saw fit
To sum it up..his job was to give us the perfect environment, our job was to do cool stuff that made him look good