Most of the managers that I have come across are not worth the paper on which their job description is printed. I am talking about the middle level managers here.<p>There is some adhoc planning going on at this level but most of the time it is dictated by what is being conveyed from the top. This takes care of all the planning, task assignment work. If the manager has capable team members then all that is required is to just tell them that they are now going to work on project X. After that it is the responsibility of those team members to manage the work. All that the so called managers do is check periodically about how it is going.<p>Recruitment of engineers is again completely left to senior engineers. Once 3 senior engineers say yes to a candidate, the manager just has to complete the formalities. So there is no contribution in building better teams.<p>There is no technical input from the managers as this takes lot of time and is somehow beneath them.<p>With agile processes, the team manages their work flow on a day to day basis. So the manager role is reduced even further.<p>All they work on is performance review once a year. It is more of a give and take as the manager and his manager don't have any realistic idea of an individual's contribution.<p>I think time has come to cull the managers rank and just have 1 manager for 100 developers with developers organizing themselves in self-managing teams. The managers just get too much credit and money for doing essentially nothing.
There are only two options for managers:<p>"You can either be a shit funnel, or a shit umbrella."<p><a href="http://www.kevgibbs.com/2011/08/3-suggestions-for-engineering-managers" rel="nofollow">http://www.kevgibbs.com/2011/08/3-suggestions-for-engineerin...</a><p>If you do the former then your reports hate you, if you do the latter then they like you but wonder what it is you actually do.... :-)
I go to meetings so my team doesn't have to.<p>As an engineering-driven company, both daily tactical decisions and our overall strategic decisions are (usually!) based on technical data. This requires our management team to understand enough of the technical details in order to make sane decisions around product, forecasting, marketing, technical partnerships, etc.<p>It's important to note that I don't necessarily view the above tasks as more "important" than engineering. They're simply other business functions that need to happen for the business to work, and it's more efficient if I do it in my role rather than taking time away from actual development to provide the data we need for those functions.<p>Another function I serve on my team is technical tiebreaker. I work hand-in-hand with my tech lead, delegating most of the daily responsibilities to him, but when the team is mired in debate, I either cast a tiebreaker vote or if I don't know enough about $TOPIC, I can at least ask some questions to get them to consider the issue from different perspectives, which is enough to make progress in the debate..<p>Again, I note that the fulfilling the above job function doesn't mean I'm smarter than my tech lead (I'm not). But engineering isn't as black and white as we want it to be, and ofttimes we just need to make <i>a</i> decision, else the team wastes too much time bike-shedding.<p>A good manager is like a good IT guy. If he/she is doing the job properly, the team is only ever rarely aware of it. And that's just the way I like it.
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?
IT manager. your list is almost perfect, I think you left one very key role off. The manager is responsible for ensuring the future of the team. This means ensuring that once whatever they are working on now is completed, that there is work coming up behind that. That can mean BD outside the company, or more often sales internal to the company to ensure your people are picked for the next big project. I like to break down my job into past (recognition, raises), present (evaluation, guidance, material support), and future (new work coming down the pike).
I manage a set of engineers, a content team, a graphics team, and a QA team. I know a lot of engineers like to say "managers don't do anything" but thats often when they take a painfully narrow view on production.<p>For example I have to set and square requirements of a technical nature (sometimes down to details) with each of these parties. Decisions like which image format will be best from a size/performance/integration perspective need to be agreed upon by all teams, up to approving designs, ensuring engineering implements them exactly, approving the UX, and making sure the QA team tests for all those standards set. Sometimes I have sit the engineers down and do a brief code-review to ensure they are following the overall architecture of the larger system.<p>Managers do those details on TOP of all the basic things like team budget, hiring/firing, recruitment, organizing new incoming work, and taking care of small HR issues. And at times we have to step in and do the work of any of those teams OURSELVES if there is a temporary gap. That includes and is not limited to coding, designing, and QAing.
Here is my take on the problem between managers and other employees:<p>1) Money.<p>2) Control.<p>The first is obvious. Managers tend to make more than others. From the point of view of an engineer, the manager is doing an easier job that requires much less training. Thus, they should, if anything, earn less, not more.<p>On the second topic, many managers seem to come from the view "I am boss. You do as I say." Rather than the view of "My job is to make your life easier. How can I help?" The former view will naturally create a lot of friction.<p>The other problem with control comes back, once again, to background. Managers that were previously engineers generally get a pass. But it seems that in some cases you have managers making technical decisions without the required technical background. Unsurprisingly, the people who <i>do</i> have the technical background, and get paid less on top, will have an issue with this.<p>I suspect that these are the true problems in the room, but ones that nobody wants to address.
I like this article, but I disagree with one point about task assignment.<p>Good engineering decisions are always based on the big picture like long/short term goal, budget and deadline. By keeping those in mind, an engineer can then go and understand task priority, and decide which solution might be best for each task.<p>If an engineer team understands the bigger picture, they can in most part self-manage and figure out what to do to achieve the end goal.<p>However if a manager or PM shields engineers from those bigger pictures, it becomes much harder to make informed engineering decisions on individual tasks, or how to allocate time among those tasks, causing slipped deadline and over budget. This reinforces the impression that managers should provide closer guidance on what to do.<p>In my experience, most technical manager/project manager will only talk about the bigger picture when pressed, and only some are able to describe it clearly.
GitHub seems to be doing just fine without managers .. <a href="http://gigaom.com/2012/03/26/tales-from-the-trenches-github/" rel="nofollow">http://gigaom.com/2012/03/26/tales-from-the-trenches-github/</a> .. from an end user's perspective.
By reading this "job description" for project managers I still wonder why on earth would people think management is a natural step in a developer's career path (at least here in Europe). These are different jobs entirely! How are the experience, knowledge and skills I earned from studying and writing <i>code</i> for years going to make me any good in dealing with <i>people</i> in the future?
A manager's job is to remove all obstacles in the team's path. This doesn't mean telling them what to do, and it doesn't involve making their technical decisions for them.
The manager's job is to solve people problems. Most developers are great at analytical thinking, but very bad at emotional thinking. Nerds are usually introverted, and moody, in my experience. Great managers are the opposite of nerds. They are extroverted, warm, communicative, cheery, and, (for the lack of a better term) dumb. Its a huge mistake to put a nerd in a manager role, as much as it is a mistake to put a manager in a programmer role. I've worked under my fare share of "nerd managers" as well as "manager programmers". Both do more hard than good.