How do you combat “Can’t you just…”?

[-]

Party-Lingonberry592@reddit

I was a developer working on a tool that was rife with brittle code and served up data to project managers. I would have that conversation weekly. When it was about the scope of the work, I would say "hopefully it won't take me that long, but I need to reverse-engineer the existing code to see how it works first so I don't break anything else in the process." Other times I'd say "Let me look into your suggestion, it would be great if it were that simple." I got called into a meeting with the director after my manager pushed on my time estimate. "Do we have a problem?!" she asked. I replied, "I don't have a problem here, but If you don't want my estimate, then don't ask me for it." Within a year I took over that team as manager and told my team to direct that kind of nonsense to me directly so they wouldn't have to deal with it.

[-]

j-e-s-u-s-1@reddit

If its big tech, be very very very careful saying I do not know how to: because they will be able to do it most certainly and you will be looking at downward trend (think quarterly reviews).

[-]

dirkforest@reddit

When I was CTO at last place I implemented, essentially, a substitution rule of s/why don’t you just/what would it take to/g. I wrote up the rule from pretty early on and everyone in the company knew if they said it someone would ask them to restate with “what would it take to”. It mostly worked. Occasionally someone would get stubborn and double down on the “why not just” but they knew they were in a corner given the rules visibility and constant reinforcement.

[-]

c0ventry@reddit

This is actually a soft skills issue, which unfortunately we have to deal with all too often (instead of actual engineering). I had to deal with this all the time during my career, and yes it's annoying. Think of them as children testing their boundaries, and you are the parent who must remain strong and project confidence and knowledge. You can't let people like this feel like they can have any power over you, so you need to work on your presence. Think of a technical person or any person in leadership that you met that inspired complete confidence. What kind of characteristics did this person have?

I always noticed that companies would have some guy that the higher ups thought was a tech genius (they almost never were) and his word was gospel to them. It would bother me that I was often better qualified than this person and it didn't seem to matter. Rather than get angry about it, I decided to start studying the behavior of these types. How did they inspire so much confidence in non-technical types? How did they get so much respect and autonomy?

TLDR Life isn't fair and people are lame. You have to learn to dominate lesser beings like a Sith :)

[-]

CooperNettees@reddit

"cant you just X?"

"I could but it would take longer and not work as well as doing Y. im happy to do X though if you're willing to take ownership of spending more time on doing it that way despite the drawbacks."

I've never had someone take me up on this offer.

[-]

1One2Twenty2Two@reddit

In a meeting with 15 people I once said to someone like that: I've never done something similar to what you're asking. Would you be able to show me and my team how you would do that?

The answer: well, you know, you guys are the expert so maybe it's a bit more complicated blah blah blah.

And that was the end of it.

[-]

SnakeSeer@reddit

I've had good luck with, "I'm not quite sure I understand how your proposal will fit into the existing program; could you go into more detail?" Once they have to start explaining, they start thinking about the problem more and realizing its scope might be bigger than they thought.

[-]

throwaway0134hdj@reddit

They say “that’s your job, I am the ideas only person”

[-]

jmfsn@reddit

"Oh, the useless one! I got it know."

[-]

LABS_Games@reddit

Honestly, getting people to thoroughly explain themselves is a great strategy for a lot of things. I once had a coworker who made frequent racist comments about colleagues. One day he said some shitty joke about an Asian colleague's eyes. Anyways, the Asian colleague called out the racist remark, which garnered the "it's just a joke" response. The colleague simply replied, "I don't get the joke, can you explain it?". Forced to lay out the shitty racism of his joke in plain English, the guy was forced to awkwardly half-mumble the explanation.

So much of our daily conversations are told through implication and shared understanding, and having someone talk through all the unspoken parts really forces them to engage with the entirety of what they said, rather than leaving so much of it as subtext. It's like rubber ducky debugging, in a way

[-]

doyouevencompile@reddit

Giving them a shovel to dig themselves a hole is the best way to stop stupid suggestions

[-]

bunk3rk1ng@reddit

Right and we are the experts. We will get a ticket and it will go through the standard process. Just like everything else. Done

[-]

throwaway0134hdj@reddit

Watch the short comedy skirt “The Expert” it’s literally what this entire thread is about

[-]

Main-Drag-4975@reddit

I like this. This is much more civil than what I always wanted to say: “ok then you do it”

[-]

tb_xtreme@reddit

It's not necessarily civil to make someone look like an ass in front of thirteen people

[-]

throwaway0134hdj@reddit

Public embarrassment is usually pretty effective at shutting them up though

[-]

Krackor@reddit

If someone is being an ass it would be uncivil to pretend otherwise.

[-]

tb_xtreme@reddit

Ok reddit

[-]

roynoise@reddit

Yeah, until they go tell our 45 other bosses that we "just don't want to help them out", and everybody in the stakeholder/c-class starts treating us like evening bigger idiots/more worthless peons.

[-]

jesusrambo@reddit

Well yeah, your job is to do it or to communicate why it’s not a good solution and find a better one

If you keep hitting stakeholders with “no”, you’re not doing your job well

[-]

vvf@reddit

We can communicate all we want, but it’s up to them to listen

[-]

throwaway0134hdj@reddit

They won’t listen. They have their minds made up and you are just being difficult for not fulfilling their dreams.

[-]

roynoise@reddit

We do what you suggest in your first statement, actually quite well.

We seldom ever even say something isn't possible . Any minor resistance whatsoever, any response that isn't "how high", even clarifying questions, to these people's most fantastical, vague whims (even when their vague demand contradicts one of the actual dozens of other stakeholders' equally fantastical whims), then we're lampooned as lazy, rebellious idiots.

[-]

throwaway0134hdj@reddit

We should all start listing out the crazy things that have been asked of us. Like I was asked to build a tool that would predict the stock market… like wtad… they ppl have no sense of the technical understanding of what they are even asking for… they just think “coder can do it”

[-]

jesusrambo@reddit

Based on this, I can guarantee you do not communicate well.

[-]

SmokyMetal060@reddit

I thought it was clear enough. Maybe it's a reading comprehension issue rather than a communication issue.

[-]

roynoise@reddit

It's the internet, dude. I'm not going to write you a meticulously crafted essay.

[-]

jesusrambo@reddit

Length isn’t the issue, there’s more than enough in that post. You tell on yourself from start to finish.

Incidentally, assuming the issue was length also points to poor communication

[-]

roynoise@reddit

I'm not the one here making assumptions. I also didn't say anything about length. Also, in case you missed the first time (reading comprehension skills issue?), reddit != reality.

[-]

throwaway0134hdj@reddit

I don’t know why you are being downvoted to oblivion. You have to know how to explain technical concepts in nontechnical ways. It’s definitely part of the field… despite how much we feel it’s not part of our job…

[-]

throwaway0134hdj@reddit

They look at us as machines… I hate that shit so much. I hear this at least once a day “I’m not technical” to me that just comes off as lazy and it’s not that you aren’t technical — no one is born technical. These folks don’t want to even bother. Crazy how they make more money…

[-]

chaitanyathengdi@reddit

Uno reverse, I like it

[-]

Financial_Orange_622@reddit

I had this situation with our ceo today. He wanted to listen but doesn't speak Technical. You have to translate into tangibles and try to give options rather than say no.

For example, "we can do that but it's about 4 weeks work" I imagine their reply would be "oh, that's more than I thought!" Then you say "yeah, making modular things is great but when you have infinite options it can present much more work. When we made x or Y feature for example things were more strictly defined.

Simpler responses : "yep! Which features from the list should we deprioritise?"

"OK I'll add it to the list with your name on it for the next review session" (I highly recommend meetings on a regular basis with all decision makers so they can argue with each other bakut priorities rather than you playing gatekeeper in the middle)

"great idea, I'll create a 1pg outline with how I think it'll look and circulate it later" then send it to enough people to replicate the above.

I've tended to work in companies with small dev teams and this method has worked plenty. Basically say yes but mean maybe. Signpost that you'll add it to a list and ask other people. Give yourself space to think things through and explain in BUSINESS TERMS why it's complicated - if the change impacts other teams or would cause other things to be delayed that's what you mention. Always talk about numbers - time, costs (we will go spend about 500 more per month on aws), other things being delayed.

Remember, if the business really want to go with this new feature which is terrible at the expense of all else - that's fine. Remember - some poor decorator/painter had to paint a wall lime green and warned the customer it would be bad... Then got paid to paint it almost white.

[-]

Subject_Bill6556@reddit

“I’m currently working on x and y for a and b. Reach out to an and b and work out the details of delaying their projects and then get back to me with their approval. After that I’ll be happy to prioritize your task” easy.

[-]

Tomicoatl@reddit

"We could do X but the risk is at scale we will have problems with . It will make it harder to maintain later meaning our time savings now are spent later."

In saying that, just because they don't have dev experience doesn't mean their ideas are bad. Sometimes devs are trying to do too much.

[-]

Infiniteh@reddit

Usually you just can't explain it as concisely as that. When you have the whole tech-related context of a project in your head, you can often sense or intuit why something won't work. I might take half an hour to explain everything behind it sufficiently to someone who doesn't understand. And the "why don't you just" suggestions usually come from that kind of person.
I do agree that sometimes an answer like that will help, though.

[-]

Tomicoatl@reddit

If you are unable to explain it then pass it to your manager/leader who can. If that person does not exist then it's time to learn those skills. It is fine to say "no, we cannot do that because of " and leave it there but enough people have been burned by time wasting devs that they are rightfully cautious of over engineering.

[-]

guareber@reddit

"I wish! That was actually my first line of thought but then I dug a bit deeper and found Y and Z"

Makes the person feel validated and heard but moves on the conversation. 60% of the time works every time.

[-]

SmartassRemarks@reddit

Easily the best answer in the thread. I learned to talk to people this way partly from reading “how to win friends and influence people.” Great book I’d recommend to anyone.

[-]

ExpletiveDeIeted@reddit

This very easily may not work or not be what you want to eve present as an option. Thst when it comes to engineering very little is not possible given enough time money etc. however you pretty much get it pick two of these three adjectives. Good, Fast, and Inexpensive.

[-]

throwaway0134hdj@reddit

What if they don’t listen and want it all? I’ve had awful experiences where the manager just chills everything up to you being lazy/not t trying hard enough.

[-]

ExpletiveDeIeted@reddit

Then you need to work on finding a job where your expertise is considered and not ignored.

[-]

CardboardJ@reddit

A project manager did this while I was working in consulting. My answer to him was, "What you can't just convince the client to pay us to make it that simple?"

I had a (not technical in the last decade) CTO start pulling this and my answer was almost always, "That would be easy if the system was free of tech debt. How about we get some of that backlog prioritized?"

Both are kinda the same answer when you really think about it.

[-]

CompetitionOdd1582@reddit

Reframe the conversation. I like asking “What’s the problem you’re wanting to solve here?” and “Who’s experiencing the problem?”

Sometimes it turns out it’s a fix for a ‘what if’ scenario they’ve made up in their head. If that’s the case, I can usually pivot us back to why the other tasks we’re working on should be prioritized higher. Backlog it if you need to, these things tend to get deleted once the next shiny idea comes along.

Sometimes it’s a legitimate issue, but you might have a better way to approach the fix. Talking about the problem opens the door for talking about the appropriate solution, not just their solution.

And sometimes you’re going to find out that they do have a great solution, you just didn’t know about the problem.

Remember, we’re professional problem solvers. It’s part of our value.

[-]

throwaway0134hdj@reddit

XY problem in a nutshell

[-]

CompetitionOdd1582@reddit

Who you calling a nutshell ;)

Seriously though, I had no idea there was a codified name for this. Thanks for teaching me something new!

[-]

throwaway0134hdj@reddit

Spending enough time on SO will do that. Np!

[-]

dexter2011412@reddit

I've seen a senior do this and it was amazing to see how the conversation evolved from there.

[-]

Mammoth-Clock-8173@reddit

I listened to a business solution architect do this with a customer once. Very, very impressive.

[-]

SinkPenguin@reddit

Agree with this one the most. Always link back to "why", and what the goals are. It's incredibly often stakeholders have different why's or just got told the "what" and don't have a clear picture of the end state. So then you can ground "can't you just do X" in the why and discuss trade offs.

[-]

Saki-Sun@reddit

Remember, we’re professional problem solvers. It’s part of our value.

Once you get past the syntax and some knowledge on how to architect solutions, it's pretty much ALL of our value.

[-]

Euphoric-Usual-5169@reddit

I had a project where I constantly got questions “why don’t you just...”. At some point I told a director “here is the code. just do it and submit a PR“. That helped.

[-]

throwaway0134hdj@reddit

That wouldn’t work at most places. But good on you if that worked at your job.

[-]

Euphoric-Usual-5169@reddit

I think it worked because the guy realized that he had pushed it too far with his daily naive suggestions and I was ready to kill him

[-]

throwaway0134hdj@reddit

For sure, these non-tech folks treat us like no feeling robots most of the time

[-]

anaveragedave@reddit

Ooooh I like this. Maybe too snarky for all occasions, but fuggit

[-]

Fluffy_Yesterday_468@reddit

“Sure that sounds great! Do you have access to the repo? Please submit a PR”. There are always non snarky ways to say snarky things

[-]

Euphoric-Usual-5169@reddit

This was preceded by weeks of trying everything and nothing working. At some point you just can’t take it anymore.

[-]

bigbry2k3@reddit

I had that experience once and eventually I just had to figure out how to give them something "close" to what they wanted and explain the technology doesn't exist to make it do XYZ but I can make it do ABC. Would that be good enough?

[-]

throwaway0134hdj@reddit

Sometimes you can just baffle them with some nonsense and they are impressed with it.

[-]

evanvelzen@reddit

I would try to find their underlying motivation and help with that. Are they looking for quick wins? Are they the owner of certain business problems? Are they trying to prove their worth to colleagues?

[-]

throwaway0134hdj@reddit

Root cause analysis is effective

[-]

Ok_Barracuda_1161@reddit

Instead of saying "no, because xyz", say "to do it this way we'd have to consider x and/or run the risk of y and may have to push out the timeline on z"

It doesn't sound like a huge difference and has the same outcome but it comes across as working with them rather than shooting them down

[-]

throwaway0134hdj@reddit

Agreed. You definitely need to learn how to speak their language. Frame thing in terms do costs and risks and delays.

[-]

mercival@reddit

"Thanks for the question, always want them, as some things you think are really hard are quite easy, and vise versa, you never know".

Then get how important it is, how much an MVP could satisfy them, or ask what priorities they want put back on the backburner for it.

[-]

sciencewarrior@reddit

This. The key is remembering that they are an expert on their problem, but you are the expert on delivering solutions. So get them talking about what they are trying to solve instead of how.

[-]

throwaway0134hdj@reddit

This is the classic XY problem. Many ways to skin a cat often the solution isn’t the first swing and could be solved by tossing out the chessboard and coming up with sth new.

[-]

throwaway0134hdj@reddit

Those are the business types. Dealing with them is a nuisance and a half because they don’t think in terms of technical difficulties, and how could they? they don’t code, but bark orders — in their minds everything is possible and it just takes the right negotiation/convincing.

The worst offenders won’t listen to rhyme of reason but just myoptical focus on their vision no matter how unreasonable. They will totally disgraced your concerns as you being difficult. Not all, but some definitely fall on the narcissist spectrum and just want to glorify their goals to the C-suite and you’re some obstacle getting in the way because you won’t do exactly as they want.

[-]

ButWhatIfPotato@reddit

Tell them to raise a ticket, that way they have to actually explain what they want without the whole snide "can't you just" comments. Then you can put in writing on why this will take forever, what are the knock on effects to the codebase and current features in development and what tasks need to be de-prioritized for this to be prioritized (can't you just always implies that something that can be done fast ie now).

[-]

secondhandschnitzel@reddit

I always listen because sometimes these ideas will make my life easier. When it’s a bad idea or I’m not sure, I just keep asking questions until they realize themselves and admit that their idea is not easier or workable. It’s a lot easier to let them fight with themselves.

[-]

Perfekt_Nerd@reddit

This is the way. Just keep asking questions to dig deeper into their idea and eventually they'll hit the point where it falls apart and drop it.

OR they won't because they're a sociopath and don't care about the merit of their idea, just that they're able to jam it down someone's throat. If that's the case, you should either (a) ignore them and do the right thing or (b) update your resume. Maybe both.

[-]

praetor-@reddit

The Socratic method. It works, and if you can keep the right expression and tone it makes you look collaborative instead of adversarial.

[-]

secondhandschnitzel@reddit

It’s very fun to get the sociopaths to completely discredit themselves in front of others by politely asking questions until it’s clear to everyone they’re just being an ass.

[-]

roksah@reddit

Just tell them to put in a change request and get to it when you'll get to it

[-]

diseasealert@reddit

Advice from Adam Savage on this very topic.

[-]

lvlint67@reddit

How do you combat “Can’t you just…”?

If the answer to such a question is ever, "no", the follow up question should be, "Why?"

This isn't the kind of question people should be "combatting".

Technical people like to pretend they are being asked to litterally draw "7 red lines with a blue marker". If you're ever discussing a problem with a colleague and you start to find yourself thinking, "this is a stupid request and this person is clueless..." It's more likely that the communication has broken down.

[-]

armahillo@reddit

Anytime someome says “simply” or “just”, I say:

“Frodo, its a tiny ring and a giant volcano. just toss the ring into it. You cant miss.”

[-]

binarycow@reddit

I use the Wally Reflector

[-]

mxldevs@reddit

They also tend to push back on our answers as to why things aren’t so simple.

Instead of focusing on how complex the task is, I would focus on the fact that you can certainly prioritize this new request, but everything else is going to be pushed back while you focus on this urgent task.

So it's up to them if they're cool with delaying all the other requests they have.

[-]

MocknozzieRiver@reddit

Yup, this is what my team does. Complexity isn't a good reason to not do something. But it pushing back other things is a good one.

Another few things that works at my company is platform instability and bugs or making it so the next thing we do in that area is harder and takes longer. If they're still like, "go for it" then we're going for it. If we think it's a really bad idea, we'll document why and basically make them accept that risk in writing lmao.

[-]

Realistic_Tomato1816@reddit

Man, some people need to work on bed-side manners.

There is a way to deflect this and win confidence/influence.

Focus on being the "Department of How" and not the "Department of No."

Again, there is language, wording to how to steer the questioner in your direction. Wording like, "I hear you, let me repeat or rephrase what you are asking.."

Once you rephrase, it can take their guard down and immediately, you can point out to the "Well, it isn't going to work because of ...."

[-]

alephaleph@reddit (OP)

Why do you assume it’s my bedside manner? I guarantee you I’m not the Dept of No.

I’ve tried your approach, and indeed many others offered by the folks here, with no luck. Im here asking for help so I can remain firmly in the Department of Yes with fresh thinking. I’d appreciate you not making assumptions about me.

[-]

Any-Neat5158@reddit

With enough time, and enough money and enough staff... we absolutely can.

Give rough initial estimates.

"I'd ballpark what your looking to do would take two engineers about a month to get done. If you need a more accurate LOE, we'd need a spike story to spend the time to dig at it some."

That answers the "can't you just".

I remember being asked if I couldn't just ask AI why I was seeing these intermittent failures in our business logic. My answer? "No."

[-]

grateidear@reddit

Recognise that my points below are just a part of the solution but thought it would be good to add.

‘Can’t you just…’ is a phrase I explicitly look out for… I try to politely but explicitly make the point over time that the phrase is usually used when massively underplaying underlying challenges. Eg ‘we have been to the moon. Can’t we just tweak things to go to Mars instead?’

I don’t know what the attitude of the person is like and whether they listen and learn when they make these inquiries, but something to think about is explicitly having a polite conversation about them instead saying ‘what would be involved in doing X?’ , and ‘what would happen if we only do Y?’ It changes the tone of the conversation from challenge to learning together which is more productive.

Very occasionally in my experience, with appropriate senior support we CAN do the ‘just’ thing and cut the Gordian knot. So it’s not a bad thing to keep an eye on from time to time, especially if that massively helps on the technical side.

[-]

mmcnl@reddit

Present a better alternative. Merely answering the question is a 1 vs 1 game. But in a company you're actually in a co-op game.

[-]

rkeet@reddit

"No, but feel free to give it a shot. We use version control, so if it goes awry we can roll back."

[-]

godofavarice_@reddit

I usually interrupt them and go “can’t you just, deez nuts” and they stop asking me.

[-]

JM0ney@reddit

I imagine it's difficult to implement any features or change requests after having been fired. Touche.

[-]

Cahnis@reddit

To be fair, not having a repo to work is the best DX there is.

[-]

Delta1262@reddit

"yeah, sure. just get me a ticket with the list of requirements, expected results, etc... I'll need the ticket in [x] format (provide good example of ticket). Lastly, what's the priority on this? Can it wait, or do I need to tell [someone higher ranking] that their item is going to have to wait until yours is complete?"

85% of the time, the person asking for whatever never delivers the ticket because it's work they don't want to have to do.

10% of the time, they make a partial ticket

4% of the time, they make a legit ticket that I then give to my PM to make sure it properly gets handled in a future sprint

1% of the time it's the CEO demanding I get something done to satisfy his ego, and most often than not, he forgets about it 10 minutes later

[-]

Madscurr@reddit

"I appreciate your engagement in this area, and I'm aware of how delays in this affect your life/work. I never want to suggest that good ideas can't originate outside of the subject matter experts on a topic; afterall, all good ideas sound obvious in retrospect. However, it is my experience that any seemingly straightforward suggestion beginning with 'just' has already been reviewed by those experts and is almost always significantly more involved than a lay-person's awareness or understanding of that thing.

"For instance, when you suggest 'just doing X,' X is or or or or or .

"So while I welcome novel ideas and constructive feedback, I'd appreciate some self-reflection on your part that there exist underlying challenges and complexities before suggesting to me that I 'just' do something."

[-]

chesterjosiah@reddit

This person's instinct to simplify is actually a good thing. Answer them with the actual reason that it isn't as simple as they're suggesting. Repeat for their followups. If the person becomes a bottleneck, offer to have a separate meeting to explain. What we do at my company is write a doc explaining the proposed solution. If you do this you can just have them read that.

[-]

Wide-Pop6050@reddit

Involve them sometimes. Say "sure create the MVP and then I'll review". And then once in a while actually do review it if it has any merit at all. Gets you some good will if they believe you are really considering it.

[-]

Kqyxzoj@reddit

No problem. I'll just allocate hours for this and prioritize it over shall I?

[-]

MMetalRain@reddit

It's a trick question.

Answering "No" might seem like you don't want to work with them or you don't know how to do your job. Answering "Yes" gets you committed into unrealistic projects.

You often have to somehow disarm or dismiss the question.

Disarming could be asking for more details. You might suggest doing this 1-to-1 out of the meeting. "Maybe, can we discuss details after this meeting?". This saves time for others and removes the power play element from the discussion when it's not happening in front of others. You seem more cooperative and actually can be!

Dismission could work when you know there is no way this suggestion is relevant. "Can't you just make the car fly?" "Yes and lets also make it invisible!". This may backfire, but sometimes shuts down followup questions quickly.

[-]

puremourning@reddit

I say “just” is a swear word. And end the conversation

[-]

flavius-as@reddit

Outside your dev team means a paying customer or still within the organization?

If still in the org, play along to a degree, but with their boss or common boss in the CC.

Play stupid instead of playing smart. And ask them to provide the full specification and once you have it, you'll do it as they requested.

Unless they want to self sabotage, most will pick up on the signal and slow down.

[-]

mattgrave@reddit

Just properly discuss about it? Let him/her deep dive in her silly idea, and answer with good enough arguments (dont be too petty) why it doesnt make sense.

[-]

Ok-Yogurt2360@reddit

Talk with them about the behaviour. Take your time and explain them that it is counter-productive in it's current form but that you would like to know what they "hope" to achieve. Find out how he can be helpful if that is his goal or how you could provide information or clarification if it is a problem like that. But be clear that the current way is distracting you and is a cause for unrest.

You could add to this the suggestion to plan a timeslot for these kind of questions. Preferably one where you are the least bothered by these kind of weird suggestions. Knowing when you have to talk with a stressful person is a lot better than being attacked out of nowhere. (Not sure if this is even the case)

[-]

phouchg0@reddit

This is good, they need a talking to or it will continue. I have seen this type many times. Hopefully, they don't know how uninformed they are. A freind once told me to "always assume good intentions". To that I would add, "until they prove otherwise" because intentions occasionally are not good. If this person has been doing this for some time, you should be able to now point to past examples.

"On this occasion you said all we had to do was X, I said there is more to it, we also have to first do A, B, and C in that order. See how that turned out?"

[-]

lab-gone-wrong@reddit

Have a meeting agenda and documentation of the scoped work

If their suggestion is not in the scoped work, let them know that they can request a change to the scope by creating a ticket and it will be evaluated and prioritized in the next planning phase. If they continue to talk, let them know we're sticking to the agenda and can have a separate call or discuss offline once they submit their formal request.

Obviously this only works in functional orgs that will back you up if you do this

[-]

pborenstein@reddit

"If it were implemented the way you think it's implemented, it would be just that easy. But it's not, so it's not."

[-]

Empanatacion@reddit

This being a correct statement doesn't make it a good idea to use it as the response.

[-]

Main-Drag-4975@reddit

They don't think it be like it is, but it do. - Oscar Gamble

[-]

techno_wizard_lizard@reddit

In the past, I took an entire day to make a presentation, along with slides and a ton of specific detail to demonstrate this person how the system actually works and why their suggestions are not going to work.

It was going to last at least two hours. They cut me off at 15 minutes in, saying they get it now. They never again propose something that was wrong while saying “why not just..”

Sometimes all it takes is to educate that person, or even flood them with the intricacies and details. If they are curious they may entertain it. If not, then, you just showed them how much context they are lacking. Either way it’s a win.

[-]

warm_kitchenette@reddit

You might evaluate each conversation to see if they are biz-specific issues (company goals, scenarios), product issues (use cases, UI, UX, feature schedule), and tech issues (tech choices, personnel assignments).

For biz-specific issues, you have a stakeholder here, but they are likely not the only stakeholder even though they "wield outside influences". With them, talk about trade-offs, estimate out any features in a rough way, loop in other stakeholders, have a rational discussion, avoid being buttonholed. Sometimes needs escalation to lead product owner, VP Product, CTO. The main thing is they are likely rational but uninformed.

For product specific issues, if they own it, then that's really their domain. You have them argue with themselves, using feature lists and dependencies that you supply. If they do not own it, you pull in all the owners and agree on priorities. If your company does scrum or bastard scrum or whatever, document and prioritize as is appropriate.

For tech issues, they should get no choices at all, unless it's at major budgeting level (on-prem vs cloud). You can offer choices, if appropriate; you explain, using lots of analogies; but you cannot let this be a free-ranging discussion. Non-developers frequently think they can just tinker with software in a way that they would never with their gas lines at home or their child's cancer medication. You listen to their concerns, you repeat it to make sure you understand it all, you politely decline to let them make tech/coding decisions. If you were surgeon, you would politely push back, no matter the certainty of the patient.

[-]

Eliarece@reddit

My office is filled with these people. My answer is weaponized boredom. Why can't I just do X ? Wow! So nice of you to ask, let me just explain my process, how I work, what I do, why I made these decisions, in excruciating details with a technical language for the next 2 hours.

Most people find a polite way to get out of the conversation within minutes, and I get an excuse to nerd out.

Doesn't work so well in meetings though

[-]

wrex1816@reddit

Learn communication skills. Wild concept for this sub.

[-]

techno_wizard_lizard@reddit

I find it funny and ironic that you say this to OP while at the same time providing zero value in what you just said, showing that you can’t communicate well.

[-]

lordnacho666@reddit

What a hilarious way to deliver a message about how to communicate

[-]

randomInterest92@reddit

Don't fall into the trap, just say "yes, indeed it is easy to do but we are working on other even? Easier things that have bigger impact"

[-]

Comfortable-Tart7734@reddit

Just ignore the complexity and toss it back to them in terms they won't want to touch.

"Sure. Here's the list of priority items I currently have in my queue. Which ones would you like to deprioritize to fit this request in? I'll let you know who to get in touch with to explain why their requests will be delayed. Once you all come to an understanding, I'll get to work."

[-]

kaladin_stormchest@reddit

If you've got enough time before the meeting, diagrams are great for pushing back

[-]

beardguy@reddit

I like to give an answer of “the answer is money, what’s the question?” and then give a rough guess for how big of an ask they have and then ask how important it is.

[-]

ImpetuousWombat@reddit

The stakeholder is glossing over things they don't understand, you need to make that clear. Get "clarification" on their proposals. For example, ask how they propose solving the specific challenges their proposals create. Or how the team should handle the indeterminate delays caused by an unvetted approach.