3 ms·

I'm sorry but that is a pathetic infantilization of IC's, and a complete misunderstanding of what "line managers" job is. I'll let some manager explain why you

I'm sorry but that is a pathetic infantilization of IC's, and a complete misunderstanding of what "line managers" job is. I'll let some manager explain why you're misrepresenting the responsibilities of managers, but as an IC I can tell you I would be offended if any manager I worked with acted like it was THEIR Job to understand what is the right thing is, then just tell me what to do as part of that. And it pisses me off when other IC's I work with don't seek or desire agency. By the way just knowing WHAT to do is only part of the task - HOW to do it is another one that also requires collaboration between technical IC's - whiteboarding, pair programming, etc.

ebiester 3y ago
You misunderstand me, perhaps. It is not the manager's responsibility to "just tell [you] what to do as part of that." The job of the line manager is to take a giant amount of information and develop a mental map in which he can present the context to the team. It isn't that an IC cannot do this (though I see this as more rare than I would like!) but rather if an IC did this, they would be in 20 hours of meetings. "The right thing," in this case, is not breaking down the tasks into mindless coffee to code, but rather "Four of our customers are really frustrated by the lack of this feature, so our PM has prioritized it. It's in an area we've identified as having some technical debt. Design has a proposed idea of how we could solve it. Talking with support, two of these customers are enterprise and want more ability to customize to their processes, and two are mid-market and would rather it was easy to use. This is going to touch an area you all have identified as having technical debt, so it'd be great if we could use some of that time to make progress in cleaning it up. We'd ideally like to constrain this to three months of work. Now, team, how much is possible given those constraints? What scope do we need to cut if it all won't fit?" That cliffs notes can be as a result of 20 hours of meetings and research. Now, it's the team's job to take that brief and work toward the art of the possible and help the team if they also need to talk with the stakeholders to gather more information. However, somebody needs to do that work. That person needs to have a technical background at the senior level, a high tolerance for meetings, the ability to work across the organization and maintain relationships, an understanding of business as a craft, and an understanding of the domain. Can a senior engineer do all that? Sure! However, it is hard to do all of that and have as much time to actually code. And most individual contributors start losing joy in the job if that becomes a significant portion of the job. (That, or they end up as managers.) In truth, we could completely divorce this role from people management. The authority is the least interesting part of the job, and is a relatively small portion of it. But even if you completely went to a communist, non-hierarchical system, you would still need someone to work in this role.

ebiester 3y ago

You misunderstand me, perhaps. It is not the manager's responsibility to "just tell [you] what to do as part of that." The job of the line manager is to take a giant amount of information and develop a mental map in which he can present the context to the team. It isn't that an IC cannot do this (though I see this as more rare than I would like!) but rather if an IC did this, they would be in 20 hours of meetings. "The right thing," in this case, is not breaking down the tasks into mindless coffee to code, but rather "Four of our customers are really frustrated by the lack of this feature, so our PM has prioritized it. It's in an area we've identified as having some technical debt. Design has a proposed idea of how we could solve it. Talking with support, two of these customers are enterprise and want more ability to customize to their processes, and two are mid-market and would rather it was easy to use. This is going to touch an area you all have identified as having technical debt, so it'd be great if we could use some of that time to make progress in cleaning it up. We'd ideally like to constrain this to three months of work. Now, team, how much is possible given those constraints? What scope do we need to cut if it all won't fit?" That cliffs notes can be as a result of 20 hours of meetings and research. Now, it's the team's job to take that brief and work toward the art of the possible and help the team if they also need to talk with the stakeholders to gather more information. However, somebody needs to do that work. That person needs to have a technical background at the senior level, a high tolerance for meetings, the ability to work across the organization and maintain relationships, an understanding of business as a craft, and an understanding of the domain. Can a senior engineer do all that? Sure! However, it is hard to do all of that and have as much time to actually code. And most individual contributors start losing joy in the job if that becomes a significant portion of the job. (That, or they end up as managers.) In truth, we could completely divorce this role from people management. The authority is the least interesting part of the job, and is a relatively small portion of it. But even if you completely went to a communist, non-hierarchical system, you would still need someone to work in this role.