3 ms·

> That assumes the engineers can prioritize the tasks It doesn't. If the product manager is prioritizing things, he or she invariably gets backlash from the en

> That assumes the engineers can prioritize the tasks It doesn't. If the product manager is prioritizing things, he or she invariably gets backlash from the engineers when they put forward that they're swamped and can't deliver unless they deal with X, Y, Z first. > and can't just get the list of frequent issues from support Which are then, all too often in my experience, ignored or downplayed by whoever prioritizes tasks over at engineering. When the engineers have skin in the support game, they pay extra attention to what may or may not lighten their "not very fun" workload.

afarrell 8y ago
No, this strategy really does depend on the engineers having a good way to prioritize things. If you have engineers doing level-2 support and you have product managers saying "Do this other thing", then the engineer now repeatedly has to resolve a conflict among the possibilities of: A) Check email and slack to see if something new has come in. B) Check your error reporting/monitoring to see if Sentry has reported any new exceptions/errors from existing services. C) Issue #1 from a customer D) Issue #2 from a different sort of customer who has more revenue impact E) Issue #3 which was actually bubbled up from someone in sales. F) Non-urgent but important Project X from the product manager which you are actually 30% of the way finished with and consequently, it is the thing that is sitting in your brain. G) Check hackernews as a salve to the stress of a bunch of ambiguously-prioritized tasks. Accomplishing engineering tasks requires allocating your brain's working memory and directing your focus on ONE thing at a time. The harder that is, the harder it is to do anything but option G. If you put engineers in this situation, but you don't give engineers the training and structure to arbitrate decisions about prioritization, then you're setting them up for needless conflict and failure. If you just designate all of your engineers as being responsible for level-2 support without any additional structured then each one needs to tell the product manager, "I'm not going to work on this project which will bring the company $X Monthly Recurring Revenue for another week, but I'm going to deal with these support requests. I am in charge of prioritizing what gets worked on. Your job as a product manager is not to decide priorities." Which is a silly thing to tell a product manager. There should be an existing consensus around how this sort of thing is handled and prioritized. If your product managers aren't allocating time for fixing frequently-encountered bugs or UX problems, then the solution isn't to set them up for a conflict with engineers. The solution is to have someone exercise leadership of the product managers so that they is alignment on the general importance of getting bugs fixed quarterly goals and so that when someone (PM or engineer, whoever is triaging level-2 support queries) exercises judgement about the priority of a bug relative to other work, others broadly agree on that decision. You need to have some structure accomplishes this.

afarrell 8y ago

No, this strategy really does depend on the engineers having a good way to prioritize things. If you have engineers doing level-2 support and you have product managers saying "Do this other thing", then the engineer now repeatedly has to resolve a conflict among the possibilities of: A) Check email and slack to see if something new has come in. B) Check your error reporting/monitoring to see if Sentry has reported any new exceptions/errors from existing services. C) Issue #1 from a customer D) Issue #2 from a different sort of customer who has more revenue impact E) Issue #3 which was actually bubbled up from someone in sales. F) Non-urgent but important Project X from the product manager which you are actually 30% of the way finished with and consequently, it is the thing that is sitting in your brain. G) Check hackernews as a salve to the stress of a bunch of ambiguously-prioritized tasks. Accomplishing engineering tasks requires allocating your brain's working memory and directing your focus on ONE thing at a time. The harder that is, the harder it is to do anything but option G. If you put engineers in this situation, but you don't give engineers the training and structure to arbitrate decisions about prioritization, then you're setting them up for needless conflict and failure. If you just designate all of your engineers as being responsible for level-2 support without any additional structured then each one needs to tell the product manager, "I'm not going to work on this project which will bring the company $X Monthly Recurring Revenue for another week, but I'm going to deal with these support requests. I am in charge of prioritizing what gets worked on. Your job as a product manager is not to decide priorities." Which is a silly thing to tell a product manager. There should be an existing consensus around how this sort of thing is handled and prioritized. If your product managers aren't allocating time for fixing frequently-encountered bugs or UX problems, then the solution isn't to set them up for a conflict with engineers. The solution is to have someone exercise leadership of the product managers so that they is alignment on the general importance of getting bugs fixed quarterly goals and so that when someone (PM or engineer, whoever is triaging level-2 support queries) exercises judgement about the priority of a bug relative to other work, others broadly agree on that decision. You need to have some structure accomplishes this.