[HN Gopher] Complain and Propose (2014)
       ___________________________________________________________________
        
       Complain and Propose (2014)
        
       Author : zdw
       Score  : 64 points
       Date   : 2024-12-27 17:12 UTC (5 hours ago)
        
 (HTM) web link (tidyfirst.substack.com)
 (TXT) w3m dump (tidyfirst.substack.com)
        
       | datadrivenangel wrote:
       | This is generally good advice, but is a recipe to get extra work
       | owning the implementation of the proposal.
        
         | titanomachy wrote:
         | Or maybe you get to work on this important new thing, instead
         | of whatever dumb thing you were going to be stuck doing.
        
           | warner25 wrote:
           | 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 wrote:
         | 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.
        
         | tonymet wrote:
         | that's the goal
        
       | raincom wrote:
       | 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 wrote:
         | 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 wrote:
         | 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.
        
       | warner25 wrote:
       | 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 wrote:
         | 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 wrote:
           | 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.)
        
         | 7bit wrote:
         | > 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.
         | 
         | I would expand on that and say that only bad managers do so.
         | They are paid for exactly that. Manage their people and remove
         | the problems that make their work hard. Sure, if their direct
         | reports come with a proposal already, that is great because
         | they now what direction to go TK make them happy. But if the
         | managers insist on their direct reports to report issues only
         | with solutions, then why do they need the manager in the first
         | place?
        
         | paulcole wrote:
         | > 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
         | 
         | I disagree with this and it's an excuse for people who don't
         | want to think.
         | 
         | Which is fine, I guess. It's everybody's right to not want to
         | think.
         | 
         | But it doesn't change the fact that in the vast majority of
         | situations, coming up with a solution is possible. The trick is
         | then to come up with one that's slightly better and then
         | slightly better and so on until you run into the limit of what
         | you're capable of.
         | 
         | Challenge people to be creative. It's a skill that can be
         | developed with practice.
         | 
         | The next time somebody says they can't come up with a solution
         | because of their low rank or whatever, try offering them $10k
         | out of your own pocket to come up with any solution.
         | 
         | Suddenly, I'll bet, a solution comes to them!
        
           | warner25 wrote:
           | I mostly agree with you. I suppose we should distinguish
           | between a "proposal" and a "solution." I guess a "solution"
           | actually satisfies a set of constraints whereas a "proposal"
           | could just be dead on arrival because it fails to satisfy one
           | or more constraints. The lower-level person is probably not
           | even aware of all the constraints, so whatever proposal they
           | come up with likely isn't going to be a solution. Demanding
           | that they come up with a throwaway proposal doesn't do a lot
           | of good.
           | 
           | Example: The school lunch program is failing to adequately
           | feed students. The first-year teachers stuck with lunch duty
           | see it, the students see it, etc. No doubt that they can come
           | up with _some_ proposal that involves spending more money on
           | the lunch program, and they can even identify some other area
           | to take the money from, but they don 't necessarily see the
           | big picture to know why that might not be possible (e.g. tax
           | dollars or grant money can only be spent in certain ways) or
           | what the negative effects might be (e.g. why money is
           | currently being spent in that other area).
           | 
           | This is another way I've seen people get squashed by
           | executives. As people were trained to offer a proposal when
           | reporting a problem, they did so, but then it gave the
           | executive an opportunity to just focus on explaining why the
           | proposal can't work instead of just listening and asking
           | follow-up questions to better understand the problem.
        
             | paulcole wrote:
             | I mean it seems more like the underlying issue you have is
             | with how people respond to proposed solutions rather than
             | that they are asked to come up with a solution at all.
        
           | sanderjd wrote:
           | I mean, the thing you quoted and said you disagree with is
           | just clearly true. Take it to the extreme:
           | 
           | Someone a week out of school can identify a problem that
           | requires thousands of people coordinated by leadership across
           | the organization to solve.
           | 
           | It isn't "people don't want to think" or a failure to
           | "challenge people to be creative" to recognize that many
           | problems require significantly more experience or expertise
           | to propose a solution to than to identify.
        
             | paulcole wrote:
             | > Someone a week out of school can identify a problem that
             | requires thousands of people coordinated by leadership
             | across the organization to solve.
             | 
             | I am not suggesting that the person solve the problem. I am
             | saying that they are capable of putting forth a solution.
             | 
             | The solution may not be _complete_ , _great_ , _reasonable_
             | , or _feasible_. But nobody ever got better at solving
             | problems by not thinking of solutions.
             | 
             | And shouldn't we try just asking someone for a solution
             | before we get to thousands of people working to solve a
             | problem?
             | 
             | > many problems require significantly more experience or
             | expertise to propose a solution to than to identify.
             | 
             | You skipped over the part where I challenged you to put
             | your own money on the line to test this belief.
             | 
             | You really think that a single solution is impossible to
             | identify for "many problems"?
             | 
             | Hypothetically, imagine a problem you think I can't come up
             | with a solution for. I will present a solution to it.
        
         | brandonbloom wrote:
         | There is a huge spectrum from no proposal at all to a magic
         | bullet on a silver platter. To some extent, the default and
         | implicit proposal is: "You should something about it!". Which
         | is markedly worse than "_We_ should do something about it.",
         | and worse still than "Let's do something about it, here's how I
         | can help..."
         | 
         | Some other useful intermediate proposals include:
         | 
         | - "Allow me and my team time to investigate a solution."
         | 
         | - "I've organized my complaints into requirements for a
         | solution. Please identify an expert to solve the problem."
         | 
         | - "I've socialized these problems with ${people}, I recommend
         | you speak to ${person} about ${topic} for next steps."
         | 
         | Having said that, I agree that complaints can be counted as
         | "votes" for which problems to solve in the future. The problem
         | is that they are not one complaint = one vote. At the very
         | least, the complainer's role and responsibilities need to be
         | accounted for within the scope of the larger organizational
         | goals.
        
           | warner25 wrote:
           | This is great; very mature organizational thinking.
        
         | karmakaze wrote:
         | It depends on the organization or the team/reporting structure
         | you find yourself in. After a few instances of thinking things
         | out deeply, reporting both the problem and solution, only to
         | have them sincerely acknowledged then never acted upon isn't a
         | great pattern worth repeating. What seems to work better in
         | those situations is to 1. complain, 2. chip away at the problem
         | in the open, 3. socialize suggestions, 4. make small inline
         | changes toward a north star which solves the problem. Basically
         | change the current system to bring the solution closer to the
         | point that someone pulls the trigger and says let's get this
         | done.
        
         | creer wrote:
         | This is also a common administrative punishment method:
         | 
         | "You seem to understand that problem. Why don't you study it
         | more in depth and return a proposal on what to do about it".
         | 
         | Unsaid: "in addition to your current workload."
         | 
         | Also unsaid "that will learn you to be a smartass".
         | 
         | (Which is okay if it's a problem you DO want to make your life
         | about - but still with the understanding that this new
         | assignement was meant as punishement and is not what will get
         | you promoted. At least not unless it's spectacularly
         | successful.)
        
       | bsder wrote:
       | 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 wrote:
       | 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 wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-12-27 23:00 UTC)