I once had a manager who had pawned a system off on me, being unable to deal with the users, the system or its problems. Some time later I received some static form the same manager about the amount of time I spent on this system. My reply was to the effect that this was his idea, I took the load off him as he requested, and that he should have no further communications with me on the subject. Of course it was worded a little differently...

That system evolved from fixing problems to adding massive new functionality because the users perceived that I was willing to try something new. Not only did they get the features they wanted, the got levels of automation and independence from dual system entry.

But apparently I forgot part of those lessons. In a more recent meeting with a number of users and the CIO, I started to explain why it was not technically feasible to handle a certain request. I was very publicly chastised by the CIO, and for good reason, and told never to do this again. The issues were not technical but personal, as I realized later. The lesson was re-learned, from the opposite side and never forgotten.

Apparently the point here is that no matter how well-meaning we are as developers, there is no question that personal relationships also play a role. Those relationships an be repaired or destroyed on a single conversation, so be careful. The job you save may be your own.

FWIW, while the CIO has moved on, I have a great relationship with everyone else who was in that meeting, so I guess I DID learn something.