4 ms·

Clear boundaries are important too. It isn't my job, as an engineer, to remember everything you requested. It's also not my job to know exactly what your corner

by ian-g 3y ago

Clear boundaries are important too. It isn't my job, as an engineer, to remember everything you requested. It's also not my job to know exactly what your corner of a platform looks like. And it's especially not my job to negotiate against your constant attempts to creep a task's scope whenever we run into issues stemming from you not knowing your own platform and process well enough.

ranting-moth 3y ago
> It isn't my job, as an engineer, to remember everything you requested. Could you clear this up a bit? If the PM makes a request to you, who's responsibility is it to remember it?
- maccard 3y ago
  It's the PM's responsibility to ensure the request is captured. It's the engineers job to deliver on the captured request. It's both people's job to talk to one another to ensure the captured request is correct.
- ian-g 3y ago
  Sorry, you're right, that wasn't clear. It isn't my job to remember the history of every request your team has ever submitted to my team. If you have a custom process that we don't know about or that your predecessor requested of my predecessor, I don't expect to be aware of that. And when it causes issues, I don't see why that's my fault
whstl 3y ago
"It isn't my job, as an engineer, to remember everything you requested" It's not your job to remember, but it is your job as a human being to set expectations about your favored communication style in a professional manner. If you need something written down in an email or Jira task or whatever, for example, so you don't have to remember, you should ask for it. If you think scope creep is a problem and don't want to keep negotiating (something very reasonable to ask for), you gotta communicate about this problem in the appropriate channels.
- BizarreByte 3y ago
  > you should ask for it. > you gotta communicate about this problem in the appropriate channels. After years of repeating myself I have quite frankly given up. No one listens and nothing ever gets better on this front.
  - whstl 3y ago
    Well, if it's the same person denying change it without a counter-argument, then there's no solution other than changing teams or company. If it's a string of PMs, all being unreasonable, some self-reflection might be necessary. Maybe the problem is not with their work, but with your expectations.
lkbm 3y ago
As an engineer, I consider all those those very much my job. "Negotiating against" scope creep maybe not quite, but it is my job to provide decent time estimates for expanded scope so they can decide if it's worth it. To be fair, I'm coming from a place where I have familiarity with pretty much our entire platform. If I were new, or delving into some aspect I haven't worked on before, I'd expect some understanding that it's going to take me time to familiarize myself with it, but I will familiarize myself with it in order to work on it. If the PM is an expert on that area, they should be willing to take the time to answer questions.

by ian-g 3y ago

ranting-moth 3y ago

> It isn't my job, as an engineer, to remember everything you requested. Could you clear this up a bit? If the PM makes a request to you, who's responsibility is it to remember it?

maccard 3y ago
It's the PM's responsibility to ensure the request is captured. It's the engineers job to deliver on the captured request. It's both people's job to talk to one another to ensure the captured request is correct.
ian-g 3y ago
Sorry, you're right, that wasn't clear. It isn't my job to remember the history of every request your team has ever submitted to my team. If you have a custom process that we don't know about or that your predecessor requested of my predecessor, I don't expect to be aware of that. And when it causes issues, I don't see why that's my fault

whstl 3y ago

"It isn't my job, as an engineer, to remember everything you requested" It's not your job to remember, but it is your job as a human being to set expectations about your favored communication style in a professional manner. If you need something written down in an email or Jira task or whatever, for example, so you don't have to remember, you should ask for it. If you think scope creep is a problem and don't want to keep negotiating (something very reasonable to ask for), you gotta communicate about this problem in the appropriate channels.

BizarreByte 3y ago
> you should ask for it. > you gotta communicate about this problem in the appropriate channels. After years of repeating myself I have quite frankly given up. No one listens and nothing ever gets better on this front.
- whstl 3y ago
  Well, if it's the same person denying change it without a counter-argument, then there's no solution other than changing teams or company. If it's a string of PMs, all being unreasonable, some self-reflection might be necessary. Maybe the problem is not with their work, but with your expectations.

lkbm 3y ago

As an engineer, I consider all those those very much my job. "Negotiating against" scope creep maybe not quite, but it is my job to provide decent time estimates for expanded scope so they can decide if it's worth it. To be fair, I'm coming from a place where I have familiarity with pretty much our entire platform. If I were new, or delving into some aspect I haven't worked on before, I'd expect some understanding that it's going to take me time to familiarize myself with it, but I will familiarize myself with it in order to work on it. If the PM is an expert on that area, they should be willing to take the time to answer questions.