5 ms·

Maybe you are correct. But ICs do not decide what to work on, the PMs and other leadership do. So why can’t ICs continue working from home while the “deciders”

Maybe you are correct. But ICs do not decide what to work on, the PMs and other leadership do. So why can’t ICs continue working from home while the “deciders” go back to the office?

dehrmann 3y ago
Maybe entry-level ICs and ICs in bad orgs, but good PMs know that the ICs building the product will have some amount of insight into its usage and pain points.
- cableshaft 3y ago
  That's what scheduled meetings and Slack is for. I have scheduled meetings with the PM to discuss business requirements for upcoming features once every couple of weeks on average, and sometimes she pings me to ask questions outside of it or have an impromptu Slack call with screen sharing. It's not worth me driving an hour and a half to the office (and her flying from many states away) just so we can discuss these things in person. And the product is coming along very well. We just had a successful demo that impressed a lot of people and secured another year of funding. And this is the third major product I've worked on entirely remote, all have done very well. That's not including the video games I developed along with artists that I never met in person that also did well back in the day, where we only communicated with text via AOL Instant Messenger and sending files to each other via email.
- ParetoOptimal 3y ago
  You literally can't be an effective IC without deeply learning the domain. Leadership and managers that don't take advantage of this and instead "listen to their gut" are gambling.
fooster 3y ago
If you work for a shitty organization sure. In a well functioning org, that isn't the case. Leadership/PM should help set direction, but not specifics.
nostrademons 3y ago
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.
ParetoOptimal 3y ago
Only the bad places decide what to work on based on leadership and manager input without signification IC feedback. Most places are bad.
marcosdumay 3y ago
What weird workplace is that where PMs are not ICs? Is it this way because they have "manager" on the task name?

Maybe you are correct. But ICs do not decide what to work on, the PMs and other leadership do. So why can’t ICs continue working from home while the “deciders” go back to the office?

dehrmann 3y ago

Maybe entry-level ICs and ICs in bad orgs, but good PMs know that the ICs building the product will have some amount of insight into its usage and pain points.

cableshaft 3y ago
That's what scheduled meetings and Slack is for. I have scheduled meetings with the PM to discuss business requirements for upcoming features once every couple of weeks on average, and sometimes she pings me to ask questions outside of it or have an impromptu Slack call with screen sharing. It's not worth me driving an hour and a half to the office (and her flying from many states away) just so we can discuss these things in person. And the product is coming along very well. We just had a successful demo that impressed a lot of people and secured another year of funding. And this is the third major product I've worked on entirely remote, all have done very well. That's not including the video games I developed along with artists that I never met in person that also did well back in the day, where we only communicated with text via AOL Instant Messenger and sending files to each other via email.
ParetoOptimal 3y ago
You literally can't be an effective IC without deeply learning the domain. Leadership and managers that don't take advantage of this and instead "listen to their gut" are gambling.

fooster 3y ago

If you work for a shitty organization sure. In a well functioning org, that isn't the case. Leadership/PM should help set direction, but not specifics.

nostrademons 3y ago

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.

ParetoOptimal 3y ago

Only the bad places decide what to work on based on leadership and manager input without signification IC feedback. Most places are bad.

marcosdumay 3y ago

What weird workplace is that where PMs are not ICs? Is it this way because they have "manager" on the task name?