4 ms·

> What I've found is that the typical developer/engineer is really bad at saying "no" or "not now" to others. The reason for this, by the way, is roughly that

> What I've found is that the typical developer/engineer is really bad at saying "no" or "not now" to others. The reason for this, by the way, is roughly that it's short-term easier to think about how to solve their problem so that they'll go away rather than "waste time" arguing about priority. People outside the engineering department tend to be a lot more well-versed in making a case for priority and instinctively push more than the engineer pushes back. Also, many thanks for being one of the awesome people who help deal with this. As a developer who has worked under a few great manager-types (and has a ton of trouble saying no to a request), you make all the difference.

hkmurakami 14y ago
Firstly, thanks for the kind words :). What's kind of funny is that while I'm pretty good at being a shit-umbrella for my team, I've found that I really really hate making urgent requests to other teams (HW, Applications, etc.) precisely because I know that they also have a lot on their plate already. In fact, I think I'm honestly really bad at 'pressuring' people in other teams to do things that our team needs. Everything comes with a cost, I guess. > People outside the engineering department tend to be a lot more well-versed in making a case for priority and instinctively push more than the engineer pushes back. I've also noticed that a lot of times, an individual sales/mktg/bizdev person actually doesn't know what the overall priorities are, since she is only aware of her customers and her items that need to be addressed. The person rarely has a sense for what the relative importance of her items are compared to those of the person sitting right next to her also asking the dev team for their time. In a similar vein, I think it's very hard to push back as an engineer since she will rarely know all the projects that are going on concurrently, who the customers are, what the estimated revenues are for each project, etc. This is exactly the kind of information you need to fight against an interruption request: "Sorry but I'm working on item X for customer Y, with deadline Z, which is a higher priority item compared to your item W." Now, an engineer probably shouldn't even have all this information, since the information is kind of a distraction in itself. So when a rogue customer-facing guy comes up to an engineer with a request, a much easier solution is to answer with, "Sorry I don't have the authority to change what I'm working on. Can you please go talk to my engineering manager A or my project manager B? I'll be happy to change course once I get updated instructions from them. Thanks."
- saraid216 14y ago
  Well, there's nothing intrinsically wrong with an engineer having the information if they're interested. It's often useful to have a larger picture. However, for the purposes of dealing with interruption, calling in an ally is basically the most efficient way to make it go away. (The caveat being that sometimes the interruption really is more important.) I've also heard managers chewing out or giving educative talks to others in order to remind them that the correct person to make the request to is the manager, not the engineer.
  - hkmurakami 14y ago
    > I've also heard managers chewing out or giving educative talks to others in order to remind them that the correct person to make the request to is the manager, not the engineer. Haha, funny you say this, since I also 'educate' others about this on a monthly basis (it's become much better compared to 12 months ago though, so credit to the customer facing teams who are generally reasonable people).
- mtrimpe 14y ago
  > I've found that I really really hate making urgent requests to other teams For me what ended up working by far the best is to always and for every request try to: 1) Give an honest summary of the negative consequences of your request being delayed/ignored 2) Ask for an honest summary of the negative consequences of your request being honored. 3) Continue calibrating the relative importance until the higher priority task is obvious for both parties. At first you might get run over a few times but if you don't accept politics (also not your own!) to enter the equation and consistently do this eventually people will be very accepting and these request can be made very efficiently.
  - dstorrs 14y ago
    What you're talking about is a great example of good-faith communication. Unfortunately, it relies on both parties dealing in good faith, and I've had too much experience with people who won't do that -- they won't give an honest assessment of what happens if their request isn't met. I wish I knew how to handle that.

hkmurakami 14y ago

Firstly, thanks for the kind words :). What's kind of funny is that while I'm pretty good at being a shit-umbrella for my team, I've found that I really really hate making urgent requests to other teams (HW, Applications, etc.) precisely because I know that they also have a lot on their plate already. In fact, I think I'm honestly really bad at 'pressuring' people in other teams to do things that our team needs. Everything comes with a cost, I guess. > People outside the engineering department tend to be a lot more well-versed in making a case for priority and instinctively push more than the engineer pushes back. I've also noticed that a lot of times, an individual sales/mktg/bizdev person actually doesn't know what the overall priorities are, since she is only aware of her customers and her items that need to be addressed. The person rarely has a sense for what the relative importance of her items are compared to those of the person sitting right next to her also asking the dev team for their time. In a similar vein, I think it's very hard to push back as an engineer since she will rarely know all the projects that are going on concurrently, who the customers are, what the estimated revenues are for each project, etc. This is exactly the kind of information you need to fight against an interruption request: "Sorry but I'm working on item X for customer Y, with deadline Z, which is a higher priority item compared to your item W." Now, an engineer probably shouldn't even have all this information, since the information is kind of a distraction in itself. So when a rogue customer-facing guy comes up to an engineer with a request, a much easier solution is to answer with, "Sorry I don't have the authority to change what I'm working on. Can you please go talk to my engineering manager A or my project manager B? I'll be happy to change course once I get updated instructions from them. Thanks."

saraid216 14y ago
Well, there's nothing intrinsically wrong with an engineer having the information if they're interested. It's often useful to have a larger picture. However, for the purposes of dealing with interruption, calling in an ally is basically the most efficient way to make it go away. (The caveat being that sometimes the interruption really is more important.) I've also heard managers chewing out or giving educative talks to others in order to remind them that the correct person to make the request to is the manager, not the engineer.
- hkmurakami 14y ago
  > I've also heard managers chewing out or giving educative talks to others in order to remind them that the correct person to make the request to is the manager, not the engineer. Haha, funny you say this, since I also 'educate' others about this on a monthly basis (it's become much better compared to 12 months ago though, so credit to the customer facing teams who are generally reasonable people).
mtrimpe 14y ago
> I've found that I really really hate making urgent requests to other teams For me what ended up working by far the best is to always and for every request try to: 1) Give an honest summary of the negative consequences of your request being delayed/ignored 2) Ask for an honest summary of the negative consequences of your request being honored. 3) Continue calibrating the relative importance until the higher priority task is obvious for both parties. At first you might get run over a few times but if you don't accept politics (also not your own!) to enter the equation and consistently do this eventually people will be very accepting and these request can be made very efficiently.
- dstorrs 14y ago
  What you're talking about is a great example of good-faith communication. Unfortunately, it relies on both parties dealing in good faith, and I've had too much experience with people who won't do that -- they won't give an honest assessment of what happens if their request isn't met. I wish I knew how to handle that.