4 ms·

That's your job as a line manager. Your job is to understand the domain. Your job is to talk with users and technical support staff and product managers and re

That's your job as a line manager. Your job is to understand the domain. Your job is to talk with users and technical support staff and product managers and read about the domain and care about what your users care about. From there, your job is to explain what you have gathered, connect it to the technical challenges, and explain this to the ICs and work with them to make sure they understand what the right thing is. You can do all of this on zoom calls and sending links for them to read and reinforcing this in every 1:1. Ask them questions about what they understand about the product and why it matters. And if your reporting load is too high to dive in deep, you need to delegate many of those tasks. Explain why you are delegating them - writing a status is not the most fun task for an IC but you can use that to distill what your managers need to support the team.

nostrademons 3y ago
There's still something missing in your description in that the point of having large organizations of knowledge workers is to shard the mental context across multiple brains. As a manager of 10, unless I am hiring very stupid people, there is no way that my knowledge base is a superset of the knowledge of all 10. There's also no way that I can talk with all 3 billion users of my product or the nonexistent technical support staff - but luckily I work with a few really good PMs and data analysts that have a decent understanding of the market. My job is to have a low-fidelity representation of what's in their heads, plus enough of an understanding of the problem to understand what sort of people need to be involved, and then connect the right people and give them enough context on the goals and other folks involved that they can work out the details themselves. I can do this over zoom calls & docs & links - my team is half remote, and they continue to be productive. But it's a lot less efficient. When everybody's at the office, ICs talk amongst themselves, if they're missing context on product goals or an important change to the codebase they'll hear it from their coworkers, if management is making a bone-headed decision they'll talk amongst themselves and eventually it'll generate enough buzz that it'll get reversed. The model of "manager figures out what to do and then tells remote employees" lacks this resilience, and these feedback points. Employees are usually pretty well incentivized to not tell their manager directly when the manager is screwing up (although I actually have a couple directs that are good at this, and I listen closely to it), and when touch-points all go through the manager and people see their job as to execute on what the manager decides, that information that "hey, this plan doesn't make any sense" doesn't really have a good way to bubble up.
- existencebox 3y ago
  As another hybrid "TLM->EM" with a similarly sized team, over a similarly sized product, I definitely feel many of the same pain points you call out. BUT. And I say this with all respect, since I broadly find a lot of value in your comments: I strongly disagree to your assertion that remote "is less efficient." My theory to what is happening is that there are existing methodologies people are used to working in, including 'hacks' to build consensus that were developed in an in-person environment. (Namely, pulling a bunch of people into a room and arguing it out.) My perspective is that remote work makes a bunch of things that are just as critical in-person (shared documentation, good communication channels, trust and rapport, etc etc) non-optional, and your previous hacks far less effective. But I don't see this as a bad thing. If anything, it's like a strongly typed language: It forces you into a more effective pathway. (For instance, imagine how remote folks or even folks-just-not-around-at-the-moment felt in not being able to participate evenly in the "in-person-bash-it-out" sessions or hallway chats without a strong culture of proliferating knowledge and documentation?) While you may reasonably say "Ok, that's fine, people built up methodologies, why flip it on its head and disrupt a status quo that works" to which I'd emphasize the "we were relying on suboptimal ways to build consensus, and it was a local maxima." I would also propose that I believe a good manager _HAS_ to change their methodologies in some ways more disruptively than just the local/remote shift when dealing with certain styles of employee, (their own) manager, and org+busines structure/process/incentives, and as such, this should just be part and parcel with the constant process of adapting to refine your own methods and style. (As an aside, I was tempted to make this comment on your upstream comment[0] talking about "maybe I'm not actually succeeding, it feels like winning at a fucked up system" since I definitely feel you there. I got into management in large part out of a "I'm frustrated by how management is often done and how it ends up percolating down to ICs, and I want to put my money where my mouth is that there's a better approach", and while I definitely feel like I've succeeded in some respects, and continue to get "rewarded" as you say, I'm intimately aware that I'm likely still screwing things up/finding the optimal way to balance pathological incentives, and still have a ton to learn. In short, I'd not be surprised if both of us are "doing fine but still have blind spots," so please take my above just as one person's opinions/"attempt to draw the elephant" :) ) [0] https://news.ycombinator.com/item?id=38984369 https://news.ycombinator.com/item?id=38984369
deanCommie 3y ago
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.
lifeisstillgood 3y ago
Like other comments there seems to be an implied “managers as superman” here- and it’s not a surprise - perhaps the last fifty or hundred years have mixed “aristocracy”, “elite”, and “white collar management”. It’s hard for even trades Union fish to see water. Anyway, I think we are seeing a rethinking of what management is - and that will have implications for elite / aristocracy as well. There will be a fight. My two cents are that the “workers” for many industries are moving from human beings to CPUs. There are amazing photos of rooms of “accountants” simply adding numbers on adding machines which are passed up the line till the corporation gets a final number. Each of those got replaced with whatever IBM made in 1956 (besides Fortran). The manager of that room of humans suddenly stopped worrying about Bob’s attitude and had to worry about silicon. Something less obvious and photogenic has been happening for years. Coders in short are the new managers (supervisors) But we have three other jobs of “management” - technical lead : understands the details of his area deeply and can make trade offs and build a better engineered product (ie door plugs that don’t fall out) Product management- honestly I remain dubious about this as a category - with good user communication a tech lead can do most of this, until we shade into strongly fashion / FMCG - organisational manager - someone looking at the needs of the org - how will this affect the nebulous idea of the company. This is the point at which politics takes over - this level of management is primarily running budgets 100x their own salary and so can be seen more as financier or VC than part of the company. However this is how for example the Post Office justifies jailing it’s own employees I am wandering off the point a bit - paint fumes I suspect, but there is one final point to make - management differs above from working in the company - on day to day operations - and working on changing the company - new projects and initiatives. Theoretically the cut off is supervisory (ie. Coders are new managers) But that’s never true - most innovation bubbles up and is then selected in a competition by various hierarchies I think the point I am making is that we do not need superman as manager - we need properly aligned systems and incentives, which I suspect only happens in open daylight
- ebiester 3y ago
  Peter Drucker proposes this (that as more is automated, more people end up as effective managers) in "The Effective Executive" over fifty years ago. But I have a blog I'm half in the middle of that dives deeper here. The manager is less "superman" and more a collection of part time jobs, one of which is to be contextual hubs for the organization. Within most IT organizations, it is their job to gather information from across and outside the organization. That isn't as much a "superhuman" job as much as a role that takes a job. The real problem is that we tied "people management" to this job. I don't think that's a necessary feature but rather a historical coincidence.

nostrademons 3y ago

There's still something missing in your description in that the point of having large organizations of knowledge workers is to shard the mental context across multiple brains. As a manager of 10, unless I am hiring very stupid people, there is no way that my knowledge base is a superset of the knowledge of all 10. There's also no way that I can talk with all 3 billion users of my product or the nonexistent technical support staff - but luckily I work with a few really good PMs and data analysts that have a decent understanding of the market. My job is to have a low-fidelity representation of what's in their heads, plus enough of an understanding of the problem to understand what sort of people need to be involved, and then connect the right people and give them enough context on the goals and other folks involved that they can work out the details themselves. I can do this over zoom calls & docs & links - my team is half remote, and they continue to be productive. But it's a lot less efficient. When everybody's at the office, ICs talk amongst themselves, if they're missing context on product goals or an important change to the codebase they'll hear it from their coworkers, if management is making a bone-headed decision they'll talk amongst themselves and eventually it'll generate enough buzz that it'll get reversed. The model of "manager figures out what to do and then tells remote employees" lacks this resilience, and these feedback points. Employees are usually pretty well incentivized to not tell their manager directly when the manager is screwing up (although I actually have a couple directs that are good at this, and I listen closely to it), and when touch-points all go through the manager and people see their job as to execute on what the manager decides, that information that "hey, this plan doesn't make any sense" doesn't really have a good way to bubble up.

existencebox 3y ago
As another hybrid "TLM->EM" with a similarly sized team, over a similarly sized product, I definitely feel many of the same pain points you call out. BUT. And I say this with all respect, since I broadly find a lot of value in your comments: I strongly disagree to your assertion that remote "is less efficient." My theory to what is happening is that there are existing methodologies people are used to working in, including 'hacks' to build consensus that were developed in an in-person environment. (Namely, pulling a bunch of people into a room and arguing it out.) My perspective is that remote work makes a bunch of things that are just as critical in-person (shared documentation, good communication channels, trust and rapport, etc etc) non-optional, and your previous hacks far less effective. But I don't see this as a bad thing. If anything, it's like a strongly typed language: It forces you into a more effective pathway. (For instance, imagine how remote folks or even folks-just-not-around-at-the-moment felt in not being able to participate evenly in the "in-person-bash-it-out" sessions or hallway chats without a strong culture of proliferating knowledge and documentation?) While you may reasonably say "Ok, that's fine, people built up methodologies, why flip it on its head and disrupt a status quo that works" to which I'd emphasize the "we were relying on suboptimal ways to build consensus, and it was a local maxima." I would also propose that I believe a good manager _HAS_ to change their methodologies in some ways more disruptively than just the local/remote shift when dealing with certain styles of employee, (their own) manager, and org+busines structure/process/incentives, and as such, this should just be part and parcel with the constant process of adapting to refine your own methods and style. (As an aside, I was tempted to make this comment on your upstream comment[0] talking about "maybe I'm not actually succeeding, it feels like winning at a fucked up system" since I definitely feel you there. I got into management in large part out of a "I'm frustrated by how management is often done and how it ends up percolating down to ICs, and I want to put my money where my mouth is that there's a better approach", and while I definitely feel like I've succeeded in some respects, and continue to get "rewarded" as you say, I'm intimately aware that I'm likely still screwing things up/finding the optimal way to balance pathological incentives, and still have a ton to learn. In short, I'd not be surprised if both of us are "doing fine but still have blind spots," so please take my above just as one person's opinions/"attempt to draw the elephant" :) ) [0] https://news.ycombinator.com/item?id=38984369 https://news.ycombinator.com/item?id=38984369

deanCommie 3y ago

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.

lifeisstillgood 3y ago

Like other comments there seems to be an implied “managers as superman” here- and it’s not a surprise - perhaps the last fifty or hundred years have mixed “aristocracy”, “elite”, and “white collar management”. It’s hard for even trades Union fish to see water. Anyway, I think we are seeing a rethinking of what management is - and that will have implications for elite / aristocracy as well. There will be a fight. My two cents are that the “workers” for many industries are moving from human beings to CPUs. There are amazing photos of rooms of “accountants” simply adding numbers on adding machines which are passed up the line till the corporation gets a final number. Each of those got replaced with whatever IBM made in 1956 (besides Fortran). The manager of that room of humans suddenly stopped worrying about Bob’s attitude and had to worry about silicon. Something less obvious and photogenic has been happening for years. Coders in short are the new managers (supervisors) But we have three other jobs of “management” - technical lead : understands the details of his area deeply and can make trade offs and build a better engineered product (ie door plugs that don’t fall out) Product management- honestly I remain dubious about this as a category - with good user communication a tech lead can do most of this, until we shade into strongly fashion / FMCG - organisational manager - someone looking at the needs of the org - how will this affect the nebulous idea of the company. This is the point at which politics takes over - this level of management is primarily running budgets 100x their own salary and so can be seen more as financier or VC than part of the company. However this is how for example the Post Office justifies jailing it’s own employees I am wandering off the point a bit - paint fumes I suspect, but there is one final point to make - management differs above from working in the company - on day to day operations - and working on changing the company - new projects and initiatives. Theoretically the cut off is supervisory (ie. Coders are new managers) But that’s never true - most innovation bubbles up and is then selected in a competition by various hierarchies I think the point I am making is that we do not need superman as manager - we need properly aligned systems and incentives, which I suspect only happens in open daylight

ebiester 3y ago
Peter Drucker proposes this (that as more is automated, more people end up as effective managers) in "The Effective Executive" over fifty years ago. But I have a blog I'm half in the middle of that dives deeper here. The manager is less "superman" and more a collection of part time jobs, one of which is to be contextual hubs for the organization. Within most IT organizations, it is their job to gather information from across and outside the organization. That isn't as much a "superhuman" job as much as a role that takes a job. The real problem is that we tied "people management" to this job. I don't think that's a necessary feature but rather a historical coincidence.