Complain and Propose (2014) | Hacker News Reader

Complain and Propose (2014)

tidyfirst.substack.com

90 pointszdw31 comments

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."

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!

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.)

> 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?

> 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!

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.

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.

But that is the entire "issue": for you to get an improvement implemented, you need to work with people with a broader context and more say in things. And they are human, so you need to make sure you don't put them needlessly on a defensive (even if they don't mean to be).

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.

> 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.

Hmm, I've been going back and forth on what I think in response to this...

On the one hand, I do agree with you that anyone can come up with an unworkable proposal for a solution to any problem.

But on the other hand, most of the good people I've worked with would find it very unsatisfying to put forward an unworkable proposal and may well just be discouraged from reporting the issue at all.

But I think on balance we are probably more in agreement than I thought. I do think it's a useful exercise to encourage people to say "this is a problem, I don't really know how to fix it, my best idea is ____ but I'm not sure that will work because ____".

But I also think it's pretty hard to foster an environment where people of every seniority level feel comfortable doing that.

>But I also think it's pretty hard to foster an environment where people of every seniority level feel comfortable doing that.

That's because pretending to be unsinkable is much easier than working to prevent the ship from sinking. Especially when there's a perception that the problem carries very low risk. That creates situations where there's little individual benefit and a lot of reputational risk for raising the alarm.

To fix this you have to intentionally create a culture that aligns individual and organizational incentives around the behavior you want to see encouraged.

100%

Even then, people who are new will inevitably be skeptical that this kind of culture is real. And they may be right that it isn't real for them, even if you think it's real.

I saw this a bunch joining a ginormous tech company decades after its rise; old-timers thought things were true about the culture that may have still been true for them, but which didn't seem true to me.

(Also, nobody feels more betrayed than those old-timers when the culture turns cut-throat during difficult times.)

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.

This is great; very mature organizational thinking.

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.

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.)

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

Or maybe you get to work on this important new thing, instead of whatever dumb thing you were going to be stuck doing.

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.

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.

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.

that's the goal

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.

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.

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com