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
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."
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.
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?
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. .
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
Depends on the manager. I had one recently (re-org. He's still around but I don't report to him anymore) who was excellent at exactly what the summary stated: shielding us from red tape and political BS. He was mildly technical - he could code if he had to, but it wasn't his strength, and (this is probably what made him good) *he knew it*. He would do requirements gathering, secure resources when necessary, and stay out of the way on technical stuff. He'd also take my estimates and grossly inflate them, which generally made them more accurate. Good managers exist, but it's an odd niche sometimes. If we swapped jobs, we'd probably both be much worse at it.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
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.
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.