5 ms·

What do technical managers do, anyway?

• bane 14y ago
  An interesting and accurate allusion, and one I'm quite fond of, technical managers herd nerds.
• sputknick 14y ago
  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).
• andrewdubinsky 14y ago
  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?
  • jborden13 14y ago
    Beat me to it...
• deleted 14y ago
  [deleted]
• arethuza 14y ago
  There are only two options for managers: "You can either be a shit funnel, or a shit umbrella." http://www.kevgibbs.com/2011/08/3-suggestions-for-engineering-managers http://www.kevgibbs.com/2011/08/3-suggestions-for-engineerin... 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.... :-)
  • justjimmy 14y ago
    "You can either be a shit funnel, or a shit umbrella." Thank you painting such a vivid imagery in my mind with that metaphor… :O
    • T-hawk 14y ago
      The term may have originated here (edit - actually, probably not based on the publication dates.) But it's where I first saw it: http://bitquabit.com/post/coding-is-priority-number-five/ http://bitquabit.com/post/coding-is-priority-number-five/
  • freework 14y ago
    If you're a shit funnel, the people you're managing will hate you, but the people above you will love you. If you're a shit umbrella, the people below you will love you, but the people above you will hate you. The people below you aren't the ones who hand out promotions.
    • mrbird 14y ago
      In Silicon Valley startups, the most valuable thing you can provide, as a manager, is the ability to attract a great team. When startups look to hire a manager, it's almost always with growth in mind. Your career is an opportunity to build a group of people who will follow you anywhere, thus making you very valuable yourself. Getting people to love working for you, while still making execs happy, is a non-trivial skill. Therefore, the best way to be successful as a manager, in the long term, is for people to love working for you. You will get amazing results. They might not be exactly what the people above you asked for, but that's where your skill is required--show that it's better and that they can trust you and your team more than they thought.
    • SoftwareMaven 14y ago
      I have experienced every negative thing that can come from being an umbrella, to the point people on other teams hated my team because they were happier. If you go that path, expect negative reactions from everybody (except your team, that is, which was all I cared about).
• g123g 14y ago
  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. 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. 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. There is no technical input from the managers as this takes lot of time and is somehow beneath them. With agile processes, the team manages their work flow on a day to day basis. So the manager role is reduced even further. 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. 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.
  • greendot 14y ago
    That sounds like a rather sad state of affairs. What kind of company do you work at anyway?
    • g123g 14y ago
      I work for a large software company with about 11,000 employees.
  • pmichaud 14y ago
    I think you have an unrealistic view of how well a large team of engineers can "self organize." It's hard to keep track of the 10,000ft view when that's your job, it's nearly impossible when you're in the thick of code, in some subsection of the overall application.
  • 14y ago
• ricardobeat 14y ago
  Where does technical fit in? That sounds like a plain old PM.
  • greendot 14y ago
    How many plain old PMs know how to code? How many plain old PMs mentor the developers and lead the code reviews?
• SpaffTwats 14y ago
  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.
• tsunamifury 14y ago
  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. 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. 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.
  • randomdata 14y ago
    > For example I have to set and square requirements of a technical nature (sometimes down to details) with each of these parties. Without knowing the specifics of your company, this feels like a needless managerial role. These are the things you want to trust your people with, so you can focus on the bigger picture. I mean, if you are taking away technical planning from an engineer, what real engineering work is left? Your final paragraph is a better example of the manager's role. To shield the outside world. To deal with problems of the people on the outside (clients, investors, etc.). The team should come to you with problems that arise, but you should generally not need to go to the team at all.
• logical42 14y ago
  They're people persons.
  • logical42 14y ago
    That was an office space reference, btw.
  • newobj 14y ago
    I don't think Smykowski was a manager in Office Space.
• erjjones 14y ago
  GitHub seems to be doing just fine without managers .. http://gigaom.com/2012/03/26/tales-from-the-trenches-github/ http://gigaom.com/2012/03/26/tales-from-the-trenches-github/ .. from an end user's perspective.
  • doktrin 14y ago
    I admire GitHub's organization and structure more than most, but we can't pretend they're a run of the mill business. The bar to get hired as an engineer, for instance, is not trivial. Once you have the ability to cherry pick your hires, you can also better select for fit (in this case, capacity to be self-driven on a mostly-remote team). Also on a purely product-related note, their UX has always (personally) felt lacking.
• freework 14y ago
  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.
• analyst74 14y ago
  I like this article, but I disagree with one point about task assignment. 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. 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. 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. 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.
  • msrpotus 14y ago
    Not always. There are always disagreements on teams; generally they can be resolved among the participants but not always and especially not on issues where everyone has strongly held opinions.
  • g123g 14y ago
    This is a very valid point. Most managers think communicating the immediate work load of the team is their only responsibility. But most of the time the team really needs to know the bigger picture. What is the future direction of the company, product etc. and most of the managers are really stingy with these types of details. This behavior results in lot of duplication of efforts. Managers are happy as they have something to show in their status reports. But in the long run, it reduces the overall product quality as most engineering decisions cannot be prudently taken without having the bigger picture in your head.
• achiang 14y ago
  I go to meetings so my team doesn't have to. 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. 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. 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.. 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 a decision, else the team wastes too much time bike-shedding. 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.
  • nolanbrown23 14y ago
    This is one of the best answers here. As a technical manager I go to meetings so my team doesn't have to. I answer the emails and questions so my team doesn't have to. The code I work on is to support my team and keep the little stuff off their plate and to make their job easier. I prioritize work based on what they're currently working on so they aren't moving from one part of the code base unnecessarily while still managing the external team priorities. I act as a coach/recruiter to hire the best team possible and give them the tools they need to succeed. TL;DR; I prevent interruptions: http://news.ycombinator.com/item?id=5092589 http://news.ycombinator.com/item?id=5092589
• tensor 14y ago
  Here is my take on the problem between managers and other employees: 1) Money. 2) Control. 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. 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. 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 do have the technical background, and get paid less on top, will have an issue with this. I suspect that these are the true problems in the room, but ones that nobody wants to address.
• jpatte 14y ago
  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 code for years going to make me any good in dealing with people in the future?