4 ms·

Because in software and other knowledge industries, feedback from the ICs is an essential component in determining which projects are worth working on (and what

Because in software and other knowledge industries, feedback from the ICs is an essential component in determining which projects are worth working on (and what their chance of success is, what other consequences they will have for the product, how long they'll take, how much they'll cost, etc). This was one of my biggest lessons transitioning to management. My biggest mistakes have all been cases where a feedback loop from engineering to PM/UX/leadership was missing and I failed to set one up. Biggest successes have been projects where I set that feedback loop up early and got out of the way, so that engineering and UX had a high-bandwidth communication pathway to negotiate issues and make product compromises based on real constraints. Unfortunately it feels like I'm swimming upstream when it comes to actual org policies here, which have forcibly reclassified me from a TLM to an Engineering Manager (so my official job duties now include assigning work, but not necessarily understanding the work I'm assigning), given me a reporting load that's too big to understand the details of each project I'm managing, made my report's performance reviews independent of how well they work with others and instead fully dependent on how much they please me, made my performance reviews largely independent of how well I support my team but very dependent on how well I please my superiors, and so on. Somebody in upper management wants people to be responsible for things and yet doesn't seem to know or care much about how to actually get results in a knowledge-based org.

ebiester 3y ago
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

ebiester 3y ago

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