6 ms·

Complain and Propose (2014)

90 points by zdw 2y ago

datadrivenangel 2y ago
This is generally good advice, but is a recipe to get extra work owning the implementation of the proposal.
- titanomachy 2y ago
  Or maybe you get to work on this important new thing, instead of whatever dumb thing you were going to be stuck doing.
  - warner25 2y ago
    Yeah, I've used this to my advantage: Sell my boss on the idea that we had a real problem and I could address it instead of doing some other lower-value tasks; essentially re-shaping my own role into something that I found much more fulfilling and resume-enhancing than whatever I'd be doing otherwise.
- ska 2y ago
  Especially in large organizations, you'll typically end up with more interesting/rewarding work if you help define it, than if you wait until something is handed to you.
  - feurio 2y ago
    Can confirm. Made a bit of a leftfield suggestion for an issue that there were no truly good solutions proposed for. I was tasked with building and deploying it. It's in production and working well so far (service which is 90% of our egress bandwidth). Got some really nice feedback from the director of technology at the Christmas social event. I can't imagine that it's hurt my job security, and it's been far more interesting than waiting for someone to find me busywork to do.
- tonymet 2y ago
  that's the goal
raincom 2y ago
Often times, you know a proposal doesn't work, and yet you don't have chops to implement a better a solution. In that case, keeping quiet is the best solution; otherwise, you just make enemies.
- avg_dev 2y ago
  one of the things i like about working at very small companies is that i don't have to immediately have a solution to everything. i can file an issue and/or mention a bug or issue that i see or foresee when we talk. i can then let it marinate until it either becomes necessary to act on it or i think of a solution and have time to work on it, whichever comes first. i often think of software as a series of problems. i don't have to worry about solutions initially. when we have polished off solutions to all of the truly immediately important problems - within some reasonable/useful level of engineering tolerances - the software can be thought of as done, for a time. just my opinion.
- omoikane 2y ago
  Documenting why a proposal wouldn't work might be valuable even if a better solution is not immediately available, then at least people are aware of potential problems and perhaps temporarily workaround them. Depending on what's the worst outcome of "wouldn't work", keeping silent might be worse than making enemies.
deleted 2y ago
[deleted]
warner25 2y ago
I was trained from the beginning of my career to do this, and trained to teach the same thing to the people reporting to me. It makes us all think harder, empowers lower-level people to make an impact, etc. Recently, though, I had someone convince me that it's not necessarily the best organizational practice. Essentially, there are sometimes big, systemic, intractable problems that lower-level people might see but not have the perspective, experience, etc. to even begin coming up with a solution. Higher-level people might have the perspective and experience but not see those problems (especially as each layer of the hierarchy acts a filter or sugar-coating mechanism for bad news as it moves upwards). If you tell people not to report problems unless they have a solution, and summarily dismiss anyone who does so, some serious problems might just be left rotting. > What am I going to do if I agree with you? A reasonable response to this might actually be, "I don't know; isn't that why you get paid the big bucks and I don't?" Reporting problems with proposed solutions should be encouraged, but there shouldn't be a blanket statement of "Don't bring a me problem unless you have a proposed solution!" An executive can simply ask, "Do you have a proposal?" and if the answer is negative the executive can say, "I understand, interesting, thanks for reporting this. I'll keep it in mind / assign someone more senior on my staff to look into it / etc."
- ranie93 2y ago
  I wonder how the author would respond to your feedback: > Reporting problems and proposed solutions should be encouraged, but there shouldn't be a blanket statement of "Don't bring a me problem unless you have a proposed solution!" It's kind of meta because in this post itself you are employing a kind of complain-and-propose. Anyways I think your conclusion is entirely reasonable. I don't think blanket statements are most ever the solution, and I assume the author would agree!
  - warner25 2y ago
    To be clear, in practice I think some organizational cultures just aggressively embrace this idea to the point of it being detrimental. I've heard statements with those exact words coming from executives, and I've seen people sort of squashed by executives in town hall-type forums for raising a problem without offering a solution. (In the line that you quoted, by the way, I just changed "and" to "with" for clarity.)
deleted 2y ago
[deleted]
bsder 2y ago
Your semi-regular reminder that Kent Beck was one of the people who failed-upward from the disaster that was Extreme Programming for the Chrysler Comprehensive Compensation System. You should take both management and programming advice from him with large grains of salt.
tikhonj 2y ago
When this attitude becomes too prevalent, important problems either don't get reported at all or morph into "the problem is that we're not implementing my exact solution". That's how you end up with pervasive organizational problems festering, while executives develop a wholly disconnected model of what's happening at the company, with the solutions that manage to get through partially addressing the problem at best.
karmakaze 2y ago
Another related thing I've encountered is positive/growth vs negative/fixed mindset. Often in discussions someone will make a suggestion and someone else will give a reason why that's not feasible. Everyone might be silent for a moment as no one has a solution off-hand to deal with it and the idea is squashed. One time I made a run-time query optimizer which wasn't all that complicated in any one area but had numerous mechanisms and fall-backs (and a lot of plumbing code). A colleague remarked how he would never have come up with that and listed all the problems which would have needed to be solved along the way to make it all work. I replied that he basically described the roadmap for what I had done step by step. It's sort of like that advice about not giving up on the first "no". Usually a list of reasons why something can't be done rarely contains any actual impossible ones and in many cases can be transformed into a list of things that can.
deleted 2y ago
[deleted]
zizee 2y ago
My experience with exec types is they most often will either agree with the problem, but not want to listen to proposed solutions (because they want to be "the one"), or they won't want to acknowledge the problem is real, and then try to dominate the conversation explaining how you are wrong.
zahlman 2y ago
I never formally did "extreme programming" or "agile", but I learned a lot indirectly from observing thought leaders like Kent Beck (and Ward Cunningham, Robert Martin etc.) back in the day. Good to see that they're still around.

90 points by zdw 2y ago

datadrivenangel 2y ago

This is generally good advice, but is a recipe to get extra work owning the implementation of the proposal.

titanomachy 2y ago
Or maybe you get to work on this important new thing, instead of whatever dumb thing you were going to be stuck doing.
- warner25 2y ago
  Yeah, I've used this to my advantage: Sell my boss on the idea that we had a real problem and I could address it instead of doing some other lower-value tasks; essentially re-shaping my own role into something that I found much more fulfilling and resume-enhancing than whatever I'd be doing otherwise.
ska 2y ago
Especially in large organizations, you'll typically end up with more interesting/rewarding work if you help define it, than if you wait until something is handed to you.
- feurio 2y ago
  Can confirm. Made a bit of a leftfield suggestion for an issue that there were no truly good solutions proposed for. I was tasked with building and deploying it. It's in production and working well so far (service which is 90% of our egress bandwidth). Got some really nice feedback from the director of technology at the Christmas social event. I can't imagine that it's hurt my job security, and it's been far more interesting than waiting for someone to find me busywork to do.
tonymet 2y ago
that's the goal

raincom 2y ago

Often times, you know a proposal doesn't work, and yet you don't have chops to implement a better a solution. In that case, keeping quiet is the best solution; otherwise, you just make enemies.

avg_dev 2y ago
one of the things i like about working at very small companies is that i don't have to immediately have a solution to everything. i can file an issue and/or mention a bug or issue that i see or foresee when we talk. i can then let it marinate until it either becomes necessary to act on it or i think of a solution and have time to work on it, whichever comes first. i often think of software as a series of problems. i don't have to worry about solutions initially. when we have polished off solutions to all of the truly immediately important problems - within some reasonable/useful level of engineering tolerances - the software can be thought of as done, for a time. just my opinion.
omoikane 2y ago
Documenting why a proposal wouldn't work might be valuable even if a better solution is not immediately available, then at least people are aware of potential problems and perhaps temporarily workaround them. Depending on what's the worst outcome of "wouldn't work", keeping silent might be worse than making enemies.

deleted 2y ago

[deleted]

warner25 2y ago

I was trained from the beginning of my career to do this, and trained to teach the same thing to the people reporting to me. It makes us all think harder, empowers lower-level people to make an impact, etc. Recently, though, I had someone convince me that it's not necessarily the best organizational practice. Essentially, there are sometimes big, systemic, intractable problems that lower-level people might see but not have the perspective, experience, etc. to even begin coming up with a solution. Higher-level people might have the perspective and experience but not see those problems (especially as each layer of the hierarchy acts a filter or sugar-coating mechanism for bad news as it moves upwards). If you tell people not to report problems unless they have a solution, and summarily dismiss anyone who does so, some serious problems might just be left rotting. > What am I going to do if I agree with you? A reasonable response to this might actually be, "I don't know; isn't that why you get paid the big bucks and I don't?" Reporting problems with proposed solutions should be encouraged, but there shouldn't be a blanket statement of "Don't bring a me problem unless you have a proposed solution!" An executive can simply ask, "Do you have a proposal?" and if the answer is negative the executive can say, "I understand, interesting, thanks for reporting this. I'll keep it in mind / assign someone more senior on my staff to look into it / etc."

ranie93 2y ago
I wonder how the author would respond to your feedback: > Reporting problems and proposed solutions should be encouraged, but there shouldn't be a blanket statement of "Don't bring a me problem unless you have a proposed solution!" It's kind of meta because in this post itself you are employing a kind of complain-and-propose. Anyways I think your conclusion is entirely reasonable. I don't think blanket statements are most ever the solution, and I assume the author would agree!
- warner25 2y ago
  To be clear, in practice I think some organizational cultures just aggressively embrace this idea to the point of it being detrimental. I've heard statements with those exact words coming from executives, and I've seen people sort of squashed by executives in town hall-type forums for raising a problem without offering a solution. (In the line that you quoted, by the way, I just changed "and" to "with" for clarity.)

deleted 2y ago

[deleted]

bsder 2y ago

Your semi-regular reminder that Kent Beck was one of the people who failed-upward from the disaster that was Extreme Programming for the Chrysler Comprehensive Compensation System. You should take both management and programming advice from him with large grains of salt.

tikhonj 2y ago

When this attitude becomes too prevalent, important problems either don't get reported at all or morph into "the problem is that we're not implementing my exact solution". That's how you end up with pervasive organizational problems festering, while executives develop a wholly disconnected model of what's happening at the company, with the solutions that manage to get through partially addressing the problem at best.

karmakaze 2y ago

Another related thing I've encountered is positive/growth vs negative/fixed mindset. Often in discussions someone will make a suggestion and someone else will give a reason why that's not feasible. Everyone might be silent for a moment as no one has a solution off-hand to deal with it and the idea is squashed. One time I made a run-time query optimizer which wasn't all that complicated in any one area but had numerous mechanisms and fall-backs (and a lot of plumbing code). A colleague remarked how he would never have come up with that and listed all the problems which would have needed to be solved along the way to make it all work. I replied that he basically described the roadmap for what I had done step by step. It's sort of like that advice about not giving up on the first "no". Usually a list of reasons why something can't be done rarely contains any actual impossible ones and in many cases can be transformed into a list of things that can.

deleted 2y ago

[deleted]

zizee 2y ago

My experience with exec types is they most often will either agree with the problem, but not want to listen to proposed solutions (because they want to be "the one"), or they won't want to acknowledge the problem is real, and then try to dominate the conversation explaining how you are wrong.

zahlman 2y ago

I never formally did "extreme programming" or "agile", but I learned a lot indirectly from observing thought leaders like Kent Beck (and Ward Cunningham, Robert Martin etc.) back in the day. Good to see that they're still around.