Lovely article, most definitely agree with what you're saying as I've had very similar experiences throughout my career. Right now, I am in the fortunate position of having a non-technical PM who takes the time to understand why a problem is a problem and will take my feedback to the client (and include in me in the meeting where necessary) instead of just insisting we do it the client's way.
Just wanted to comment on "this is the way the client wants it, so this is the way we'll do it".
It reminds me of that meme of the four people pushing a cube along with one person pushing a ball and the caption reads "work smarter, not harder". In this analogy, we'd rather push the ball, not the cube because it's much easier right?
The problem is, what if the client has a cube sized hole they are trying to fill and you thought you knew better by giving them ball - which was really only easier for you but not what the client wanted or needed.
Understanding should go both ways and before I shoot down a client's idea, I first try to understand what they are trying achieve before proposing a better solution. That way, I tend to get much further with the client (and my PM) than if I spend a lot of time explaining why their idea is bad or problematic.
In the analogy above, I might propose that we make a ball much larger than the cube sized hole the client is trying to fill and once we have pushed the ball to where it needs to be, we cut it into the right size cube and fit it. That solution works better for everyone.
The client tends to go along a lot easier when they can see I'm trying solve their problem, not my problem and more often than not, I end up solving both of our problems.
Absolutely agree on all points! And I suppose this is some of what frustrates me about those times when someone (the PM, or anyone else for that matter) foists the client's dictates upon me without giving me a chance to have an intelligent conversation about what is truly desired and how we can get there. If I know we're trying to achieve X, and the client asked for something that doesn't seem geared toward X, I can then explain better options that might get us closer to the client's goal and make the process more sane for the dev team. But if I'm locked out of the goal-defining process, and I'm just told, "Do this thing, because the client wants us to do the thing," it's very difficult to provide any sort of intelligent input.
100%. As I like to put it, don't tell me how you think the problem should be solved, tell me the problem. Solving it is what I'm here for. I learned that back when I was doing tech support, and it applies to so many areas -- including, in keeping with your other post, medicine.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Lovely article, most definitely agree with what you're saying as I've had very similar experiences throughout my career. Right now, I am in the fortunate position of having a non-technical PM who takes the time to understand why a problem is a problem and will take my feedback to the client (and include in me in the meeting where necessary) instead of just insisting we do it the client's way.
Just wanted to comment on "this is the way the client wants it, so this is the way we'll do it".
It reminds me of that meme of the four people pushing a cube along with one person pushing a ball and the caption reads "work smarter, not harder". In this analogy, we'd rather push the ball, not the cube because it's much easier right?
The problem is, what if the client has a cube sized hole they are trying to fill and you thought you knew better by giving them ball - which was really only easier for you but not what the client wanted or needed.
Understanding should go both ways and before I shoot down a client's idea, I first try to understand what they are trying achieve before proposing a better solution. That way, I tend to get much further with the client (and my PM) than if I spend a lot of time explaining why their idea is bad or problematic.
In the analogy above, I might propose that we make a ball much larger than the cube sized hole the client is trying to fill and once we have pushed the ball to where it needs to be, we cut it into the right size cube and fit it. That solution works better for everyone.
The client tends to go along a lot easier when they can see I'm trying solve their problem, not my problem and more often than not, I end up solving both of our problems.
Absolutely agree on all points! And I suppose this is some of what frustrates me about those times when someone (the PM, or anyone else for that matter) foists the client's dictates upon me without giving me a chance to have an intelligent conversation about what is truly desired and how we can get there. If I know we're trying to achieve X, and the client asked for something that doesn't seem geared toward X, I can then explain better options that might get us closer to the client's goal and make the process more sane for the dev team. But if I'm locked out of the goal-defining process, and I'm just told, "Do this thing, because the client wants us to do the thing," it's very difficult to provide any sort of intelligent input.
100%. As I like to put it, don't tell me how you think the problem should be solved, tell me the problem. Solving it is what I'm here for. I learned that back when I was doing tech support, and it applies to so many areas -- including, in keeping with your other post, medicine.