4 ms·

A good manager minimizes the amount of time a developer has to spend on stuff that isn't developing. In the right situations, a good manager can make a team of

• user5994461 10y ago
  Most stuff isn't developing. Designing, planning, architecturing, reviewing, developing, testing, delivering, maintaining, presenting... That's all a developer's jobs. I don't think that they should be strictly limited to "that guy who's got a special job title" (architect, managers, lead, whatever).
  • jdbernard 10y ago
    The way I interpreted larrik's comment, he meant things like interfacing with other layers in the company, interfacing with other managers about the team's capacity for support, etc. Most of the things you mention I would include in "development". What you seem to call development I would specifically call implementation. Although, it can be beneficial to have different people for a lot of the things you mention, especially as a project grows in size and scope. And you need at least two people if you include review; reviewing one's own work is far less effective. Same with testing. Plenty of great devs are not great or don't like presenting, etc. If you do go the route of splitting responsibilities, you're going to be more efficient if you have someone coordinating their efforts, reducing the communication overhead for the whole team by being a central point of synchronization. That's one of the responsibilities of a good manager.
    • larrik 10y ago
      Your interpretation is indeed what I was aiming for.
• clueless123 10y ago
  In my book, the best managers should work for the team, not the other way around.
  • cookiecaper 10y ago
    Be careful with this. It's usually a sign of a political double-talker. The manager hasn't forgotten who he works for, even if he wishes you would.
    • jdbernard 10y ago
      Well, it depends. I've been in healthy situations where this was true. One company in particular where this was mostly true from the very top down. Of course, yes, there are plenty of situations where it is just double-talk.
      • cookiecaper 10y ago
        The manager isn't a good politician if you don't believe his bullshit. If the manager himself is a founder, former programmer, or otherwise both intimately familiar with and committed to the process that actually produces the outcome, he may understand the importance of the work and really be working to ensure his team has what it needs so they can do a good job for the company. He's still working for the company, but he appreciates and understands engineering, and since you're working together for common goals from a common understanding, your interests are aligned. You can almost always expect people to consider their field of expertise the nexus of the company's lifeblood, the critical component that everything will die without. Everything else will be considered tertiary. In the case of most managers, their expertise is schmoozing, and that's going to be their primary focus. To the extent that good engineering jeopardizes schmoozing, you can and should expect the manager to strongly prefer schmoozes.
        • lpr22 10y ago
          Why skip secondary and jump straight to tertiary? I've worked with a lot of really good managers who understand the role their group plays without having to delude themselves into thinking their team or function is primary. I think that's something that's really important regardless of the industry. The most enjoyable jobs I've had have been those where there was good, self-aware management. While bad management is obviously a horrible time all-around, I've also had very bad experiences in the so called flat, self-managed models. For those to work, the greater majority of the team need to actually be self-aware, good (at least self) managers.
• fuck_google 10y ago
  If management would be replaced with motivation, developers would be even more productive.