4 ms·

I think a lot here miss the main point of the article. Managers used to be smarter than their subordinates, so they could steer the work. With knowledge work,

I think a lot here miss the main point of the article. Managers used to be smarter than their subordinates, so they could steer the work. With knowledge work, as soon as you turn manager, you're away from the knowledge. That means all of a sudden your subordinates are smarter than you. So where does that leave the manager? Well, as the article also kind of concludes, the manager is now at the service of the team. Big difference! Instead of coordinating and guiding the work, the manager now has to make sure the path is clear for the team to do their job. The manager deals with all the bullshit so the team doesn't have to. This also means that it will be hard for you to notice a great manager, but easy to notice a bad one.

TigeriusKirk 4y ago
>I think a lot here miss the main point of the article. People are very, very clearly reacting to the headline and making the same comments we've seen 1000 times before. It's a shame since the article itself is interesting and could stimulate actual novel conversation, but the chance for that is gone.
commandlinefan 4y ago
I'm reminded of football coaches. Some of them used to play football, but even then were rarely superstar players. They definitely can't suit up and take over for a missing player - yet they're held responsible for the wins and losses more than the players themselves, and the players have incredible respect and deference for what they do.
- koonsolo 4y ago
  I still feel football coaches bring more expertise on the table. They handle the strategy used and which player does what. For software development, those things should be in the hands of the developers and architects.
ska 4y ago
> you're away from the knowledge. That means all of a sudden your subordinates are smarter than you. This is incorrect in a subtle but important way: Being closer to "the knowledge" as you put it, doesn't change how smart you are, it changes how well informed/up to date you are. That being said, it's always better to hire people smarter than you if you can :) Similarly, being closer to "the knowledge" tends to make you poorly informed about other important aspects of your business, almost unavoidably. This information is often critical to actual success, more than IC's/engineers often realize. To some degree this is zero sum, and reflects where you spend your time. Done well, a good EM will be an interface between the goals (from above) and capabilities (from below) and keeping them aligned. This: > it will be hard for you to notice a great manager, but easy to notice a bad one. is very true. The corollary is that as an IC you often perform much better in a high functioning team with a good or great manager, but it's easy/comfortable to believe this is mostly yourself.
- koonsolo 4y ago
  > Similarly, being closer to "the knowledge" tends to make you poorly informed about other important aspects of your business, almost unavoidably. This information is often critical to actual success, more than IC's/engineers often realize. But the question is here the same: is the manager most informed to take the decisions? I would expect the functional analyst to know most about the domain and what is required, and the sales or business development people about how to extract money out of the customer. In all cases, I think the experts of all fields are at the lowest level. > Done well, a good EM will be an interface between the goals (from above) and capabilities (from below) and keeping them aligned. I agree that the vision needs to come from the top downwards. That means "where do we want to go", but the "how will we do this", is in my opinion all the people at the lowest levels. As for capabilities, a great manager will present what needs to be done to the team, and the team will decide what effort will be required.
  - ska 4y ago
    > is the manager most informed to take the decisions? Often, yes. Or at least knows who is, and how to put it to them. Put another way, the domain experts are usually the best people to describe the tradeoffs but often don't have a sufficiently broad view to make the decisions. Obviously this isn't universal - one key skill in engineering management is empowering your team to make all the decisions they can most usefully make, and facilitating their input to the ones they can't. > As for capabilities, a great manager will present what needs to be done to the team, and the team will decide what effort will be required. I think this really misses the point. With a great manager, a team will fire on all cylinders; rarely is this true without at least a good one (exceptions made for small, experienced teams in certain circumstances). You are describing more of a project manager "hat", which sometimes is worn by an engineering manager, but need not be.
lunias 4y ago
Whenever I feel like my management is not sufficiently technical or experienced I think of the construction foreman. I imagine what things would be like if you could become a foreman without ever learning construction yourself. How would that work? Software development at some companies often seems like that. The person in the position of leadership is instead led (at the expense of productivity) by the people they're meant to lead. Of course this would never be allowed in a field where there are serious non-reversible consequences of negligence stemming from a lack of knowledge. I feel like this is largely a phenomenon local to software development.

TigeriusKirk 4y ago

>I think a lot here miss the main point of the article. People are very, very clearly reacting to the headline and making the same comments we've seen 1000 times before. It's a shame since the article itself is interesting and could stimulate actual novel conversation, but the chance for that is gone.

commandlinefan 4y ago

I'm reminded of football coaches. Some of them used to play football, but even then were rarely superstar players. They definitely can't suit up and take over for a missing player - yet they're held responsible for the wins and losses more than the players themselves, and the players have incredible respect and deference for what they do.

koonsolo 4y ago
I still feel football coaches bring more expertise on the table. They handle the strategy used and which player does what. For software development, those things should be in the hands of the developers and architects.

ska 4y ago

> you're away from the knowledge. That means all of a sudden your subordinates are smarter than you. This is incorrect in a subtle but important way: Being closer to "the knowledge" as you put it, doesn't change how smart you are, it changes how well informed/up to date you are. That being said, it's always better to hire people smarter than you if you can :) Similarly, being closer to "the knowledge" tends to make you poorly informed about other important aspects of your business, almost unavoidably. This information is often critical to actual success, more than IC's/engineers often realize. To some degree this is zero sum, and reflects where you spend your time. Done well, a good EM will be an interface between the goals (from above) and capabilities (from below) and keeping them aligned. This: > it will be hard for you to notice a great manager, but easy to notice a bad one. is very true. The corollary is that as an IC you often perform much better in a high functioning team with a good or great manager, but it's easy/comfortable to believe this is mostly yourself.

koonsolo 4y ago
> Similarly, being closer to "the knowledge" tends to make you poorly informed about other important aspects of your business, almost unavoidably. This information is often critical to actual success, more than IC's/engineers often realize. But the question is here the same: is the manager most informed to take the decisions? I would expect the functional analyst to know most about the domain and what is required, and the sales or business development people about how to extract money out of the customer. In all cases, I think the experts of all fields are at the lowest level. > Done well, a good EM will be an interface between the goals (from above) and capabilities (from below) and keeping them aligned. I agree that the vision needs to come from the top downwards. That means "where do we want to go", but the "how will we do this", is in my opinion all the people at the lowest levels. As for capabilities, a great manager will present what needs to be done to the team, and the team will decide what effort will be required.
- ska 4y ago
  > is the manager most informed to take the decisions? Often, yes. Or at least knows who is, and how to put it to them. Put another way, the domain experts are usually the best people to describe the tradeoffs but often don't have a sufficiently broad view to make the decisions. Obviously this isn't universal - one key skill in engineering management is empowering your team to make all the decisions they can most usefully make, and facilitating their input to the ones they can't. > As for capabilities, a great manager will present what needs to be done to the team, and the team will decide what effort will be required. I think this really misses the point. With a great manager, a team will fire on all cylinders; rarely is this true without at least a good one (exceptions made for small, experienced teams in certain circumstances). You are describing more of a project manager "hat", which sometimes is worn by an engineering manager, but need not be.

lunias 4y ago

Whenever I feel like my management is not sufficiently technical or experienced I think of the construction foreman. I imagine what things would be like if you could become a foreman without ever learning construction yourself. How would that work? Software development at some companies often seems like that. The person in the position of leadership is instead led (at the expense of productivity) by the people they're meant to lead. Of course this would never be allowed in a field where there are serious non-reversible consequences of negligence stemming from a lack of knowledge. I feel like this is largely a phenomenon local to software development.