Do Non-Technical Managers Add Value? 249
New submitter Kimomaru writes "Ars Technica asks, 'How does a non-technical manager add value to a team of self-motivated software developers?' IT Managers have come some way in the past decade (for some). Often derided as being, at best, unnecessary and, at worst, a complete waste of budgetary resources, managers in technology today can add significant value by shielding developers and systems engineers from political nonsense and red tape. From the article: 'Don't underestimate the amount of interaction your manager does with other departments. They handle budgets, training plans, HR paperwork. They protect the developers from getting sucked into meetings with other departments and provide a unified front for your group.'" Has that been your experience?
No (Score:2, Interesting)
No, it has been the opposite. They come out of these meetings, not knowing what they have agreed to. They cannot translate what the developers need, and what the business needs either. They end up being a man-in-the middle mess of Chinese whispers.
Non-technical managers are technical (Score:5, Interesting)
They're technical, but in another discipline: organizational management.
Unfortunately, most companies treat this as if it were not a discipline, which allows them to promote either (a) cronies or (b) droids who went through the project management courses that are short of an MBA.
Your "non-technical" managers specialize in planning projects, keeping people off your backs, and keeping you from falling into common developer pitfalls.
Keep them -- just insist on having good ones, so you have fewer of them.
Re:I've had a few in my time. (Score:5, Interesting)
This. Rule number 1 for managers: have clear goals, and communicate them. Rule #2: make sure the team has what they need.
The best boss I ever had was an ex-Israeli commando officer. No, no, no, he wasn't a "do it or I kill you" manager. He was good because: 1) there was never, ever, any doubt in your mind whatsoever what he wanted accomplished. 2) When you told him what you needed to accomplish that, he either got it, or adjusted the goal. When you think about it, no good officer sends in a team of commandos with a fuzzy objective and poorly equipped. To do otherwise it to spend too much of your life writing unpleasant letters to parents.
Re:Managers (Score:5, Interesting)
Before retiring I was an IT manager. I can tell you my presence was a great benefit to my employees. In addition to isolating them from all the politics and idiotic suggestions from other department heads, I also was a mentor. My staff had varying skill levels and I worked with each one to help them improve their skill set. I also prevented those less qualified from being assigned tasks better handled by someone else.
In addition, I fought the rest of upper management to make my staff's working environment enjoyable. No overtime when I was there. I knew enough to know that overtime is, generally speaking, non-productive when forced, and forced often.
I also instituted incentive plans for those of my staff that tried hard. They didn't have to be superstars, they just had to try to improve themselves. And my staff loved me. All our software was developed in house and we did a major conversion on one of the pieces, probably the most important piece in the chain. We did it on time, minimal roll out issues and no overtime. And everyone had fun along the way.
Problem was, the owners couldn't see the benefit I was bringing to them. Most projects like that are late, over budget and don't work right out of the gate. They fired me :)
Wonder how they like things now?
Product Managers vs Worst Non-technical (Score:5, Interesting)
Salespeople
- To be good in sales, you have to be able to lie to yourself about the quality of a product, because the customer will not be able to believe it's a good product unless you believe it's a good product.
- To be good in sales, you have to be able to convince yourself that a customer has a need for something that they in actuality have no need for.
- To be good in sales, you have to have the belief that "the product is awesome because I am awesome."
- To be good in sales, you have to do anything you can to get a sale
- A good sales person can sell sand to arabs and ice to eskimos.
Product Managers
- To be a good product manager, you cannot lie to yourself that a product is superior.
- To be a good product manager, you have to design a product that people will really want and really need.
- To be a good product manager, you have to be able to say "I am only decent if the product is decent".
- To be a good product manager, you have to have to be willing to push back against a change that will harm the long-term usability or usefulness of a product for everyone else at the cost of getting a short term sale for one specific customer.
- To be a good product manager, you have to make sure your company won't be selling sand to arabs or ice to eskimos, but rather selling ice to arabs to cool their drinks and sand to eskimos to give their cars traction.
With the rare exception of someone like Steve Jobs who's good at both roles, promoting an outstanding salesperson to do product management is like hiring a convicted arsonist to run your fire department. .
Re:Managers (Score:5, Interesting)
When you have a good manager, they are almost invisible and you don't realize what is going on behind the scenes
This is so, so true. At some point in my career, I was working for a large vendor's Advanced TAC. I had a manager who occasionally would come up to my desk with some hot escalation which needed immediate attention. I was wondering what he was doing all day.
Then came the day that he left. He got the Silicon Valley escort out of the building right after his resignation, and I got a temporary manager. All hell broke loose. That's when I realized the true value of my former manager: he was shielding his precious TAC engineers from unnecessary political escalations and made sure that we only got cases which needed our attention, and made sure we actually have some time to analyze the case before coming to a preliminary conclusion. My workload tripled.
I have also been on the other side of that coin. Not so long ago, I was working as a team lead for another large vendor, on a project for a new product. I had a couple of engineers in my team and they would sometimes jokingly ask what I was doing all day. Coming in at 11am, delegating a bunch of tasks and leaving at 4pm. What they did not see is that I worked at home from 8am until 10:30am, and usually until late at night. When I left, I spoke my best engineer a few weeks later. He confessed that he sometimes thought that I was a slacker, but that he now got my workload and was suffering badly. Best compliment I've ever had.
Depends on the Developers (Score:4, Interesting)
Most of the developers who I have worked with do not want to deal with all of the process and paperwork (change requests, scheduling pushes (dev to test, dev to prod), etc). In cases like that, the manager is useful because they let the team focus on what they are good at (writing code). The managers are also helpful because they free up the devs from having to deal with the frequent requests for status updates.
Having recently started managing people in an operational capacity, I find that most of my time is now spent making sure that other people understand what their priorities are, making sure that they are getting the work done, and helping to set priorities for the department. The reality of it is that there are only so many hours in a day. While I still get to work on PoCs, and do the more risky technical tasks (like planning migrations, application deployments and upgrades, etc), I now have to "waste" time managing people. I say waste because honestly, it was not until I became a manager that I had to deal with the fact that a lot of people are not motivated. A lot of people need someone there to make sure that have done their homework. That mindset sucks, but I am not sure what to do about it. I enjoy what I do for a living, so I do not mind working. A lot of people out there just want to collect a paycheck. Managing people takes away from time that I would rather spend working with the systems or learning new technology.
I think that I am different from the typical manager because I was given a team to help me handle my work. I had more to do than there was time in the day to get it done with. The tasks that I have to get done directly affect the profitability and operational capabilities of the organization. I know what I need to do and can set my own priorities. Given that, I have been allowed to hire some people to help me out. Therefore managing them is fairly easy because I get to set the priorities and do not have many people above me telling me what they think I should be having my team do.
It is possible to have a good project manager who knows next to nothing about technology. We always joke that one of our PMs could be running an automobile plant just as well as she helps run our projects. She knows practically nothing about what we do, but she can build project plans, set timelines and most importantly, keep people on task. When timelines start to slip, she is great at gathering feedback about why deadlines are being missed. That feedback then helps the rest of the team realign and keep things moving forward. Again, she knows next to nothing about the feedback she is being given, but that is not her job. Her job is to keep everyone in communication with each other, and ensure that everyone has visibility into the status of the project. Lastly, she is a great resource because every project she runs is run in an orderly, predictable kind of way. In the tech world, especially among developers, it is all too common to make things up as you go. (After all, that is what developers do. They develop things that were not there before. An inherently creative process). Our devs know what when they are done with their latest build, it will get pushed into test. They do not have to spend time pushing it to test. They do not have to build the process to push it to test. That process is already there for them. Same thing with soliciting UAT feedback. They do not have to gather the feedback. The PM gathers it, orders it, prioritizes it, and then makes it available to the manager(s) and developer(s) whose code needs to be refined.
Re:Two Flavors (Score:3, Interesting)
Think your problem mate
Is futile's one syllable
Though your point still stands
Re:Two Flavors (Score:5, Interesting)
Even without acting as a bridge to external people, simply having an educate but non-technical resource on hand is useful.
If you can't explain your project to your manager in terms they can understand, you have no hope of explaining it to the end-users, upper management, budget committees, etc. If your non-technical manager sees through your bullshit, its your clue you are doing it wrong.
Just as the act of merely explaining a problem to another programmer will often yield insight into the solution (without the other programmer saying a single word, or perhaps paying all that much attention), explaining stuff to a non-technical manager often helps with the design and implementation. The questions they ask will also be asked by others.
I agree with what you say, but the problem is giving this person authority over the group. You could have such a person who is within the group but not over it. My wife actually fulfills that role for me in my business, with a couple of select customers filling in if other knowledge is required that she doesn't have.
In my only actual "job" I had a non-technical manager who was good for most of the reasons that you say, but her cluelessness seriously held our group back in various ways. Her inability to understand at any level what we did and what a reasonable way to do it would be caused endless frustration. The "interfacing with other groups" and all that didn't work as she was too clueless and the rest of us had to carry on that responsibility. We were the internal IT department for an IT department within a larger organization, so all of these problems were amplified as the rest of the department was a bunch of nerds, also.
On the other hand, she did take time to teach me how to write project proposals and stuff like that in which she excelled. However, that means that in the end I had acquired her extremely limited skill set myself and added it to my otherwise very marketable skill set in programming, which made her of even *less* value to our team.
In case you think I'm pissed because I got burned, quite the opposite. She fought for me like nobody and even mentioned when I quit that my pay increase (as a percentage) during my time there was the highest in our department. I liked her as a person and think that she would have been highly effective in the right job. She had the motivation, was physically attractive (say what you want - it matters), and intelligence to be great at a lot of things. Tech just wasn't one of them.