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.
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.
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
"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.
You ever duck your head down, put the earphones on, and cut a swath through the feature list, barely realizing that you've missed lunch and it's already 7pm? You'd leave but you've just thought of a really elegant optimization routine and it's so obvious, but you need to see it work before you go?
A good manager can provide coordination between project members, act as an insulating buffer between customers/requirements and devs, fight for resources, push back against poor requests and push forward agendas like refactoring, internal tool development, or library updates (ie, the Good Fight). Really though, this boils down to the simple goal of letting the devs do their job.
Without all the other context switching, we're free to descend into code mode, shut out the outside world, and make beautiful code that we're proud of. In practical terms, that means less bugs, better security, efficient code, lower cost of maintenance, and so on. That's the biggest thing a manager can really provide; an environment where we're free to excel.
That doesn't require any sort of technical chops.
I made the jump from developer to team lead and now on to management. Good management is very very hard, keeping people on task, motivated, and managing burn out is really more of an art than science and I'm not even including dealing with different personality strengths/weaknesses and the various combinations thereof.
If you have a good manager or even just a not-bad manager let them know. It's a difficult position to do well and lots of folks who you respect see you as worthless.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
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.
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. .
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.
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 requirement was kept in place, and now development has all but halted while developers scramble to find ever smaller and less relevant process improvements to implement.
I think it comes from higher ups telling the manager "I want you to do this" while the manager hears "I want your department to do this while you update linkedin and attend management seminars".
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.
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 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.
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..
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.
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.
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.
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.
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
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.
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.