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?
Consumed in moderation, they can be part of a balanced and brain enriching diet. Personally, I am sort of a vegan when it comes to this specific item at the cafeteria, so I make it up with M&Ms and Mountain Dew.
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
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.
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."
Absolutely. While I would hesitate to call my manager 'non technical', he is much more focused on the look and feel of our company websites. It's my job to implement back end functionality. However, he makes my working life easy. I'm able to work for long periods of time with 0 interruptions - mainly because he fields all the 'feature requests' and complaints. A great manager can be worth their weight in gold - a terrible one can drag you down like they were made of lead.
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'
The answer clearly is no
http://en.wikipedia.org/wiki/Betteridge's_law_of_headlines
I always thought of Creationism as the Raving Right's version of the Loony Left's Anthropogenic Global Warming-brightmal
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.
Futurist Traditionalism
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.
The cow says "Moo." The dog says "Woof." The Timothy says "Thanks, valued customer. We appreciate your input."
a manager needs to understand what their underlings do. It's been my experience that non-technical managers rarely understand the jobs of the people they are managing.
I was going through "technical" interview with IT manager who had only MBA under her belt. She asked me the question: "What is common between air plain, rubber band and lake ? "
In my experience, IT mangers don't none of those things: "They protect the developers from getting sucked into meetings with other departments and provide a unified front for your group."
"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.
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.
It crowd, a relationship manager can be far more useful in alot of situations for IT pros, I ahve had non-technical managers in the past and wasted alot of time explaining basic terms and computing requirements that a Technical manager would have grasped/known, our current manager for a team of 25 It pros is actually called a relationship manager and she is amazing for sorting out interdepartmental issues / managing budgets and so on, she is not required to understand what we do, just that we get it done.
No. Not unless they are in a non-technical role. Then they can add plenty of value.
Easy wasn't it!
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.
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.
"I'm so moist I'm sticking to the leather." -Kermit the Frog on The Late Late Show
Where the mangers is answering questions when those questions need technical people to answer them.
I do not enjoy working for non-technical leaders. I don't like having to explain what I'm doing all of the time, and often breaking things down into words and ideas my child or mother could understand. I've worked for both in my almost 20-year IT tenure, and I far prefer "working technical leaders".
I dislike the term "manager". It shows a false understanding of what's supposed to be in place and occur. You manage things, you lead people. Leader is and should be the correct term.
Oddly enough, the captcha is "idealism".
It describes the good bosses perfectly.
Like all managers, the bad ones pass down everything from the top unfiltered (so they can never be blamed), and
pass stuff from down to his superiors only when required, and never does something like that proactive, always needs
to be cornered and forced to do something about anything.
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...
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.
Actual Technically-oriented managers will want to remain near the technical, productive level, so they won't allow themselves to be promoted up and have more managers brought in under them.
Non-Technical managers do not care about being near the technical, productive level, so will always be aiming to get promoted or get underlings below them, thus bloating the organisation and eventually destroying its productivity as top management become n-levels seperated from the people actually producing stuff.
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 quickly get away from the latest technologies and get stuck on what they did 3-5 years ago rather than what is common practice now. That can be a huge disadvantage to the team.
In my case, I let my staff go they way they wanted to and did what I could to encourage them to do so. I had my own opinions, but allowed myself to be swayed if they made a good reasoned argument that went against what I thought was the way to go. And they were able to get it done.
I agree completely. It can be a invaluable help, and spares all that time which would be spent on meetings explaining things to consulents, the customer or whoever else. Not to mention all the organization of parts, support and tests.
A bit of technicality is a must, otherwise almost the same amount of time is spent on explaining the problem, just now for a much smaller audience.
A fair amount of technicality is even better, or impossible or very hard to implement solutions could be sold by "mistake" as a result of lack of understanding of the system.
but how many actually add value, and how many are PHB's. A lot of MBA's are taught that arbritrary checklists are the only way to manage. I've seen places that demand time allocation listed in 15min increments, which inevitably leads to filling out the checklist being included on the checklist.
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.
It's supposed to be completely automatic, but actually you have to press this button.
As a non technical manager is to continuously ask "what/why" to every feature we're building but to trust the engineers in how to build it. If you can explain it to me, you can explain it to the user. If you can't explain it to the user, he won't use it. I'm not talking about if you want to use PostgreSQL or MySQL, I'm talking about if an action is necessary to take. Here are some of the standard questions I ask:
What exactly does the user expect
Does the proposed functionality fulfill that expectation
What are the approaches we can employ to create that functionality
What's the best way
What's the quickest (usually cheapest) way
What's the criticality to the use flow of this functionality
These questions help me budget time and money and meet the users requirements. Remember, from an engineer's standpoint, you can build anything. It's the managers job to make sure you're building something useful within the constraints of the project and ensure you think about how to do something, and not waste time thinking about what to do and where to get the resources.
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. .
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 technical manager can fall into the second category above, if they really want to develop instead of manage.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Non-technical managers just cave to pressure from higher management, the only line of defense I've ever seen is from technically experienced managers - usually those who were sys/netadmins or developers themselves once- who understand the issues and workloads.
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 smart decisions by taking that into account. The ability to say "no" to superiors, even when their pie-in-the-sky ideals are unrealistic, is definitely lacking. OTOH, saying no to subordinates, not so hard. However, the day when we can no longer pull miracles out of our ass is fast approaching.
Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
A bad combination is a non-technical manager managing an R&D group. I worked in such an environment as a senior R&D engineer making furnaces.
We desperately needed some test equipment (nothing earth-shaking, a couple of $200 items). My manager just crossed his arms and said "Why do we need it?" Fair question, so I had to give him a heat transfer and fluid dynamics primer (conservation of mass and energy) explaining that we needed to measure an air flow rate to understand what was happening in the device we were trying to market. The idea was to be able to tell our customers the principle of operation and how to optimize the control settings.
He basically nixed my request, pointing to a Wikipedia page with fluid mechanics equations that could be used to estimate air flow rates (ignoring or not understanding that the equations did not apply to our application). So I launched into another heat and mass transfer lecture, explaining why these equations were not suitable, and we needed the equipment to actually measure the air flow.
Nixed again, another Wikipedia page thrown at me with yet more equations that did not describe our situation.
I left after 7 months, despite the $120k salary, because I couldn't make any technical headway and saw that a crash was coming. When I left they were struggling with a flood of customer complaints about the furnaces that they were pushing to market yet they did not understand how they really worked. A few months later, after the more-or-less inevitable downsizing, I met with a few of my ex-coworkers that said that I was one of a string of PhD engineers they hired to sort things out, but they all left out of frustration. They praised me for sticking it out for 7 months, the previous record was 3 months!
Now I am a professor teaching engineering heat transfer and fluid mechanics and I get outstanding teaching reviews, so I chalk up that 7 months as teaching apprenticeship. Thanks boss!
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.
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.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
I used to think that IT Managers needed to be technical to be any good, but I don't think it's true anymore. I've had non-technical managers that new what it took to make things happen; 1) hire the right people and 2) make sure they had what they needed to operate. The best project manager I've had did the one thing I needed when I was working on an issue at 2am - she brought me coffee. No attitude, no, "I'm a manager, I don't do this". She went across the street and brought me coffee. That happened 7 years ago and I never forgot it. Non-technical managers come with advantages and disadvantages like everything else, but when they're good, they're VERY good.
(Formerly - I'm in sales now...) I was lucky in that A) I had some basic coding skills, though no one in their right mind would hire me as a real programmer. At least I understood the basics. And, B) I'd spent many more years as a worker-bee than a manager so I had *lots* of experience on how NOT to manage people. I always adhered to a few basic principles; first, they are people, dammit, not "resources" and they have skills, desires and aspirations that must be acknowledged and rewarded or they'll fly the coop to some place that will recognize them. Secondly, my success as a manager depends on what they produce, both in quantity and quality. Period. Therefore, it's my main goal to make sure that they have the tools and guidance to be successful. Finally, the age-old saying: praise publicly and punish privately. Again, they're people and deserve to be treated with respect. Even when you have to fire someone.
If you need a manager to "shield" people from politics and red tape in your company, let me tell you that the thing that is sucking out all the value and all your profits is in no way connected to technical knowledge or not.
Seven puppies were harmed during the making of this post.
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.
Drill baby drill - on Mars
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 right person on the team (as rarely as possible).
3. Has at least one person on the team with sufficient interpersonal skills (and enough political common sense to stay quiet during non-technical discussions) to take with him to meetings where many unpredictable technical questions are likely to arise.
Really, this doesn't happen all that often. Most of the manager's work is non-technical. I'd take a good absolutely non-technical manager over an average technical one any time.
With similar management skills a technical manager would probably be better. Probably. Can he resist the urge to micromanage things he does somewhat understand?
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!
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
A non-technical manager can add value by serving as an abstraction layer that encapsulates non-technical stuff (such as budgeting, marketing, and political tackling) and interfaces between technical and non-technical groups. This requires leaving the technical stuff to the right people, which may lead to a technical guru as second-in-command. The biggest challenge to a non-technical manager is long-term planning! After all, how can you see ahead when you cannot fully understand the current picture? The manager of a technical unit must have technical knowledge at least on overview level of enterprise architecture...
A good manager keeps invasive outsiders away and makes sure that the workers have what they need.
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 being able to re-frame them in a business sense (for the outsider). It means being able to answer why the insider can't have everything. It means being able to explain business needs and how the technology can meet it. Within the team, it means managing the dynamics of the group without being a babysitter or kindergarten teacher.
A business-oriented person who understands the implications of the technology can make as good a manager as a technical person with a strong understanding of the business needs. The most critical factor is the ability to translate and communicate.
Make sure I have the resources to do what needs to be done. Sometimes those resources are blockers.
I'm have a key role in how the entire enterprise functions. I *CAN* look at your printer. But so can the department that is supposed to do that. I'm not better than them. I'm in a different role, and the desktop/printer people won't be put on a pike out front if payroll doesn't happen. So it's not fair to skip them to come to me, and expect me to do both, and them to do neither.
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: 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.
bickerdyke
My manager totally shielded me from all the meetings and endless debates about business requirements. I wouldn't go to meetings for several days in a row. Just programming, music and beer. Now he's gone (resigned) and they haven't replaced him. Those were the days!
Fred Brooks makes the point (in Mythical Man Month) that nearly any project organizational method can work, as long as the project is small enough to be within the understanding of the entire team. If you have 10 good people on your team, you don't need a manager. If you have more than 20 people on your team, it starts to get hard to do things without a manager.
Of course, managers are of all quality levels, as are programmers. A bad manager slows things down, just as a bad programmer does.
"First they came for the slanderers and i said nothing."
http://www.theitcrowd.co.uk/characters/jen.htm She comes in handy: defuses situations, stops the fairly regular beatings, knows pretty girls on 7 so you can use her name to go schlepping around with..
as a good manager is one who can buffer their staff from the dumb ideas from senior management.
One of the key attributes of such people is the ability to talk with and deal with senior management on their terms - i.e. they speak the same language, and they can translate the problems identified by their staff into terms that senior management can understand.
This is not something that technical managers can always do - they may understand the issues, and may not need to get feedback from their staff, however translating that into a conversation that presents senior management with the risks and accountabilities that they need to accept.
Would you put someone in charge of finance who didn't have a background in finance or accounting?
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 within a specialist department should be representative of the core competency of that department. We certainly need people to help manage the money and people, and there are many other roles within a large IT organization that don't need to be technical. But, when it comes to making good decisions about technology you really need people with a technical background.
... and their boss's way to get you (and every one else two levels down) to do their boss's mission.
Management is a human-made thing, and has no real place anywhere in Nature. If you get a group of any number of people that know how to do something that needs to be done, they'll always self-assemble, and get it done. The problem comes when one of them tries to manage it all.
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.
Politics; n. : A religion whereby man is god.
Have dealt with my fair share of managers. A few good ones most of them mediocre, some truly awful. Just like programming, systems administration, testing, etc etc it is a skill and like many IT skills they don't necessarily teach it at college. You don't need great IT skills to be a good IT manager, you need good people skills, and the ability to determine what is it the next level of management thinks about your dept and how do they make that determination. In roughly 20 years of IT work, 2 of the three most effective managers I have worked for were not from the IT field.
Strong business knowledge helps tremendously in no matter what you do. I can't tell you how many times my education has led me to solutions overlooked by my coworkers with equivalent, if not superior tech savvy. At the same time, you still need the technical knowledge otherwise your not in the game, I can't stand managers that don't understand at least the framework of what their employees do, its all too common and you can usually tell because they hide behind buzz words and vague assumptions.
Even if a "non-technical" manager can do the job, guaranteed that one that gets it would do a much better job. Good teamwork can go far here, but I'm a firm believer in leading by example.
My non-technical manager usually pulls me into non-sense meetings with other departments and teams so that I can do the talking in case a technical question comes up. Around here we are asked to provide "feedback" on training plans, and we do our own HR paperwork. At the end of the day the non-technical manager handles budgets, hiring, and walks around asking when he's going to be able to put the checkmark on this and that item.
A previous very technical manager understood the trade, and did in fact shield my team from all the noise that prevented us from getting things done.
A prior to that I quit a company because the non-technical manager there insisted on having the technical people explain and justify their work every other day, and we never figured out a way to make things work with her.
If managers are there to shield engineers from "political nonsense and red tape" it is probably more cost effective to reduce the political nonsense and red tape instead of hiring someone to deal with it.
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.
A non-technical manager... well, they can shield me from their touchy-feely meetings with other departments that just suck up and waste time... just so that they can have their own touch-feely meetings with me and the rest of the team that they manage that suck up and waste time.
Nope, for any technical job, the direct manager needs to be technical or they are very unlikely to be respected by their team. A non-technical manager cannot fully appreciate the difficulty of task, and that goes both ways... they can think something that is trivial is one of the most difficult things in the world, or they can think something difficult is one of the most trivial things in the world. They don't have to completely understand the work that their direct reports are doing, but they need to have a pretty good idea so that they know what they are asking of their reports and they can call BS on their reports when they are trying to pull a fast one.
That being said, they do need to shield their direct reports from the BS mentioned... but non-technical managers can only relate with their direct reports in a non-technical way... meaning touchy-feely meetings. To be a good technical manager is NOT an easy task and I fully appreciate the work that one does. You give me a clueless touchy-feely micro-manager and I will leave at the next best opportunity.
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 aspects of their own teams to them so I can get them to do what they should have known to do in the first place.
I do not understand how someone can be passionate about a technology construction, and not be technical. These folks should chase their passions somewhere else.
The best managers that I have had, and that I deal with now, are former EE's, CE's, CS types with development experience that went on into higher management ranks.
You spend more time figuring out strategy, and less time bogged down on trivial matters that are obvious to the greenest of college hires.
The answer clearly is no.
Escher was the first MC and Giger invented the HR department.
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.
Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
I gave them donuts, with the promise of MORE donuts to come....
Joels Spolsky wrote this article years ago:
http://www.joelonsoftware.com/items/2009/03/09.html
He said a (program) manager should:
1. Design UIs
2. Write functional specs
3. Coordinate teams
4. Serve as the customer advocate, and
5. Wear Banana Republic chinos
You don't need to be deeply technical to do any of these things, but you do need to have some skills that are not "generic" for other areas, like knowing usability.
And most importantly he must be a peer to the developers, not a boss. Otherwise when they say anything unfeasible (or stupid) the devs can't disagree because it will be bad for their careers. And here lies the problem, after a century of corporate culture evolution managers can't be anything other than bosses in most companies. Most career paths in companies make the senior members into managers.
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 the job of the manager to ensure the "motivation" is directed towards the project's goals rather than towards goofing around on the "interesting" and "self-motivating" parts.
That is the only way to make sure all the other IMPORTANT parts of the project are executed properly, not merely the coding. So the job of any manager is to control the sheep, or programmers, to make sure they are all going in the same direction, not being "self-motivated" all over the place, wherever their interest or motivation takes them.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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.
Just as there are nightmare PHB managers, there are useless waste-of-space techies. Assuming that we're talking here about apples and apples (competent managers and competent techies) they bring different, and damn-near equally important, skills and assets to the table. I have spent several decades in the science-for-hire business (research in a private company, not university related), and you see the other side of this problem quite often. Highly competent science types who take on management roles rather than hire someone with the right skills because "I am a PhD and can do this silly management stuff with one hand behind my back." Those are the companies that run into problems big-time. Any good science/tech business of any size needs to have good managers who have been trained for what they do and are competent at it. If both sides recognize the inherent worth of the other (again, assuming competence all around), and if they stay off each others turf and call on the other when their expertise is what's needed, this is what makes a company run.
at least that is persistent and wide spread view I have been allowed to experience in projects last few years. As soon as organisation moved to 'agile' frameworks they seem to forget all they ever learned about project management which if project is big (sort of bigger than one 7 person teams seems to be main criterion) causes quite some stress points in the team (and product). If there is enough money in it and project is made for customer not for the open market it can fly. It is still a struggle. Funny that as I had a chance to see two projects doing exact the same stuff in different organisations and the one doing it with clear disregard to any project management techniques from the past was only 5 times more expensive. But hey - there were some people happy to work in a chaos. This is not to say such approach cannot go well - small projects or some where people equipped with some social and management skills can be quite fun to work without formal management structure thrown from above and deliver successfully. ymmv but that is always so, is it not?
a lot of the important parts of my job could have been done by someone who didn't know much about software architecture or programming. Not all, but *some*. A lot of it is keeping developers from being distracted by BS, which is a thankless job. When you do that right, developers start to believe that work is just about getting paid to work on interesting things; nobody will miss you until you're gone.
In most software projects there has to be an interface between the technical folks and the non-technical users and management. What is the chance that that position is unimportant? Practically none.
And look at it from the other side. You don't like it when your boss acts like a technical ignoramus, but *his* boss doesn't like it when he acts like a *management* ignoramus. The person who sits in the middle has to have a certain mental agility that not all developers or managers have. He's got to fit in on both sides of the equation.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I remember a similar topic roughly a year go.
Table-ized A.I.
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
If they are good at blocking the bureaucracy, that is definitely a value. If they don't have a technical background, then they shouldn't be making technical commitments for the group in meetings. A manager willing to admit his strengths and weaknesses and seek support for the latter is worth his weight in gold.
A man's got to know his limitations.
Have gnu, will travel.
My manager wasn't technical enough to open a laptop lid, but could debug your kernel memory manager with just a protractor and 2 fifths of whiskey. He once filled out a requisition form using only a sharpie stuck up his ass in the middle of a team meeting. Here's to Bill Brassky!
How does a non-technical manager add value to a team of self-motivated software developers
It's a loaded question. I mean self-motivated software developers aka rockstars?
The answer is immensely. I mean you need at least one adult on the team.
Please define "value" first. Otherwise it's one of those never ending "is it good for the economy?" debates, where everyone has his own definition of "good", "economy", and what they mean when used together.
Former semi-technical manager here. Related questions seem to come up frequently. What value do managers add. Why can't they get out of the developers' way and let them just do their thing. Well, I have parachuted into some teams which were run by developers and engineers without clear commercial leadership, and those projects always turned out to be in a pretty bad shape. Even though there were senior and highly qualified engineers in place.
So as a manager, you start asking some basic questions. What is this we are building here. What features are we working on. What vision do we have for the final product, what experience is it supposed to deliver. Ok, we don't know - maybe we should figure that out, rather than doing development for 3 months and just see what comes out of it. Is what the team is working on now and with current plans, going to deliver the target experience. Who is sponsoring this project, that we need to keep informed and who will champion this project when resources get tight. Why is the most junior guy fresh out of university working on the most critical piece of code. How does what we are building fit with what the rest of the organization is doing. Why are you guys forking some piece of code creating your own special version of one of the company's products just for this project; have you got any idea whatsoever of the implications on maintenance costs down the line. (Well - that is one of the problems that a purely non-technical manager is going to have a hard time discovering, because he is not going to ask about it, and the engineers are for sure not going to tell him about it - they don't even know it is a problem.) What is it you are doing differently so that the core engine is going to work _this time_, given that the previous three attempts failed - did we learn from that at all, or are we just trying random new things.
You can just go on and on. A team run by engineers without clear leadership by someone with sufficient managerial level to be a real manager and not just an "architect" or "technical manager", will end up in a mess 90% of the time. The remaining 10% of the time is for projects that are so simple or small in scope or technical in nature that the engineers will get it right.
Crappy managers will ruin any project. Non-crappy but non-technical managers have a bit of a challenge, but you would be surprised what a competent general manager will be able to figure out, just by starting with some innocent questions and going from there, and spending some time getting to learn more about the subject matter at hand. Unfortunately, only a small percent of managers have the level of leadership skills and ability to figure out new things on the fly.
my two direct supervisors are both technical people, so one hide all night doing "reports" on the other side of the building, and the other leaves at 3:30. I don't get there until 2:00, and he's usually off smokin n joken with other "managers". Out of the 11 other bosses I have, only 7 of them are in the same town, and 6 of them are at least semi-technical. Non technical - as long as their competent at their job that's great. The smartest geniuses ever can still be incompetent at social skills...
Ugh. I saw this topic come up on Reddit yesterday. It seems like everyone who starts praising "non-technical" managers simultaneous brings up their favorite managers who demonstrate a considerable technical knowledge. It seems like what everyone keeps defining as a "non technical manger" possesses a considerable technical understanding of what their teams do.
Actually understanding the process that goes into developing software, or being able to understand what the members of the development team are doing. I've definitely had my share where that is above them.
Try being a developer and working for a real non-technical manager, e.g. completely technologically illiterate. Who can't tell the difference between Windows and Linux -- and hires a Windows consultant to provide assistance on resolving issues with a Linux production environment, and insisted that we figure out some way to get McAfee Antivirus working on CentOs (because company policy is that all computers have to have McAfee on them!). Who has zero understanding of what developers actually do (e.g. repeatedly tries to assign graphics work to developers, assigns HTML markup to DBAs, and tries to get the front end devs to write ad copy). Has no patience for anything technical to be explained to him and often has less of a grasp of the technology than the clients, subsequently believes anything the clients tells them can be done over the rejections by staff that their requests are either impossible to accomplish, outlandishly under planned, or the "bug" the client is experiencing is due to the client's own user error.
Oh, but supposedly he's great at marketing. Because actually making a product, who cares about that.
Bob Slydel (John C. McGinley): "What you do at Initech is, you take the specifications from the customers and you bring them down to the software engineers."
Smykowski: "Yes. Y--Yes. That's-- That's right."
Bob Porter (Paul Wilson): "Well, then I just have to ask, why couldn't the customers just take them directly to the-- to the software people, huh?"
Smykowski: "Well, I'll tell you why. Uh, because... engineers are not good at dealing with customers."
Bob Slydel: "Uh-huh. So, you physically take the specs from the customer?"
Smykowski: "Well... no. M-My secretary does that, or they're faxed."
Bob Slydel: "Uh-huh."
Bob Porter: "So then you must physically bring them to the software people."
Smykowski: "Well... no. I mean, sometimes."
Bob Slydel: "What-- What would you say you do here?"
Smykowski: "Well, look, I already told you. I deal with the goddamn customers so the engineers don't have to. I have people skills! I am good at dealing with people! Can't you understand that? What the hell is wrong with you people?!"
Best movie of all time... of all time.
And should not be under appreciated. Not only because of the political stuff, but just to keep people connected to the company. The worst thing in the world is to be abandoned by your management. It sucks. And management is a real skill. There are people who think they are managers and then there people with real skill at managing people. And it seems to start with being a decent human being, but goes way further.
The best people I ever worked for were former IBMers. IBM builds great managers.
I've worked with a number of technical and non-technical managers and, in my experience, it doesn't take a deep background, but if a good manager is managing a technical problem, they get at least somewhat technical. If you don't know anything about web development, how can you hope to hire the right people that know how to do it well? How do you know if the estimates from your junior engineers are realistic? You have to know the technology well enough to at least know the right questions to ask.
I recently joined as manager for a team of developers and the environment is toxic because, up to now, engineers got dragged into every meeting because the manager did not not have the knowledge required to make decisions or communicate with other teams. The application was throwing exceptions and having frequent production outages, and no one was asking the right questions to get them fixed (developers had convinced non-technical manager that this sort of thing was normal). Developers coded aimlessly, with no real design, because no one was evaluating them on code quality. Several developers (including the "architect") would coast under the radar, giving inflated estimates for the simplest of tasks, and the manager did not have the knowledge to challenge them.
It can certainly be done, but if a manager can't perform some of those key functions, someone else (maybe the architect) has to, and the power dynamic becomes very tricky if the non-technical manager and architect disagree (maybe the manager is good friends with a team member, but the architect knows that person isn't pulling their weight). I generally think it's better to have one person who can be held responsible for all aspects of a project's performance. If you need a gopher, get a secretary or maybe call them a project engineer, but put someone who understands the work at the top of the chain of command.
Ok, fine, you don't need a manager. So stop programming and YOU go to all these fucking meetings all day and placate people from other business units and deal with pissed off customers.
No. They Don't.
What company is this that the manager does all that? Political non-sense, red-tape, endless meetings... As a systems engineer, these are the bane of my existence. And it's only getting worse.
In my 20 years of IT experience, I've had precisely two managers that would fit the optimistic description in the story. The rest have been a complete waste of oxygen and usually made life much harder than it needed to be.
Alas, the Dilbert Principle is the order of the day in most Enterprises.
David de Groot Snr Systems Engineer
An overly technical manager can be dangerous. They tend to overlook important non-technical issues as they gravitate to their comfort zone in the 1s & 0's. OTOH, a Manager who has no practical problem solving skills will be out of their depth. What you need is someone who can comprehend complex issues but knows how to deal with people and politics in a way that technical people shouldnt have to. Case in point, my previous mgr. Who was caring, fair and encouraged us to grow while guiding us and mentoring in a wise, original thinker type way. He really made you feel like you were important and valued. Now hes gone (mostly because he was much too forward thinking for our monolithic telecom operator company mentality) and we're stuck with a new mgr. who thinks its ok to use email as an IM client (papertrailer), asks for vacation schedules 12mth in advance, and doesnt mind asking people who have been working for 24 hrs to just deliver that one more thing just so he can further his own goals of corporate ladder climbing to the detrement of the very team he is supposed to be leading. Good mgrs are extremely hard to come by. If you're lucky enough to get one, be good to them and learn from them.
I had a manager who had a very thin technical background. His hope was that he added value. He did not know enough to be useful. Its like being able to read cobol, so they saddle you with it so they can audit. Its verbose enough so that it massively affects productivity, has too little in the name of tools so that you constantly have to re-invent the wheel, and they rarely audit, so you are stuck (and they still can't understand when they do try to audit). I had a manager who wanted to audit power consumption in the data center by counting power cords. Re-read that: counting power cords. A 4 port switch consumes 50 milliAmps, and a server consumes 15 amps and to him they are all the same. Likewise, locking himself in his office for 5 weeks so he could come up with a (mis-spelled) mission statement for the team (he was team leader, I was the team). He did not help. When he was on call, I would get his calls. I was left out of important meetings routinely. I might get information after the meeting was over, important questions would not be asked, and I would be left fixing things later. I was berated for giving 'only' 3 months of data for a quarterly report (remember, quarter means 4). I could not get parking permits to attend meetings (but his boss told him just to ask for all the parking permits he needed and to pass it on). I was denied any access to the internet and had to ask his boss for it (and it was promptly given). He was an ass hole. After I left, they could not replace me and tried (unsuccessfully) to hire me back. Imagine that.
How does a non-technical manager add value to a team of self-motivated software developers?
By leaving? But, more seriously, a good, non-technical manager can actually be of value to a technical team, if he understands his role, which is it to take care of all the non-technical management - and nothing else.
To illustrate: I once had a manager who used to say "leading programmers is like herding cats", which brilliantly demonstrates that he doesn't understand programmers, leadership and cats. Firstly, thinking that "leading" is similar to "herding" means that you believe your staff are no more than non-thinking cattle. But programmers ARE a bit like cats - they have a mind of their own and see you as their equals - at best. The secret to leading cats - and to any good leadership - is to treat them with genuine respect, so they get to trust you, and never try to hem them in without a very good reason, because they will just walk away. You have to be the sort of person they want to follow.
Most non-technical managers just aren't the kind of person a techie would want to follow, sadly. I suppose at least part of the reason is that in order to be successful in a management career, you have to have a rather conformist mindset; you need to be somebody who likes rules and feels that it is wrong to question them. A technical career, on the other hand, requires you to ask critical questions all the time - you can see how that might make the relationship difficult.
Some do, some don't.
If you call sucking up to his boss, sowing discord in everything he has his finger on, being a laughingstock to everyone else, and a legend in his own mind being productive, then yes he is.
...less valuable for actual project planning.
We have a non-technical project manager. We work as basically subcontracted labor for a major vendor. There's a lot of paperwork and reporting associated with the projects we do that has to be done in tight deadlines for us to get paid and we never have to do it or see it, which has a certain value because I'm pretty sure if we did have to do we would be expected to do it outside of normal work hours. It lets us focus on the technical work and not on the bureaucracy.
The downside is that project planning, even for projects highly similar to what we have done several times before, is a tedious session of overly detailed task descriptions. If the PM had better technical knowledge these planning sessions would be a hell of lot shorter as the PM would have a more detailed idea of what needs to be done and the more optimal order of tasks and the time involved -- the plans would be 90% prepared instead of 20% prepared, often with wildly inaccurate schedules. The PM would also be able to grasp the existing customer environment details better which would greatly help planning; too often you end up blind planning because the PM can offer no insight or you have to have extra meetings with the customer who often feels a little exasperated at having to provide the same info the PM didn't grasp before.
In our case, the PM is more of a "coordinator" and less of a "manager", which has some value but makes the management side of project planning too time-consuming and tedious.
In my experience most managers are ineffectual at their primary function - people management. Too many times I've seen projects fail or almost fail due to a manager's inability. Equally bad is a manager whom spends all their time in meetings instead of interacting with their staff. A manager has to earn my respect but at the outset I give them 100% respect; at that point it is up to the manager whether I loose respect for them.
a solution for with seat time in front of the computer. All that seat time has no value now he like you can just google.
Most of the software failures that I've witnessed are the result of either
1) Poor quality - eg Lots of code, bad / undefined interactions between the components. Usually results in loss of data
2) Poor user experience - software performs complicated task well, users aren't able to adapt to using the capabilities
3) Misunderstanding of the problem solving opportunity - System solves the problem as designed, however rather than automating an old stupid process to take less time, the old stupid process could be re-engineered to bring added value (generate revenue, save lives, retain employees, etc) to the organization
Fixing the first requires someone that is technical, but not necessarily that technical.
Fixing the Last requires someone that understands the business. They probably aren't technical.
Fixing the Middle requires someone that understand user experience, often an engineer with some empathy, or a business person that is technical.
Good technology requires both technical and non technical contributions for success. That combination is rarer than you would think.
In other words, non-technical managers create a bureaucratic, red-taped environment for themselves so that they have what to shield programmers from.
in my professional IT experience I have had 1 out of about 10 managers that I found any value in. If you find a useful manager, my best advice is to leave when they do.
Lots of discussion about "shielding", "protecting" etc. Good stuff, but don't forget that being in a management position also means being a leader, and leaders need to challenge their teams to reach higher (quality, productivity, etc). and accomplish more. New managers out there shouldn't lose sight of this. It's very important. Source: IT VP.
My experience has been that non-technical managers in IT suck. The worst manager I ever worked for was non-technical and that meant that she was easily lied to because she had no way to judge what she was being told and she just assumed that the people under her would tell the truth. She made a lot of bad hiring decisions because we had some job applicants who lied about their experience and she lacked the ability to see through it and saw no need to have technical people in the department talk to the potential employees prior to hiring them. She also made a decision in agreeing to change the kind of work we did that at the time I expressed concern that it was not a good decision. In the end, a department of about 15 people was completely gutted when this new work was moved to a cheaper country we had an office in. She was a pointy haired boss to an extreme and she used to pepper her conversations with whatever industry buzz words were in vogue at the time to make herself look like she really understood the kind of technical work she managed. It's a long story not worth going into, but basically we had some upper management changes in the company and a female manager who had personally protected my manager left the company and the new male manager who took over made my manager a golden parachute offer she could not resist. Her husband was loaded and she used his money to start a business that had nothing to do with IT and as far as I know she has never worked in IT since. The best managers I've worked for all had IT backgrounds and were real in the trenches IT people before being promoted to management and it made them more effective at the kind of management battles that managers have to do with other departments and better able to represent our interests since they actually understood the work we were doing under them.
The purpose of non-technical management is to absorb all the stock options before the people who actually design the company's products can get any.
"Fascism should more properly be called corporatism because it is the merger of state and corporate power." -- Mussolini
I did not see any reference to the manager's responsibility to keep new work coming in and shaping the organization so that all stakeholders buy in to a reasonable if challenging set of expectations. That takes time and effort. If the product ships June 30, what is everyone doing July 1? Who is worrying about that back in January?
When the manager is deflecting politics from the team it doesn't have to be invisible. A few subtle hints to the team about fighting off other departments or beating IT bureaucrats into submission would remind the grunts why they have been making unimpeded progress. Getting the team to appreciate you might seem hypocritical to an ethical manager but it definitely goes with the territory.
Let the doctors do the doctoring, the accountants do the accounting, and let the engineers do the engineering. Don't make a buch of promises until you have talked to the people doing the work to see how long it will really take, otherwise you have nobody to blame but yourselves when things don't work out.
> "Ars Technica asks, 'How does a non-technical manager add value to a team of self-motivated software developers?'
By mating with females, they ensure the propagation of the species.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Everyone keeps talking about how managers are shielding developers. Sorry, that only happens sometimes. Most of the time, the managers are introducing the red tape right into developers processes and make them do extra work that wouldn't be necessary of they were out of the picture.
For example, I've done presentations on how the project is going when the managers should have "shielded" that. And the prep for that meeting took about two days of work that could have been spent more productively.
Also, managers always get the ego from "manager" title. I've been specifically told that developers are a level below managers and I've gotten the "everyone is replaceable" speech. Mainly because that (ex) manager has formerly managed sales people where they were truly replaceable. Tech people need months of ramp up on the new code base. And something that simple was not understood by management!
...I am technical by nature have been transitioning to this kind of role because I'm at a place in life where it makes sense to do that. My experiences have been fairly good, and I've a couple of basic observations below:
For the last 5 years, I've moved into pre-sales and from there have been project management for extended periods of time. The interesting thing I found is by NOT getting as technical as the developers / implementers are, my ability to keep them out of trouble, ask the right questions, clear barriers have all been significantly improved. One very significant element of that is securing help or resources for them when needed.
They won't always ask and they won't always know because of how close to whatever it is they are. Being able to see this condition and deal with it early is worth gold and they are often very appreciative. As an analogy, you are driving somewhere and refuse to get directions, running the risk of being late. You think, just another coupla minutes and I'll recognize something... while your co-pilot doesn't experience this and brings up the phone nav system to bail you out, or they call in to get precise directions...
They don't have the "in the bubble" mindset the driver does, and this frees them to consider things on a macro level. All of that results in more efficient project work and a generally happier team.
Another comment above mentioned the type who can bring different skill sets together to get something done. That has high value as well and I have worked on teams where we had that person. Amazing really. I concur.
When it comes down to silly metrics, non-value added kinds of management things, sometimes those need attention and the good managers will deal with those in creative ways while their team gets it done for real. The poor ones will highlight those things cover your ass style.
And that brings me to my last general comment. Those that own the project and back their team take heat and personal risk. They are very highly valued and they contribute with the common goal of everybody seeing success on the effort. Where they insulate themselves from all of that, again cover your ass style, the team remains at risk, while the manager really doesn't, and that mess generally leads to a low value, high resentment, high friction environment nobody wants.
Blogging because I can...
There's also two complementary tasks that I need to do:
The rest usually just falls in line.
We have a /. post re-asking a Ars post re-asking a Programmers.SE post.
What the hell is the point of all that? Would /. have posted it if it was just a question on SE?
Slashdot links to Ars which links to some other site. At some point, all links will be to other sites and no site will have any content. Then the Internet's decline will be complete.
Or Dilbert's PHB wouldn't be such an archetype.
And btw, my late ex, who was an engineer at Kennedy Space Ctr for 17 years, and worked on Station and Shuttle (and a ton of other things), used to tell me her ex-boss liked to "brag" that his degree was in typing.... and you wonder why NASA's in the state it's in, or why China's becoming the next superpower in space....
mark "actually, where I am now, my boss, his boss, and *his* boss, are all technical"
if they're managers over a project that I am unfortunately tied to, yet not in a direct position of authority over me, I will have zero respect for them and categorically dismiss anything they say, because my typical experience is that they don't understand the basic concepts behind the project and want something compromised in terms of capability so that it's digestible by their feeble mind. in addition, non-technical managers generally tend to churn make-work and/or work that is superfluous to the project goal in an effort to generate something they can even begin to comprehend. they're generally roadblocks, and I resent them for being in even a relative position OVER me (and usually making a higher salary than me).
for managers in a position of direct authority over me, I change jobs for exactly the reasons I noted above. when it comes to explaining what you've been working on for the past 3 months in some kind of mid-term performance eval, a non-technical manager (that has NEVER DONE YOUR JOB) will generally overlook the really hard or thankless tasks in favor of buzzwords that they can palate or comprehend better. If you're talking code, it could have to do with recursive algorithms or matrix transformations or just about anything. Bottom line is, it's hurting you and your career to have someone evaluating you who doesn't really understand what you do on a daily basis.
The term non-technical manager is an oxymoron. An IT manager has to be technical, as you cannot manage that which you do not understand. A person in management who is non-technical can be an executive. An executive perspective is different, focusing on a "higher" level, the big picture. An IT Manager is like a coach on the field. He has played some of the positions and uses his expertise to improve the players, and sets the standards of each technical area. He is therefore highly technical (or was). His job is to improve his team's game, starting with individual skills, and up to calling the right plays (IT technical strategies), and getting everyone to work together as a team. Knows enough to cry BS when something is not being done right. The best background to have is an IT consultant, where you are an expert in some things and know a little bit about everything else. That, and understanding the team-building concept. The role of an executive is like the GM up in the press box, worrying about the fiscal picture, having tea with the investors, and using politics to facilitate. Some of the descriptions above are right on for an executive. Job skills boil down to talking pretty, knowing they don't know, and keeping out of the way of folks who do. But they serve a very useful purpose, as they can articulate mission, vision, and pave the way to getting those things done (by the IT Manager) Another great analogy is that a newspaper's managing editor is to an IT Manager as the Editor-in-Chief is to (and is) an executive. The managing editor might have ink under his fingernails once in a while, and keeps everyone focused and the presses running. The EIC is concerned that the Whitehouse is calling and complaining about an article, and payroll costs are too high. Every IT department needs an IT manager, but sometimes they get an IT executive instead (the so-called non-technical manager). The trouble is, they still need an IT Manager. But of course, you really need both.
Had a couple of them. Was waist of ressources, time and nerves. Had two with technical background, and they knew what to do.
I've had dozens of managers (I'm a software developer) and the only ones worth a damn were ones that used to hold a real technical job before moving into management. I can deal with their outdated technological knowledge and their sometimes dogged insistence on old methodologies because at its core the job hasn't changed, and they realize that. My technical managers kept the rest of the business off our backs and helped give us the space we needed.
My non-technical managers never quite understood the level of detail that we are immersed in on a daily basis. They were impossible to deal with because they were always focusing on vague strategies like 'better communication' or 'migrating to best-of-breed solutions' or some-such marking nonsense.
It all comes down to this: How can a person be a good manager if they don't understand what exactly it is that you do on a daily basis?
I like my women how I like my sugar.. granulated.
I reproduce the whole paper below with permission of the authors:
NO
-- 29A the number of the Beast
I have had both in the past. Non or less technical managers that did a great job in shielding the "worker bees" from nonsense. And then I have had the exact opposite. The non technical manager would could not debug his way out of a paper bag if his life depended on it, dragging the technical personnel into every meeting and ultimately being the cause for 50% of the department to leave.
So I guess as alway: The answer is "It depends"
You're confusing a Non-Technical [Project] Manager with an Account Manager. Account Mangers are the ones that manage the client's expectations, and generally "correct" for engineers having little more charisma than the machines they work with.