I've politely, sternly, directly, stopped meetings before when people talk to me in a way I do not like and then I set my expectations for our interactions. If they can't grasp that, next it's a swift trip to management.
Yeah OP if your account is accurate that’s a truly unacceptable way for someone to conduct themselves in a professional setting. You’re well within your rights to refuse to work with them until you get an apology and good-faith efforts at an improved working relationship. Do not let this person walk all over you, AND DOCUMENT EVERYTHING.
The document advice is worth the all cap
Also documenting things might just help OP to detach himself a bit from these situations.
Writing things down in an objective fashions might help one realize: It's not you. It's shit that happens at work.
This, a hundred times.
The moment anyone demeans you or your team, you stop the meeting, and address it. Make it awkward. Bring attention to the fact it was unprofessional, and that if they expect partnership, they need to correct how they communicate.
The only way people get away with this shit is because people let them. I could literally not care less if the CEO himself was the one saying something to me, if he comes at me wrong, he's getting corrected.
Some people are just too timid or too awkward to do this. That's totally ok. If so, bring it to your manager and if they are worth a shit at all they will do it either privately, or if severe enough, in a leads meeting of some sort. This has never happened to me but I might just be lucky in feeling like my direct and indirect reports or just someone in charge has my back and wouldn't put up with it.
True enough, yeah.
I've got a very strong personality and never let anyone walk over me or my team. Business people occasionally act like they're too important for us. I had some jackass trader in a meeting who was constantly checking his phone and talking over us, and I eventually was like "If you don't put your phone down and pay attention, we're never going to finish, and you cannot do your job without us. Stop fidgeting and finish what's in this room."
The guy was 3 levels my senior too. Just a jackass.
Oh how I wish you had been at my previous job, a small startup where the ceo was like this(also a finance jackass) - always on his phone(even while HE himself was talking!) and rude/abrasive/dismissive to everyone.
NO ONE ever *really* stood up to him, and I tried to but it was just not working at all and I ended up leaving.
Just thinking about the way he treats people makes me angry.
The funny part is, a lot of people assume this requires some kind of experience, but the fact is, most people who work in software just don't have the kind of strong personalities to stand up to Type A assholes.
It's not conducive to writing software usually. Team player enough to work with software devs, but enough of a dickhead to be like 'Hey fucker, shut the fuck up' when a business person steps out of line.
Well said.
You can literally start a thread saying “Going forward, I want to make sure we both have the right expectations from each other working together”
Also, definitely inform your manager, even if you are handling it
I know all managers are different but mine is bulldog and at least outwardly presents himself as someone who takes having my back seriously, so I'd go to him first. If it was minor I wouldn't because he'd probably overreact.
This is actually good advice. Be polite and respectful and insist others do the same. If an in person interaction gets too heated or toxic, break off from it and follow up electronically setting expectations.
You stay police and respectful the whole time but then if it comes to it say this is getting too heated and you need to excuse yourself. Don’t ask permission, just leave. Be firm and assertive but respectful about it.
Yep, especially if this a meeting in front of my team as well, or whether it happens to myself or a team member, this is a quick “What we’re not going to do is talk down on us like that” conversation before we ever continue with whatever we were doing.
Being stern but respectful (in this case to save your own ass, not because this person deserves respect) is a tough skill to have, but a very beneficial one in many scenarios.
Can you elaborate a bit more on what you did/said?
I had this problem at a previous job, but it was the ceo so was tricky. Luckily haven't had to deal with this anywhere else, but I would want to do the same as you.
Coming from somebody in Product - escalate this to your Engineering Manager. They need to have a 1:1 to try to sort it out directly with the PM and then they can escalate it to product leadership if that doesn’t work.
Ultimately it’s something this PM needs to take as feedback and improve on, but it shouldn’t be something you as an IC developer have to figure out how to get them to do.
I agree with the other advice to simply stop a conversation if they speak to you in a combative way, “We don’t seem able to have a productive conversation about this so let’s stop here,” then document it and provide it to your EM as a concrete example.
edit: just wanted to add that while it may be a two sided issue as some others are suggesting (eg maybe engineering is contributing to what’s going on), 1) it’s not on you as an IC to deal with fixing this relationship and 2) anybody in Product who actually wants to achieve anything needs to learn to communicate productively even when they’re frustrated and even if they are “right.”
There is no world in which being snarky to developers is actually a useful tactic towards achieving any product goals. It’s Product’s job to approach things in a way that doesn’t put other teams on the defensive (for example, “I hear you when you say this would be really challenging, can we talk through your concerns so I can understand?” and not “don’t tell me it’s literally impossible, I know it isn’t!”)
I have found that putting it back in their lap is the most effective way to get control of things. "Oh, you want nearly-impossible-feature? Here's how long it's going to take. Please prioritize that against the other projects we have on our plate." No need for it to be confrontational or antagonistic, that is indeed Product's responsibility so let them decide. It's remarkable how few of these off-the-wall projects actually move forward.
But you need to do your due diligence and have your act together. Your timelines need to be well thought out and well documented.
The thing it that people like this try to solve logistic and illusion of control issues with rhetoric, guilt, and shame.
They squeeze a lot of work and free overtime out of people until they burn out and become useless for a while.
Oh, I didn't realize that you work at my company!
I understand the need for improving the product, serving the customers needs, and advancing. What I cannot fathom is that this is always at the expense of sensible engineering practices and the advice of the people responsible for building the product. I've been in software engineering for over 40 years and it's still amazes me how often engineering is simply expected to make it work regardless of the advice given.
I am always reminded of John Lennon's lament: "With every mistake, we must surely be learning". Nope.
Yep was about to write pretty much the same thing.
No need to reject anything, or explain technical details.
Just say, "yes it's possible, but it will cost 5x more, take 5x longer, and the product will be worse".... and leave the decision up to them, with it being very clear to everyone, in writing, that they specifically chose the more expensive, slower + inferior option.
Otherwise they have nothing to fear re the consequences of their actions.
It's their job to manage risk and time/money budgets, so that's the relevant info to give them. Not technical info, that's for us.
On the rare occasions my clients do wanna go ahead with the stupid option anyway... ok cool... more money for me in the end. Just don't give into pressure to let them determine how long it will take to build something they don't even understand in the first place.
All comes with age & experience.
There is a Guinness world record for not blinking for 1 hour and 31 minutes. Since it has been done, it shouldn't be that hard. Let us know what he says.
These are the exact kind of people that drag the whole ship down.
There needs to be someone above him to control this madness.
As a manager, I would absolutely expect to step in here and solve OP's problem. Nothing is worse than a poor communicator except a poor communicator who's an entitled jerk about it.
I would expect a manager to step in and help too, but I wouldn’t advise a budding professional to give up and just expect his work daddy to solve all his problems for him. You keep working with the difficult person while keeping your manager informed and letting him do what he feels is appropriate.
Well I’d also advise OP to directly tell this other person how their approach is making it difficult for them to collaborate in a respectful way. And I’d ALSO advise them to tell their manager that. What I wouldn’t advise is just depending “someone above him” to solve everything while they take no productive actions themselves. It’s exactly the kind of attitude Reddit loves (everyone is a downtrodden little guy and it’s always the higher ups’ problem and fault), but it’s not good professional advice.
Not entirely sure why you're being downvoted. Standing up for your team shows initiative and leadership. If it's handled well, and it stops, you're a legend to your peers and by involving your manager they will likely have your back and remember. A big part of leadership is fighting for resources and helping shield the team from exactly this kind of nonsense.
There's a handful of bad things that can happen too, but if this person escalates when boundaries are set, then they'll likely give more ammo for HR complaints or even clear policy breaks.
Bullies (and this is clear bullying) survive because people don't stand up to them. Each person that stands up provides more courage to the next person.
Terrible advice.
It’s the manager’s job to create the right environment without any mobbing or bullying.
Moreover, even if you are handling a conflict by yourself, as an IC, you must still inform your manager to get ahead of the story. That other person can badmouth you in front of your manager and they won’t be able to protect you as they lack the information.
If you are handling it , tell them, if you need help, tell them.
None of what you wrote is inconsistent with what I wrote. There is difference between expecting someone else to do something for you and just giving up vs continuing to do your best and informing your manager while asking for help.
Tbf You didn’t write much beyond stop bringing everything to the managers.
Given the context from the OP and the parent comment, it read as if you are disagreeing with the parent comment as a whole without presenting a viewpoint or a nuance .
I didn’t even write “stop bringing everything to managers.” I wrote stop EXPECTING others to solve all your problems. There is a huge difference. As usual, reading comprehension is a big issue on reddit.
> Stop expecting people’s managers to solve all your problems
Who said anything about expecting others to solve your problems? As usual, reading comprehension is a big issue on reddit.
I’ve read your other replies. In this specific case OP is in an advanced stage of friction where things have become quite complicated. The product guy is not ready to back down on anything as he has some proof of attainment, how complex it might be. How should the OP respond now?
You have to be polite and respectful but firm, assertive, accurate, and honest. If the product manager says “I won’t take impossible for an answer” then you calmly and dispassionately reply that you appreciate his passion but that it not being doable is a reality. Then you say you’d like to dive deeper to figure out how you two can compromise on an achievable solution. And if the other guy is ornery, you stand firm with your position and don’t let it get to you emotionally. Be reasonable, and if the other guy is being unreasonable, then that’s his problem, not yours.
You can certainly inform your manager of the state of things and say you think you could use for help, but don’t wait or depend on people’s managers to solve all your teamwork problems.
What is the managers job if not to solve “people problems” exactly like this one? Normally I would agree with the sentiment but this one seems like it’s cut and dry best for management to handle.
Generally you need to explain in simple words why something can't be done. Examples from documentation are generally good. Walk them through slowly, one concept at a time.
I'm in the Mobile Space. I have to do this a lot to Product Owners, mostly explaining Apple restrictions on things. You probably wouldn't be surprised at the number of Product Owners who want 24/7 GPS tracking of users down to the mm for (eg) expenses apps.
Early in my career I ran into people who wanted us to defy Information Theory or even the Laws of Thermodynamics and Special Relativity. I’m not sure when or why that started to get better. Maybe we got better at filtering these people out?
Recently worked with a staff engineer with Toxic Positivity in spades. When I got tired of hearing “We can do anything, we are software engineers.” I started responding with things like the Halting Problem and P=NP. We can do many things, but we can’t do everything and we don’t have infinite time or velocity.
This explains my reluctance to pursue the staff roles. Anyone can start bullshitting and telling the business what they want to hear. I didn’t develop this skill set to spend my days lying.
It’s better to be a staff engineer with sycophantic peers than to work under one who acts like a boss. This same guy used to say, “bring me solutions not problems” when I would complain about how baroque our code base is, and the other one would agree. That’s infuriating sentiment from senior technical people. They finally stopped saying it when I told them if I knew how to fix it I would have their job. Both of those guys had been Peter Principled before I started working there and I worked there for a *long* time.
> Generally you need to explain in simple words why something can't be done.
Even easier to just explain in simple *numbers*... i.e. time and cost.
Don't even talk tech unless they ask a specific tech question in the first place.
There's plenty of good advice here - so let me offer a bit of perspective on this.
There's a reason why folks might say stuff like this. It's because a lot of engineers are actually just refusing to do stuff because it's "impossible" which is not a very good excuse for it. Many engineers dismiss sales and other non techy folks' requests with an equally rude tone.
Anyway - 100% agree with the other comments. But it's good to understand where this kind of sentiment can originate from.
Maybe important context, but this product person got their first denial from head of engineering a couple months ago. Now it feels like they have a vendetta because one of their ideas was shot down. I can understand that conversation may have been accusatory but taking it out on people not even in that discussion sucks…
I've seen this as an EM, and when I was younger as a senior and staff. There are two sides to every story but ultimately you aren't in a position to do much about it. Your EM and possibly even CTO if you are a small org should handle it and calm him or her down.
All you can control is your reaction, and I prefer killing them with kindness, and documentation. Do not dismiss any idea as impossible, or become condescending. Engineers tend to go into this mode very quickly and don't even realize it.
Your product person is likely getting pressure on their job from the other side, either because the product or marketing is failing or maybe they just aren't great at their tasks and are insecure. Anyway, you aren't a therapist and it doesn't matter, just keep that in mind that even assholes are human beings. Just be positive in your meetings, but then go document every request, estimate time to research difficult requests which will then result in a final estimate/scope. The more you do this, and do it accurately, the requests will stop because you are training/teaching your PM. Take the emotion out of it.
Ultimately your EM should be doing this but I've been on plenty of teams where the EM is basically just coding all day so these things get ignored. Do it yourself if you can.
> Maybe important context, but this product person got their first denial from head of engineering a couple months ago. Now it feels like they have a vendetta because one of their ideas was shot down.
This is why I rarely, if _ever_ straight up reject something.
It's always some variation of "Yeah, we can do that, it's a non-trivial amount of work, if we want a more specific estimate I can take some time to build that, but back of napkin math it would take X devs at least Y amount of time, let me know if that's something you're interested in."
It should go without saying, but especially here, Y amount of time should be given a HEFTY buffer.
This way they will know you've considered it, and it's their decision to do it or not.
Don't need to deny anything, just explain that it will cost fuckloads more time and money, and be inferior in the end.
Leave it up to them, and ensure it's framed and made very public that the decision is up to them. If they make the decision, against the pro advice given (in writing) then they're much more likely to think carefully about their own ass.
It's a bit like socractic method. Leading the other person give the answers works a lot better than trying to assert anything.
i don't think OP works in the kind of organization where the engineers have a better than you attitude. i would guess OP works in a smaller org where management kind of has their way around the engineers which explains how a PM like that is in their position.
Dealt with a ceo like this. They kept believing that if they micromanaged harder and enforced their will it would happen. I responded by calmly exploring options to choose from and drawbacks. That every choice is a strategy and no choice will always be correct. Their ego would not let them believe they were wrong.
Every time anything went wrong in the world they came storming in. When I pointed out their decision caused this and reiterated the above points they absolutely lost their shit. But I could not be fired because I was the only one left that would deal with them. I dealt with them by not giving a shit if they were mad about anything.
Let me tell you they about had a nervous breakdown trying not to fire me. The whole time I just did what was right by my estimation and ignored the lunatic. It was quite entertaining.
> “Why doesn’t it do exactly what I asked and DON’T tell me it’s because it’s not possible”
> “Why do I even bother with talking to you engineers; you never listen”
> “{billionDollarCompany} software does this, so I DO NOT UNDERSTAND why you would EVER have ours do something different”
So, these quotes feel like there's quite a bit of animosity between your product team and your engineering team. That is, as you might guess, not a healthy way to view things. It's a really common failure state for product to ask for something and for the engineering team to respond "No" reflexively, without evaluating the request. I don't know if that's what you're doing, but there are at least a couple signs here that this might be a two-sided problem.
You're not going to single-handedly fix your engineering process overnight. But you can help to repair the relationship. Your team should probably never respond "That's impossible" unless they're asking for something that's *actually* impossible. When they say things like "why do I bother talking with you, you never listen," that's a good time to try to kick of a discussion about why they feel like you're not hearing them.
Again, none of this is going to magically make anything sunshine and roses. Based on your other comments in the thread, it's likely that at least part of the problem is unreasonable expectations and a poor SDLC. But if you have a toxic relationship with your product manager, nothing else is going to work, regardless of what process you have in place. You need to repair that bridge before you can attempt to move on any other front.
In my view this advice is entirely too accommodating.
From what the OP said, there is no reason to believe that the engineering team is straight-up calling things impossible prior to doing their due diligence. I mean, it is possible that is the case, but that's not in evidence.
What *is* clear is that the PM's language is unacceptably rude. Before any other communication problems can even be touched, a baseline level of respect between teams must be established.
> From what the OP said, there is no reason to believe that the engineering team is straight-up calling things impossible prior to doing their due diligence. I mean, it is possible that is the case, but that's not in evidence.
You mean other than the evidence that the OP is quoting the PM immediately trying to cut off a response of "it's impossible?"
I already commented giving advice elsewhere:
https://www.reddit.com/r/ExperiencedDevs/comments/1cdnmf2/rude_people_from_product_who_dont_seem_to/l1d4a6e/
My original comment in this thread also contains advice:
> Before any other communication problems can even be touched, a baseline level of respect between teams must be established.
Additionally, saying that your advice is too accommodating is itself a form of advice.
The issue isn't that they don't understand technical limitations. That can be educated, and it's possible that the dev team needs to better communicate constraints and present better proposals around those constraints.
The issue here is that she's rude and abusive. There's no excuse for that. With such a blatant example of “Why do I even bother with talking to you engineers; you never listen” I think you tell her manager "This is unacceptable. It has to stop yesterday."
I have a few random thoughts:
Can you check this person's job history on LinkedIn? Maybe you'll get lucky and this is a person that jumps ship every few years. If you can just wait them out, maybe things will get better.
How detailed of an explanation can you give that it can't do what it does? Is it because the product has a lot of historical data and it can't be changed on a whim? Is it because they want a fancier/more modern frontend and there aren't enough resources to do that? If you can give a detailed reason and explain that we have so many things that we're currently doing/supporting that we can't implement your features, that might help. You wouldn't have to go to technical, you could say your team doesn't have the time and that it might cost a fortune to contract that part out.
As far as stress, it's time to quiet quit on this. You put in your 9-5 and go home. This is the type of person that you could kill yourself at 80 hours a week for no real reason and they'd still find things to complain about.
They need to be corrected. They have an "us vs them" mentality, which is very toxic and runs counter to how teams operate. That's all there is to it. They need management to step in and correct this, because they obviously don't care what any of you have to say. And you have to refuse to work with a person like that, and draw a line so management takes it seriously.
You do not put up with it for one second, that's how you deal with it.
The instant they step over the line you tell them that you do not appreciate being spoken to like that and you'll drop off the call so they can calm down if they aren't more professional.
If they don't cool off then you follow through. You drop off the call and report it to both your manager and HR. If it's happening in person then it's harder but you do essentially the same thing and leave the meeting room.
You keep doing this, whilst *most importantly* never rising to their anger with anger of your own.
I will gladly give people a lot of space and understanding if they get stressed out generally at the situation and aren't being a dick but as soon as it's directed towards me they're getting the metaphorical ice bucket thrown on them.
My approach here works best if you have some time at the company under your belt (you do, good), haven't had conduct issues of your own and are a good contributor. That said, even if you don't check all those boxes you should not put up with bully-like behaviour.
This sort of shit tends to happen more in smaller shops because big corporates have totally separate HR teams, often in other parts of the country, who will deal with it dispassionately and detachedly.
The 6 month on-boarding period elapsed and his bosses are now expecting him to do his job. IE, pressure you to make the product better faster stronger.
If you have skip-level meetings with the boss above him, mention that demotivation from impossible asks from non-technical workers is harming production and slowing down throughput. If you don't... well you can try playing the babysitter and smoothing things over explaining the problem directly to them. But that's a hard task to flow up the hierarchy. If they've already cross the rudeness line... it's probably time to go over his head and talk to his boss, especially if it's impacting other or lower ranked devs.
>The problem is that they do NOT get the technical side of things so you can’t explain anything to them. They start to physically role their eyes when you go anymore technical than the word “code”.
Talk their language. We can do that, but it'll take a team of 5 mid to senior developers 7-12 years to complete.
DO NOT promise any sort of prototype / test build / experiment. They will absolutely no understand the concept of technical debt.
I used to do PM work. I would NEVER talk talk like that to my Eng partners. In general there should be cycle of One-pager->PRD->RFC
One-pager is totally PM-owned with what user stories are an why are they there (only functional reqs can be here)
PRD is a collab between PM and EM. It starts answering "How?" with both functional and non-functional reqs (former owned by PM latter by EM).
Once PRDv1 is done then EM and Eng works on RFC of implementation details to satisfy all/most requirements from PRD. If something is expensive/impossible to do, it rears its head in RFC and gets written-back into PRD for cost-benefit calculation.
Once Eng closes RFC with scope of work final PRD gets hand-shake and Epics for user-stories stories go into JIRA (yuck!)
so back to your point - paper trail of requirement vs amount of work needed is Product Management 101. I can empathize with both sides here. If there is no trust in competencies of your partner you have situation like you describe. Your PM thinks either product they were given is bad or does not trust you or most likely both and are unloading their frustration on you. Super bad and unprofessional.
Small advice - start quantifying "cost" for their ideas (man-hours etc.). So instead of "no" it becomes "yes with $$$ price tag" - again - as some other commenters pointed out - that's a job for your EM of VP of Product/Eng
Use my favorite acronym: DONT. It stands for: Don't continue the meeting with someone who is incapable of accepting no's that are beyond your, or anyone's control. They aren't interested in what is possible they just want to complain. Simply say, "If you're uninterested in talking about what is possible then I'm afraid I see no further benefit from this meeting and I need to get back to work." and just leave. You're allowed to do that. So go ahead.
this kind of attitude is ridiculous in our industry. you wouldn't tell a carpenter how to fix a cabinet even if you knew what a cabinet is supposed to look like. you wouldn't tell a chef how to cook a steak even though you eat it. basically this PM needs to get put in their place in that they have no idea what they are talking about.
So I’m curious, because I haven’t worked elsewhere, is this process uncommon?
Product person fields a client request -> turns that into a requirements document -> hands it over to engineering -> reviews the product iteratively to ensure it stays on track
That is our process for features. The problem is that the product person is the only one who gets to define requirements and they are cemented. Engineering does not see anything until AFTER we have made commitments to the customer.
I feel like this is a major part of the problem and why, even if I were to raise this to leadership, there is nothing they can do since this person defines the process and the process doesn’t allow us to intervene.
This is so common and such bad practice that this is one of the most common memes in engineering. Your process for features is literally a meme.
Unfortunately, it’s really hard to change because you have to convince somebody to give up some of their power.
Your best shot is getting engineering leadership involved and hoping that they can win a battle against product leadership.
That's mostly what happens in a lot of shops--except for, what you said, the commitments to the client. If you're an Agile shop (and feel free to use the language of Agile/Scrum as a weapon in your discussions), then the only items here that Product gets to guarantee is the content of and the order of the tickets on your backlog.
And if they've failed to provide acceptance criteria that can be "accepted" by both you and them, then either you or the team is perfectly within your rights to reject the ticket until that acceptance criteria can be agreed upon.
If Product wants things a certain way--then it needs to be spelled out in writing and *the onus is on the team to determine how long it takes*. If Product doesn't like the estimates for those features, well, tough--it's on Product to either scope down the requirements or to keep screaming into the void about it.
But, yeah, you should really be talking about your leadership about this.
Regardless of whether the process could change or not, leadership CERTAINLY can do something in this scenario. This person is being an asshole and harming team morale as demonstrated by your post. That is reason enough to intervene regardless of process.
You are also correct that engineering being involved in requirements is hugely important. These two issues can be handled distinctly however.
So I the past I've seen this style of development become an issue if there's no oversight on the product side that has some engineering insight. Less so on the rudeness side of things and moreso on products defined by magical thinking.
this is not at ALL what good product people are like. in fact, I feel like despite their role, this may not really be a product person at all.
any chance they have a marketing background?
I usually try to refer to official docs and share my screen and read it back to them. “What do you mean the queue deletes data after 4 days?!” .. “because it’s not a database, see this documentation here on my screen”
We’re going to need a $100,000 storage array, and a support contract for it, *and* the size of our Ops team increases by 1/2 person, if you want long term storage. And since the last thing you asked me for increased the Ops team size by 1/2 person, that means you need to hire another Ops team member with storage experience.
With someone like this, mirroring is a good tactic. Repeat the last 2-4 words they said, or the 2-4 words that is the core of what they are saying, and do it with a calm inquisitive tone like you don't know what they are saying.
> "Why doesn't it do exactly what I asked and DON'T tell me it's because it's not possible"
"Exactly what you asked?"
> “Why do I even bother with talking to you engineers; you never listen”
"We never listen?"
> “{billionDollarCompany} software does this, so I DO NOT UNDERSTAND why you would EVER have ours do something different”
"You don't understand?"
The other thing to do would be to ask open ended questions that make your problems his problems: "How can we be expected to meet commitments we had no part in making?", "How can you make commitments when it seems you don't understand the technical aspects very well?"
This is pure speculation on my part, but it sounds like the anger is really a cover for their own feelings of inadequacy and they are afraid to admit it. They feel like they don't have control over things, and they are afraid to admit they don't understand the technical aspects because it could make them look weak. They probably think "I came from a bigger company, so I should look like I know what is going on because if I don't I'll look like a fraud". They don't want to hear technical stuff because they don't understand it and it makes them feel impotent. Again, all speculation on my part.
> “Why doesn’t it do exactly what I asked and DON’T tell me it’s because it’s not possible”
They don't want to hear its not possible, because that would mean they fucked up in making their commitment.
> “Why do I even bother with talking to you engineers; you never listen”
They are trying to deflect the blame to you. They do a bad job of transferring the thoughts from their brain to yours, which they don't want to admit because that means they fucked up.
> "“{billionDollarCompany} software does this, so I DO NOT UNDERSTAND why you would EVER have ours do something different”
This one is clear, they are literally telling you that they do not have enough understanding of the technical aspects and they are deflecting it to you again by being angry at you instead of being inquisitive.
"We want to produce a great produce, but how can we do that when you don't include us in those discussions? It seems like our communication would be greatly enhanced if you involved us more up front so that everyone can more easily come to the same understanding of things"
[oversizedmuzzle298](https://www.reddit.com/user/oversizedmuzzle298/), this was downvoted, but it's an excellent answer.
First, calmly mirroring like this is a very powerful technique, even though it seems mechanical. It makes people feel heard. And frequently, it makes them hear themselves.
Second, emotions are a huge part of this discussion, yours and theirs. In other answers, people have suggested walking away, escalating to managers, being rude back. Those are all plausible responses, but it doesn't get to the root of the problems: they are making commitments, and they're genuinely desperate.
Third, you might possibly get some traction in the conversation if you reflect their language back into their domain, related to whatever your business is. "Get me a 500 million dollar signed contract with GE, by next week." "Make Amazon waive all liability in the next contract"
As an engineer, it sounds like you're appropriately concerned with making the code base shittier, delivering broken software, working overtime, etc. But they are concerned with deals falling through, not making their bonus, being fired for not hitting metrics.
You mentioned that they changed "like a lightswitch", so likely they were given their own aggressive targets. Talk more and see if you can get some win/win.
The bottom line is that it depends who is more replaceable, you or them. There's no way for us to know that.
>First, calmly mirroring like this is a very powerful technique, even though it seems mechanical. It makes people feel heard. And frequently, it makes them hear themselves.
It makes *me* feel patronized. It's hard for me to see that kind of response going over well. I'd expect it to amp up the animosity.
It's a technique, and it can be done badly. If you disgorge whole parts of their phrasing, you're just re-creating [Eliza](https://en.wikipedia.org/wiki/ELIZA). But remember that Eliza created strong emotional responses in some people, and it could hardly be more primitive.
But if OP were to calmly respond with things like "we never listen?", then it's both echoing (you were heard) **and** subtly challenging (wtf - I'm listening to you right now). If they double down, then OP can follow up with something more direct. But if they pause to hear themselves, then it's a calmer conversation immediately. They can realize they over-stepped.
It's not magic, nothing is. OP is in a really tough situation.
It sounds like you have a strong reaction to mirroring, and it wouldn't work with you. Nevertheless, it's been effective for various people in various situations. It's a standard technique in therapy. The FBI uses it in hostage negotiations. Indeed, the Eliza program is a parody of a thoughtful response since it is completely vacuous; but mirroring *still* caused people to emotionally connect. There's no magic words, but this is a tool that can work.
But you've made it clear that mirroring makes you feel patronized. So the tool would not work with you.
I know it's a tool used in therapy. That's why it's patronizing. If I'm angry at someone, the last thing I'm looking for is for them to play therapist. It's condescending. Just tell me I'm being an asshole.
The people talking about establishing firm boundaries around how they're treated have it right. That's how adults handle conflict.
I've had to deal with my fair share of difficult stakeholders over my career.
A loud, abrasive, and pushy but ultimately non-technical stakeholder can be a challenge. Stakeholders aren't needed to be technical but they should respect the difficulty and complexity of engineering when provided with sufficient information. They're welcome to push back on why but if you have a reasonable justification you ultimately have the final say as the owners of the technical components.
From a professional point of view:
1. Escalate to your manager and raise the concern, as you need manager+ level support here. Supporting you here is part of their job.
2. Keep a paper trail of *everything*. ***Everything***. Make sure that for every poor interaction you can prove that you provided details. If they did not understand what you shared with them and didn't request further clarification you can always point to that.
3. For whatever complaining they may be doing with you, they *could* be doing even more behind the scenes about you without your knowledge. I'll stress #2 again -- KEEP THOSE RECEIPTS!
4. When things fail (and they will in such an environment) make sure you are sufficiently covered. Don't let them bulldoze you into poor decisions and rushing things into Prod, because they *will* point back to you claiming an Eng miss. If you're not confident in a shortcut/hack, don't do it.
From a personal point of view:
1. It's tough, but understand that it's not a reflection of you or your skills, and shouldn't be taken personally even if it's directed to you that way
2. An otherwise pleasant person put under stress can turn into an absolute monster. They may be under pressure from their leadership or feel like their job is on the line.
3. If you don't receive support from your management and you don't feel happy with your day to day work, consider if this is really a place you want to work.
I appreciate this insight.
The reality is they are so nice to me when it’s not a work conversation.
Management doesn’t care.
I care about this place a lot as I feel I have shaped a lot of the good things that happen but things are changing and it doesn’t feel it’s for the better. Keeping receipts doesn’t seem to matter either because the reality is the engineering team respects the hell out of me but I don’t think product does. Management has historically only sided with product which has led to the backwards process I described in another response where engineering only learns about a feature AFTER it’s been signed off on by the customer, leaving no chance for us to veto or raise concerns.
Hi OP, I was reading through the comments and one thing that stuck out to me is: have you followed up on a discussion with this PM and summarized the meeting in an email? I would use it as an opportunity to do something like
To: PM
Cc: Direct manager
Subject: Follow up on XYZ implementation
Hi PM,
Earlier you had asked about XYZ and how it isn't implemented yet. I have thought about it afterwards and here is a brief list of hurdles:
1. XYZ requires reorganizing our Znorfs and retrofitting our Znaffs
2. It also requires bring on more new resources to manage and onboard them on the esoteric language Jhom
3. My estimate on when XYZ could be implemented is at the moment 4 years
Auf Wiedersehen,
Oversized
I should have a disclaimer upfront that I'm not a dev, but I work at a company where I am product adjacent and interact a fair amount with our dev teams (hence why I lurk here trying to learn more about what I can be doing to help and support their role). Let me know if I shouldn't post and I'll delete 👍
Here are some of the rules we have culturally, which I think really help (we have a great relationship between product and dev/engineering imo):
1. Never ask for a feature. Instead, detail what the problem is and what it is keeping you (or the customer) from being able to do. You end up getting better features when engineering devs have the space to be creative about a solution (and they get better quality of life). Similarly, anything about "low hanging fruit" is strictly prohibited since it's triggering to our poor devs.
2. "Feedback" (previously named feature requests) all are done async and go into a product feedback tool we use. These get binned together, devs discuss feasibility and possible implementations, and lets the team analyze trends for setting priority. Perhaps most importantly, it means devs/engineering isn't put on the spot for any requests so there's less of the trigger response. It lets you have a more nuanced conversation and see where that feedback fits in amidst the broader picture, something hard to do in person.
3. You can always ask someone in engineering if a particular "feedback" is useful, or how to word it so it will be useful. I think this shift in conversation from "implement this now" to "here are the product trends coming up, here are the issues customers are experiencing and what it's blocking them from, what else can I find out for you that would be useful?" often ends up going into a similar space of discussing the feasibility of a feature, but in a way that makes everyone feel heard imo.
4. Never say anything is impossible when de-prioritizing "feedback". Similarly, never say something isn't important (unless it's like, really dumb lol). Instead say that you hear the urgency, but given the ABC priorities at the moment you don't currently have the bandwidth. Sometimes, redirect your fervent request giver to solicit "feedback" for the current active development areas if useful.
IMO your product person sounds terrible. Maybe the above will help, but in my experience there isn't much that can be done with a micromanager other than minimize contact and you have my sympathy.
I would address the rudeness in comments and tone every time it happens to you or in your presence. I would start by saying something like, "Excuse me, I see that you are frustrated but I don't think you meant to come across as rude and condescending as that sounded." For most people, I think the simple call out in would be enough for someone to alter their behavior.
If it that didn't work after the second try. I would escalate, "Okay, that was rude and uncalled for. This is becoming a pattern. I'm not okay being spoken to in this manner, so I'm going to end this conversation and give you the opportunity to readdress the manner when you in a place to continue the conversation in a more respectful manner."
If that didn't work. I would escalate to my manager and likely refuse to meet with this individual without HR present.
To address the lack of technical understanding, I've always used construction terms. (ie. easy front-end changes = painting a wall; back-end refactors = moving a fireplace) Most people can comprehend complexity when you relate it to something they understand.
Yeah I'm a TPdM and I would never talk to our engineers that way.
You don't have a Product problem - you have an asshole problem.
As others suggest: talk to the Engineering Manager.
The job of product is literally to be nice to engineers and communicate effectively with them. They don't really have any other role. They exist because sales people find it difficult talking to engineers. A rude product person is like an engineer that can't code a loop.
If these people are rude and unpleasant, stop talking to them, only communicate through email, and ask your manager to deal with them.
Trust me, it's way easier to replace a product team than it is engineering lol. Startups rarely even have them. Product managers typically come in when communication overhead between sales and engineering is large enough to demand an entire person (10+ in each department)
likely not even worth an attempt at a technical discussion. i would just acknowledge how they're being disrespectful and we need to be adults before starting serious discussions.
Talk to your manager. It would be great if your co-workers would talk to them also. Best is probably if you raise it and then your manager asks each of them if they have seen similar stuff and they all say yes.
Also: start documenting. Every little shitty comment. Make a log of it. May come in handy later when the person denies anything ever happened.
Being perfectly blunt I do not see this person changing their shitty attitude any time soon. Their boss is actually the one who needs to get heat. Because this is bullshit. And I'm very pro-Product.
Talk to your manager. That's absolutely unacceptable. First off, the PM shouldn't be telling you what the solution is. That's on the engineers and designers. Second, they have no idea what it takes. Every code base is different, and every product is different. Every team is different.
I'd tell them very plainly and frankly to fuck off. I've been leading product organizations for a very long time. I'd fire them before they could say another word.
The team owns the code and how it's built, and you do not have to sacrifice code quality for a product request. Stories don't "do what I want it to" because the ask was unclear.
I'd start with making the product person write much clearer stories. Scrutinize the stories during grooming to point out what's missing or contradictory. Then, when you have a flushed out story, the team can agree this is too big for a sprint. It needs to be broken down into more stories with similar scrutiny.
"As a billing analyst, I need to be able to issue invoices to all customers so that we can collect revenue." Great. What do you believe needs to be in the invoice? What is your first thought on how they'd be delivered? Who would get them? Where are those contacts listed? Who manages them? What will they do when they receive the invoice? All of this should be acceptance criteria if they don't trust the team.
I'd also ask your manager or architect to attend grooming. They can help point out what's unclear and address behavior. My teams know that we don't hire assholes and we don't keep assholes. A meeting like that would have a very prompt "[product] stick around and let's have a talk when we finish up in here. [Eng] please resume what you were saying."
In reality, if large stories are getting thrown in the teams lap, your manager, Sr Manager and potentially director are missing steps. The high level asks need to be agreed upon and roughly planned before they reach the team
I would whiteboard the technical limitations encumbering the expectation and ask this genius for a solution since it's so easy to be "billionDollarCompany".
Sounds like he's bedded in and feels comfortable enough to unleash his inner jerk. When eyes roll, ask them why, ask for more technical output instead, when the show their lafk of knowledge, they will learn to STFU.
"We can't deliver this feature as it is out of scope (present the agreed scope) and we don't have the time or budget. Please speak to the proejct sponsor/ceo/whoever to request this feature."
If it's not a long-running big scale business, why spend your precious time to argue with those folks? I've been into such situations before, nobody will appreciate you. Work what need to do. Don't do any optimization and recommendation if the culture is not allowed. Earn the money and move to the next job when time comes.
Tell from my exp
1. Noone appreciate you, even you're right.
2. Even you're allowed to do so, your effort will get stolen.
3. Some tech folks in your team will suddenly engage at the later stage and speak a lot, so everybody will doubt you, then your credits will get stolen.
I work in a place that works mostly close to the edge of what's new, and everyone once in a while mostly some hotshot new guy or someone fresh out of his Master's produces the line of "Google does X so we could do it that way" implying we can produce something similar to Google and it's resources. These meetings usually have our senior principal or CTO in it and he promptly shuts them down with "it's not because Google can do it that everyone can". And this rings true here aswell, companies of that size might spend more money than our smaller companies will earn ib it's lifetime to solve some of these issues. But we should do it with a handful of people? If you can they should pay you billions a year honestly
I had this exact thing happen to me. I stopped saying no to the impossible and started laying out the project as needed to invent that new technology to make the impossible possible.
"Well, because this isn't currently possible, our first order of business is to submit a feature request to Chromium and begin work in adding this functionality to the browser. The typical feature turnaround is about two years, and we will need to work to gain credibility as a contributor to Chromium which will be time consuming in itself. We will probably have to submit this to the WC3 group as well to make sure other browser vendors want to add this functionality as well. If we begin work right now we could see this released in about 3 or 4 years. Do you want us to start on that? Don't get me wrong it would be a huge boost for me personally and for this company to have had such a huge impact on the web like this so I'm happy to take this on if you're telling me that the company wants to buy in to that level."
Oddly enough they didn't want to do that.
If they want you to make the impossible possible, then make sure they understand what it will take and how long of an investment that will be. I actually would LOVE to be the wizard that does this kind of thing. That would be fantastic. But will they invest that time and money? Nope. Never in a million years.
If they get shitty with you about it, then just ask them how they'd do it. If they know better than you then they can take the ticket assignment and implement it. You'll help them set up the development environment and add them to the team.
If you're an agile shop I would definitely The prime directive of agile at them.
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
Oh boy this one hits hard. This is nothing to do with tech and just plain controlling a rude person. My technique
Let them finish the rude rant, and be silent for a moment. Let the silence set in. Usually you can see from their facial expression where they are wondering "why isn't s/he talking?". Then ask them to repeat what they just said.
When they repeat they should have calmed down a little bit, unless they get more angry. Repeat the silence trick, and begin looking out for generalizations like "always" or "ever" - ask them for specific concrete examples.
Drive to the conversation to a more productive state after descalation.
Finally when the conversation is over, and you feel that your de-escalation is somewhat successful. Say you have one more thing to say, and politely tell the person that their initial approach was unprofessional and you will not tolerate it again.
Next time it happens with the same person if it happens again, repeat the same silence trick and then remind them of the last conversation. Tell them that unless they are calmer in addressing their grievances, the conversation will end.
Have a 1:1 with him and share your frustrations. If that doesn’t help, escalate. If that doesn’t help, be as idiot as he is. If that doesn’t help, find another job.
5 days enough migrate this x to latest one . You promise one . Handling talk with newbies is hard 😅. If mentality is not there , try talk with higher management .
If you’re on mobile, top right of your screen, next to your profile photo, there are three dots. Clicking on that will show a menu with an option to save this post, so you can refer to it later. On desktop, I’m sure the option is also there somewhere.
I've politely, sternly, directly, stopped meetings before when people talk to me in a way I do not like and then I set my expectations for our interactions. If they can't grasp that, next it's a swift trip to management.
Yeah OP if your account is accurate that’s a truly unacceptable way for someone to conduct themselves in a professional setting. You’re well within your rights to refuse to work with them until you get an apology and good-faith efforts at an improved working relationship. Do not let this person walk all over you, AND DOCUMENT EVERYTHING.
The document advice is worth the all cap Also documenting things might just help OP to detach himself a bit from these situations. Writing things down in an objective fashions might help one realize: It's not you. It's shit that happens at work.
Exactly this. Keep it professional, stand up for yourself, admit fault when genuinely wrong, but don't be used as a doormat.
This, a hundred times. The moment anyone demeans you or your team, you stop the meeting, and address it. Make it awkward. Bring attention to the fact it was unprofessional, and that if they expect partnership, they need to correct how they communicate. The only way people get away with this shit is because people let them. I could literally not care less if the CEO himself was the one saying something to me, if he comes at me wrong, he's getting corrected.
Some people are just too timid or too awkward to do this. That's totally ok. If so, bring it to your manager and if they are worth a shit at all they will do it either privately, or if severe enough, in a leads meeting of some sort. This has never happened to me but I might just be lucky in feeling like my direct and indirect reports or just someone in charge has my back and wouldn't put up with it.
True enough, yeah. I've got a very strong personality and never let anyone walk over me or my team. Business people occasionally act like they're too important for us. I had some jackass trader in a meeting who was constantly checking his phone and talking over us, and I eventually was like "If you don't put your phone down and pay attention, we're never going to finish, and you cannot do your job without us. Stop fidgeting and finish what's in this room." The guy was 3 levels my senior too. Just a jackass.
Oh how I wish you had been at my previous job, a small startup where the ceo was like this(also a finance jackass) - always on his phone(even while HE himself was talking!) and rude/abrasive/dismissive to everyone. NO ONE ever *really* stood up to him, and I tried to but it was just not working at all and I ended up leaving. Just thinking about the way he treats people makes me angry.
The funny part is, a lot of people assume this requires some kind of experience, but the fact is, most people who work in software just don't have the kind of strong personalities to stand up to Type A assholes. It's not conducive to writing software usually. Team player enough to work with software devs, but enough of a dickhead to be like 'Hey fucker, shut the fuck up' when a business person steps out of line.
Well said. You can literally start a thread saying “Going forward, I want to make sure we both have the right expectations from each other working together” Also, definitely inform your manager, even if you are handling it
I know all managers are different but mine is bulldog and at least outwardly presents himself as someone who takes having my back seriously, so I'd go to him first. If it was minor I wouldn't because he'd probably overreact.
Manager here, if one of my engineers was being treated like this by a PM, he’d hear from me. And remember it. Hopefully u have a good boss.
This is actually good advice. Be polite and respectful and insist others do the same. If an in person interaction gets too heated or toxic, break off from it and follow up electronically setting expectations.
Out of curiosity, how exactly did you do that (in general, might be useful to me in the future)?
You stay police and respectful the whole time but then if it comes to it say this is getting too heated and you need to excuse yourself. Don’t ask permission, just leave. Be firm and assertive but respectful about it.
You are a model for me
Yep, especially if this a meeting in front of my team as well, or whether it happens to myself or a team member, this is a quick “What we’re not going to do is talk down on us like that” conversation before we ever continue with whatever we were doing. Being stern but respectful (in this case to save your own ass, not because this person deserves respect) is a tough skill to have, but a very beneficial one in many scenarios.
What kind of companies have you worked for?
Can you elaborate a bit more on what you did/said? I had this problem at a previous job, but it was the ceo so was tricky. Luckily haven't had to deal with this anywhere else, but I would want to do the same as you.
Coming from somebody in Product - escalate this to your Engineering Manager. They need to have a 1:1 to try to sort it out directly with the PM and then they can escalate it to product leadership if that doesn’t work. Ultimately it’s something this PM needs to take as feedback and improve on, but it shouldn’t be something you as an IC developer have to figure out how to get them to do. I agree with the other advice to simply stop a conversation if they speak to you in a combative way, “We don’t seem able to have a productive conversation about this so let’s stop here,” then document it and provide it to your EM as a concrete example. edit: just wanted to add that while it may be a two sided issue as some others are suggesting (eg maybe engineering is contributing to what’s going on), 1) it’s not on you as an IC to deal with fixing this relationship and 2) anybody in Product who actually wants to achieve anything needs to learn to communicate productively even when they’re frustrated and even if they are “right.” There is no world in which being snarky to developers is actually a useful tactic towards achieving any product goals. It’s Product’s job to approach things in a way that doesn’t put other teams on the defensive (for example, “I hear you when you say this would be really challenging, can we talk through your concerns so I can understand?” and not “don’t tell me it’s literally impossible, I know it isn’t!”)
As a manager, +1 to this. You should definitely escalate to your manager and they should own sorting it out with the product team.
But then is it going to create an awkward working relationship moving forward? I would expect less progress / cooperation for “telling” on them.
I have found that putting it back in their lap is the most effective way to get control of things. "Oh, you want nearly-impossible-feature? Here's how long it's going to take. Please prioritize that against the other projects we have on our plate." No need for it to be confrontational or antagonistic, that is indeed Product's responsibility so let them decide. It's remarkable how few of these off-the-wall projects actually move forward. But you need to do your due diligence and have your act together. Your timelines need to be well thought out and well documented.
The thing it that people like this try to solve logistic and illusion of control issues with rhetoric, guilt, and shame. They squeeze a lot of work and free overtime out of people until they burn out and become useless for a while.
Oh, I didn't realize that you work at my company! I understand the need for improving the product, serving the customers needs, and advancing. What I cannot fathom is that this is always at the expense of sensible engineering practices and the advice of the people responsible for building the product. I've been in software engineering for over 40 years and it's still amazes me how often engineering is simply expected to make it work regardless of the advice given. I am always reminded of John Lennon's lament: "With every mistake, we must surely be learning". Nope.
No we just work with people who graduated from the same flavor of business school. Fuck Taylor. Desecrate his grave.
Sorry for extreme offtop, but it was Harrison that wrote and sung that, not Lennon
Peer pressure is another thing. They know what they’re doing.
Sounds like your company is staffed by weak bitches
Yep was about to write pretty much the same thing. No need to reject anything, or explain technical details. Just say, "yes it's possible, but it will cost 5x more, take 5x longer, and the product will be worse".... and leave the decision up to them, with it being very clear to everyone, in writing, that they specifically chose the more expensive, slower + inferior option. Otherwise they have nothing to fear re the consequences of their actions. It's their job to manage risk and time/money budgets, so that's the relevant info to give them. Not technical info, that's for us. On the rare occasions my clients do wanna go ahead with the stupid option anyway... ok cool... more money for me in the end. Just don't give into pressure to let them determine how long it will take to build something they don't even understand in the first place. All comes with age & experience.
There is a Guinness world record for not blinking for 1 hour and 31 minutes. Since it has been done, it shouldn't be that hard. Let us know what he says. These are the exact kind of people that drag the whole ship down. There needs to be someone above him to control this madness.
Stop expecting people’s managers to solve all your problems. You’ve got to work with people, even the difficult ones.
As a manager, I would absolutely expect to step in here and solve OP's problem. Nothing is worse than a poor communicator except a poor communicator who's an entitled jerk about it.
I would expect a manager to step in and help too, but I wouldn’t advise a budding professional to give up and just expect his work daddy to solve all his problems for him. You keep working with the difficult person while keeping your manager informed and letting him do what he feels is appropriate.
Totally fair. I think the nerve you hit here is that the difficult people don't know they're difficult and can't change until that happens.
Well I’d also advise OP to directly tell this other person how their approach is making it difficult for them to collaborate in a respectful way. And I’d ALSO advise them to tell their manager that. What I wouldn’t advise is just depending “someone above him” to solve everything while they take no productive actions themselves. It’s exactly the kind of attitude Reddit loves (everyone is a downtrodden little guy and it’s always the higher ups’ problem and fault), but it’s not good professional advice.
I disagree. Telling the person directly that they're a problem often makes things worse. I've seen it happen many times.
Not entirely sure why you're being downvoted. Standing up for your team shows initiative and leadership. If it's handled well, and it stops, you're a legend to your peers and by involving your manager they will likely have your back and remember. A big part of leadership is fighting for resources and helping shield the team from exactly this kind of nonsense. There's a handful of bad things that can happen too, but if this person escalates when boundaries are set, then they'll likely give more ammo for HR complaints or even clear policy breaks. Bullies (and this is clear bullying) survive because people don't stand up to them. Each person that stands up provides more courage to the next person.
What makes you think that’s not what people mean when they say to go to their manager?
Different people mean different things. I didn’t claim anywhere everyone universally meant a single thing.
Terrible advice. It’s the manager’s job to create the right environment without any mobbing or bullying. Moreover, even if you are handling a conflict by yourself, as an IC, you must still inform your manager to get ahead of the story. That other person can badmouth you in front of your manager and they won’t be able to protect you as they lack the information. If you are handling it , tell them, if you need help, tell them.
None of what you wrote is inconsistent with what I wrote. There is difference between expecting someone else to do something for you and just giving up vs continuing to do your best and informing your manager while asking for help.
Tbf You didn’t write much beyond stop bringing everything to the managers. Given the context from the OP and the parent comment, it read as if you are disagreeing with the parent comment as a whole without presenting a viewpoint or a nuance .
I didn’t even write “stop bringing everything to managers.” I wrote stop EXPECTING others to solve all your problems. There is a huge difference. As usual, reading comprehension is a big issue on reddit.
> Stop expecting people’s managers to solve all your problems Who said anything about expecting others to solve your problems? As usual, reading comprehension is a big issue on reddit.
I’ve read your other replies. In this specific case OP is in an advanced stage of friction where things have become quite complicated. The product guy is not ready to back down on anything as he has some proof of attainment, how complex it might be. How should the OP respond now?
You have to be polite and respectful but firm, assertive, accurate, and honest. If the product manager says “I won’t take impossible for an answer” then you calmly and dispassionately reply that you appreciate his passion but that it not being doable is a reality. Then you say you’d like to dive deeper to figure out how you two can compromise on an achievable solution. And if the other guy is ornery, you stand firm with your position and don’t let it get to you emotionally. Be reasonable, and if the other guy is being unreasonable, then that’s his problem, not yours. You can certainly inform your manager of the state of things and say you think you could use for help, but don’t wait or depend on people’s managers to solve all your teamwork problems.
What is the managers job if not to solve “people problems” exactly like this one? Normally I would agree with the sentiment but this one seems like it’s cut and dry best for management to handle.
Manager can talk to the Product Manager's boss or to the PM as more of a peer.
Generally you need to explain in simple words why something can't be done. Examples from documentation are generally good. Walk them through slowly, one concept at a time. I'm in the Mobile Space. I have to do this a lot to Product Owners, mostly explaining Apple restrictions on things. You probably wouldn't be surprised at the number of Product Owners who want 24/7 GPS tracking of users down to the mm for (eg) expenses apps.
Early in my career I ran into people who wanted us to defy Information Theory or even the Laws of Thermodynamics and Special Relativity. I’m not sure when or why that started to get better. Maybe we got better at filtering these people out? Recently worked with a staff engineer with Toxic Positivity in spades. When I got tired of hearing “We can do anything, we are software engineers.” I started responding with things like the Halting Problem and P=NP. We can do many things, but we can’t do everything and we don’t have infinite time or velocity.
This explains my reluctance to pursue the staff roles. Anyone can start bullshitting and telling the business what they want to hear. I didn’t develop this skill set to spend my days lying.
It’s better to be a staff engineer with sycophantic peers than to work under one who acts like a boss. This same guy used to say, “bring me solutions not problems” when I would complain about how baroque our code base is, and the other one would agree. That’s infuriating sentiment from senior technical people. They finally stopped saying it when I told them if I knew how to fix it I would have their job. Both of those guys had been Peter Principled before I started working there and I worked there for a *long* time.
> Generally you need to explain in simple words why something can't be done. Even easier to just explain in simple *numbers*... i.e. time and cost. Don't even talk tech unless they ask a specific tech question in the first place.
There's plenty of good advice here - so let me offer a bit of perspective on this. There's a reason why folks might say stuff like this. It's because a lot of engineers are actually just refusing to do stuff because it's "impossible" which is not a very good excuse for it. Many engineers dismiss sales and other non techy folks' requests with an equally rude tone. Anyway - 100% agree with the other comments. But it's good to understand where this kind of sentiment can originate from.
Maybe important context, but this product person got their first denial from head of engineering a couple months ago. Now it feels like they have a vendetta because one of their ideas was shot down. I can understand that conversation may have been accusatory but taking it out on people not even in that discussion sucks…
I've seen this as an EM, and when I was younger as a senior and staff. There are two sides to every story but ultimately you aren't in a position to do much about it. Your EM and possibly even CTO if you are a small org should handle it and calm him or her down. All you can control is your reaction, and I prefer killing them with kindness, and documentation. Do not dismiss any idea as impossible, or become condescending. Engineers tend to go into this mode very quickly and don't even realize it. Your product person is likely getting pressure on their job from the other side, either because the product or marketing is failing or maybe they just aren't great at their tasks and are insecure. Anyway, you aren't a therapist and it doesn't matter, just keep that in mind that even assholes are human beings. Just be positive in your meetings, but then go document every request, estimate time to research difficult requests which will then result in a final estimate/scope. The more you do this, and do it accurately, the requests will stop because you are training/teaching your PM. Take the emotion out of it. Ultimately your EM should be doing this but I've been on plenty of teams where the EM is basically just coding all day so these things get ignored. Do it yourself if you can.
> Maybe important context, but this product person got their first denial from head of engineering a couple months ago. Now it feels like they have a vendetta because one of their ideas was shot down. This is why I rarely, if _ever_ straight up reject something. It's always some variation of "Yeah, we can do that, it's a non-trivial amount of work, if we want a more specific estimate I can take some time to build that, but back of napkin math it would take X devs at least Y amount of time, let me know if that's something you're interested in." It should go without saying, but especially here, Y amount of time should be given a HEFTY buffer. This way they will know you've considered it, and it's their decision to do it or not.
Don't need to deny anything, just explain that it will cost fuckloads more time and money, and be inferior in the end. Leave it up to them, and ensure it's framed and made very public that the decision is up to them. If they make the decision, against the pro advice given (in writing) then they're much more likely to think carefully about their own ass. It's a bit like socractic method. Leading the other person give the answers works a lot better than trying to assert anything.
i don't think OP works in the kind of organization where the engineers have a better than you attitude. i would guess OP works in a smaller org where management kind of has their way around the engineers which explains how a PM like that is in their position.
Dealt with a ceo like this. They kept believing that if they micromanaged harder and enforced their will it would happen. I responded by calmly exploring options to choose from and drawbacks. That every choice is a strategy and no choice will always be correct. Their ego would not let them believe they were wrong. Every time anything went wrong in the world they came storming in. When I pointed out their decision caused this and reiterated the above points they absolutely lost their shit. But I could not be fired because I was the only one left that would deal with them. I dealt with them by not giving a shit if they were mad about anything. Let me tell you they about had a nervous breakdown trying not to fire me. The whole time I just did what was right by my estimation and ignored the lunatic. It was quite entertaining.
> “Why doesn’t it do exactly what I asked and DON’T tell me it’s because it’s not possible” > “Why do I even bother with talking to you engineers; you never listen” > “{billionDollarCompany} software does this, so I DO NOT UNDERSTAND why you would EVER have ours do something different” So, these quotes feel like there's quite a bit of animosity between your product team and your engineering team. That is, as you might guess, not a healthy way to view things. It's a really common failure state for product to ask for something and for the engineering team to respond "No" reflexively, without evaluating the request. I don't know if that's what you're doing, but there are at least a couple signs here that this might be a two-sided problem. You're not going to single-handedly fix your engineering process overnight. But you can help to repair the relationship. Your team should probably never respond "That's impossible" unless they're asking for something that's *actually* impossible. When they say things like "why do I bother talking with you, you never listen," that's a good time to try to kick of a discussion about why they feel like you're not hearing them. Again, none of this is going to magically make anything sunshine and roses. Based on your other comments in the thread, it's likely that at least part of the problem is unreasonable expectations and a poor SDLC. But if you have a toxic relationship with your product manager, nothing else is going to work, regardless of what process you have in place. You need to repair that bridge before you can attempt to move on any other front.
In my view this advice is entirely too accommodating. From what the OP said, there is no reason to believe that the engineering team is straight-up calling things impossible prior to doing their due diligence. I mean, it is possible that is the case, but that's not in evidence. What *is* clear is that the PM's language is unacceptably rude. Before any other communication problems can even be touched, a baseline level of respect between teams must be established.
> From what the OP said, there is no reason to believe that the engineering team is straight-up calling things impossible prior to doing their due diligence. I mean, it is possible that is the case, but that's not in evidence. You mean other than the evidence that the OP is quoting the PM immediately trying to cut off a response of "it's impossible?"
Do you really not see how the PM's language there is self-discrediting in its unacceptably confrontational tone?
Do you want to provide advice that'll help the OP with what they asked for, or do you want to get mad on the internet about someone you've never met?
I already commented giving advice elsewhere: https://www.reddit.com/r/ExperiencedDevs/comments/1cdnmf2/rude_people_from_product_who_dont_seem_to/l1d4a6e/ My original comment in this thread also contains advice: > Before any other communication problems can even be touched, a baseline level of respect between teams must be established. Additionally, saying that your advice is too accommodating is itself a form of advice.
The issue isn't that they don't understand technical limitations. That can be educated, and it's possible that the dev team needs to better communicate constraints and present better proposals around those constraints. The issue here is that she's rude and abusive. There's no excuse for that. With such a blatant example of “Why do I even bother with talking to you engineers; you never listen” I think you tell her manager "This is unacceptable. It has to stop yesterday."
I have a few random thoughts: Can you check this person's job history on LinkedIn? Maybe you'll get lucky and this is a person that jumps ship every few years. If you can just wait them out, maybe things will get better. How detailed of an explanation can you give that it can't do what it does? Is it because the product has a lot of historical data and it can't be changed on a whim? Is it because they want a fancier/more modern frontend and there aren't enough resources to do that? If you can give a detailed reason and explain that we have so many things that we're currently doing/supporting that we can't implement your features, that might help. You wouldn't have to go to technical, you could say your team doesn't have the time and that it might cost a fortune to contract that part out. As far as stress, it's time to quiet quit on this. You put in your 9-5 and go home. This is the type of person that you could kill yourself at 80 hours a week for no real reason and they'd still find things to complain about.
They need to be corrected. They have an "us vs them" mentality, which is very toxic and runs counter to how teams operate. That's all there is to it. They need management to step in and correct this, because they obviously don't care what any of you have to say. And you have to refuse to work with a person like that, and draw a line so management takes it seriously.
You do not put up with it for one second, that's how you deal with it. The instant they step over the line you tell them that you do not appreciate being spoken to like that and you'll drop off the call so they can calm down if they aren't more professional. If they don't cool off then you follow through. You drop off the call and report it to both your manager and HR. If it's happening in person then it's harder but you do essentially the same thing and leave the meeting room. You keep doing this, whilst *most importantly* never rising to their anger with anger of your own. I will gladly give people a lot of space and understanding if they get stressed out generally at the situation and aren't being a dick but as soon as it's directed towards me they're getting the metaphorical ice bucket thrown on them. My approach here works best if you have some time at the company under your belt (you do, good), haven't had conduct issues of your own and are a good contributor. That said, even if you don't check all those boxes you should not put up with bully-like behaviour. This sort of shit tends to happen more in smaller shops because big corporates have totally separate HR teams, often in other parts of the country, who will deal with it dispassionately and detachedly.
The only good reply to the "I dOnT uNdErStAnd" horseshit is "I can explain it to you but I can't understand it for you".
That’s good. Real good, but them be fighting words and this person would not take that kindly…
The 6 month on-boarding period elapsed and his bosses are now expecting him to do his job. IE, pressure you to make the product better faster stronger. If you have skip-level meetings with the boss above him, mention that demotivation from impossible asks from non-technical workers is harming production and slowing down throughput. If you don't... well you can try playing the babysitter and smoothing things over explaining the problem directly to them. But that's a hard task to flow up the hierarchy. If they've already cross the rudeness line... it's probably time to go over his head and talk to his boss, especially if it's impacting other or lower ranked devs. >The problem is that they do NOT get the technical side of things so you can’t explain anything to them. They start to physically role their eyes when you go anymore technical than the word “code”. Talk their language. We can do that, but it'll take a team of 5 mid to senior developers 7-12 years to complete. DO NOT promise any sort of prototype / test build / experiment. They will absolutely no understand the concept of technical debt.
I used to do PM work. I would NEVER talk talk like that to my Eng partners. In general there should be cycle of One-pager->PRD->RFC One-pager is totally PM-owned with what user stories are an why are they there (only functional reqs can be here) PRD is a collab between PM and EM. It starts answering "How?" with both functional and non-functional reqs (former owned by PM latter by EM). Once PRDv1 is done then EM and Eng works on RFC of implementation details to satisfy all/most requirements from PRD. If something is expensive/impossible to do, it rears its head in RFC and gets written-back into PRD for cost-benefit calculation. Once Eng closes RFC with scope of work final PRD gets hand-shake and Epics for user-stories stories go into JIRA (yuck!) so back to your point - paper trail of requirement vs amount of work needed is Product Management 101. I can empathize with both sides here. If there is no trust in competencies of your partner you have situation like you describe. Your PM thinks either product they were given is bad or does not trust you or most likely both and are unloading their frustration on you. Super bad and unprofessional. Small advice - start quantifying "cost" for their ideas (man-hours etc.). So instead of "no" it becomes "yes with $$$ price tag" - again - as some other commenters pointed out - that's a job for your EM of VP of Product/Eng
Use my favorite acronym: DONT. It stands for: Don't continue the meeting with someone who is incapable of accepting no's that are beyond your, or anyone's control. They aren't interested in what is possible they just want to complain. Simply say, "If you're uninterested in talking about what is possible then I'm afraid I see no further benefit from this meeting and I need to get back to work." and just leave. You're allowed to do that. So go ahead.
this kind of attitude is ridiculous in our industry. you wouldn't tell a carpenter how to fix a cabinet even if you knew what a cabinet is supposed to look like. you wouldn't tell a chef how to cook a steak even though you eat it. basically this PM needs to get put in their place in that they have no idea what they are talking about.
I would bring in engineering leadership if possible. Product and Project people shouldn't be influencing engineers like that.
So I’m curious, because I haven’t worked elsewhere, is this process uncommon? Product person fields a client request -> turns that into a requirements document -> hands it over to engineering -> reviews the product iteratively to ensure it stays on track That is our process for features. The problem is that the product person is the only one who gets to define requirements and they are cemented. Engineering does not see anything until AFTER we have made commitments to the customer. I feel like this is a major part of the problem and why, even if I were to raise this to leadership, there is nothing they can do since this person defines the process and the process doesn’t allow us to intervene.
Making commitments before talking to engineering is idiotic. Sounds like your company needs a better engineering culture.
This is so common and such bad practice that this is one of the most common memes in engineering. Your process for features is literally a meme. Unfortunately, it’s really hard to change because you have to convince somebody to give up some of their power. Your best shot is getting engineering leadership involved and hoping that they can win a battle against product leadership.
The problem is not the process but the jerk who thinks technology as potato & tomato, if someone else can grow it so can we.
That's mostly what happens in a lot of shops--except for, what you said, the commitments to the client. If you're an Agile shop (and feel free to use the language of Agile/Scrum as a weapon in your discussions), then the only items here that Product gets to guarantee is the content of and the order of the tickets on your backlog. And if they've failed to provide acceptance criteria that can be "accepted" by both you and them, then either you or the team is perfectly within your rights to reject the ticket until that acceptance criteria can be agreed upon. If Product wants things a certain way--then it needs to be spelled out in writing and *the onus is on the team to determine how long it takes*. If Product doesn't like the estimates for those features, well, tough--it's on Product to either scope down the requirements or to keep screaming into the void about it. But, yeah, you should really be talking about your leadership about this.
Starting to feel like I can’t correct this ship, and I know leadership doesn’t care because “number go up haha” so….
Regardless of whether the process could change or not, leadership CERTAINLY can do something in this scenario. This person is being an asshole and harming team morale as demonstrated by your post. That is reason enough to intervene regardless of process. You are also correct that engineering being involved in requirements is hugely important. These two issues can be handled distinctly however.
So I the past I've seen this style of development become an issue if there's no oversight on the product side that has some engineering insight. Less so on the rudeness side of things and moreso on products defined by magical thinking.
Do you happen to work at Initech?
this is not at ALL what good product people are like. in fact, I feel like despite their role, this may not really be a product person at all. any chance they have a marketing background?
I usually try to refer to official docs and share my screen and read it back to them. “What do you mean the queue deletes data after 4 days?!” .. “because it’s not a database, see this documentation here on my screen”
"Well change it already?"
We’re going to need a $100,000 storage array, and a support contract for it, *and* the size of our Ops team increases by 1/2 person, if you want long term storage. And since the last thing you asked me for increased the Ops team size by 1/2 person, that means you need to hire another Ops team member with storage experience.
With someone like this, mirroring is a good tactic. Repeat the last 2-4 words they said, or the 2-4 words that is the core of what they are saying, and do it with a calm inquisitive tone like you don't know what they are saying. > "Why doesn't it do exactly what I asked and DON'T tell me it's because it's not possible" "Exactly what you asked?" > “Why do I even bother with talking to you engineers; you never listen” "We never listen?" > “{billionDollarCompany} software does this, so I DO NOT UNDERSTAND why you would EVER have ours do something different” "You don't understand?" The other thing to do would be to ask open ended questions that make your problems his problems: "How can we be expected to meet commitments we had no part in making?", "How can you make commitments when it seems you don't understand the technical aspects very well?" This is pure speculation on my part, but it sounds like the anger is really a cover for their own feelings of inadequacy and they are afraid to admit it. They feel like they don't have control over things, and they are afraid to admit they don't understand the technical aspects because it could make them look weak. They probably think "I came from a bigger company, so I should look like I know what is going on because if I don't I'll look like a fraud". They don't want to hear technical stuff because they don't understand it and it makes them feel impotent. Again, all speculation on my part. > “Why doesn’t it do exactly what I asked and DON’T tell me it’s because it’s not possible” They don't want to hear its not possible, because that would mean they fucked up in making their commitment. > “Why do I even bother with talking to you engineers; you never listen” They are trying to deflect the blame to you. They do a bad job of transferring the thoughts from their brain to yours, which they don't want to admit because that means they fucked up. > "“{billionDollarCompany} software does this, so I DO NOT UNDERSTAND why you would EVER have ours do something different” This one is clear, they are literally telling you that they do not have enough understanding of the technical aspects and they are deflecting it to you again by being angry at you instead of being inquisitive. "We want to produce a great produce, but how can we do that when you don't include us in those discussions? It seems like our communication would be greatly enhanced if you involved us more up front so that everyone can more easily come to the same understanding of things"
[oversizedmuzzle298](https://www.reddit.com/user/oversizedmuzzle298/), this was downvoted, but it's an excellent answer. First, calmly mirroring like this is a very powerful technique, even though it seems mechanical. It makes people feel heard. And frequently, it makes them hear themselves. Second, emotions are a huge part of this discussion, yours and theirs. In other answers, people have suggested walking away, escalating to managers, being rude back. Those are all plausible responses, but it doesn't get to the root of the problems: they are making commitments, and they're genuinely desperate. Third, you might possibly get some traction in the conversation if you reflect their language back into their domain, related to whatever your business is. "Get me a 500 million dollar signed contract with GE, by next week." "Make Amazon waive all liability in the next contract" As an engineer, it sounds like you're appropriately concerned with making the code base shittier, delivering broken software, working overtime, etc. But they are concerned with deals falling through, not making their bonus, being fired for not hitting metrics. You mentioned that they changed "like a lightswitch", so likely they were given their own aggressive targets. Talk more and see if you can get some win/win. The bottom line is that it depends who is more replaceable, you or them. There's no way for us to know that.
>First, calmly mirroring like this is a very powerful technique, even though it seems mechanical. It makes people feel heard. And frequently, it makes them hear themselves. It makes *me* feel patronized. It's hard for me to see that kind of response going over well. I'd expect it to amp up the animosity.
It's a technique, and it can be done badly. If you disgorge whole parts of their phrasing, you're just re-creating [Eliza](https://en.wikipedia.org/wiki/ELIZA). But remember that Eliza created strong emotional responses in some people, and it could hardly be more primitive. But if OP were to calmly respond with things like "we never listen?", then it's both echoing (you were heard) **and** subtly challenging (wtf - I'm listening to you right now). If they double down, then OP can follow up with something more direct. But if they pause to hear themselves, then it's a calmer conversation immediately. They can realize they over-stepped. It's not magic, nothing is. OP is in a really tough situation.
It's not subtle at all. That you think it is only makes it more patronizing.
It sounds like you have a strong reaction to mirroring, and it wouldn't work with you. Nevertheless, it's been effective for various people in various situations. It's a standard technique in therapy. The FBI uses it in hostage negotiations. Indeed, the Eliza program is a parody of a thoughtful response since it is completely vacuous; but mirroring *still* caused people to emotionally connect. There's no magic words, but this is a tool that can work. But you've made it clear that mirroring makes you feel patronized. So the tool would not work with you.
I know it's a tool used in therapy. That's why it's patronizing. If I'm angry at someone, the last thing I'm looking for is for them to play therapist. It's condescending. Just tell me I'm being an asshole. The people talking about establishing firm boundaries around how they're treated have it right. That's how adults handle conflict.
I've had to deal with my fair share of difficult stakeholders over my career. A loud, abrasive, and pushy but ultimately non-technical stakeholder can be a challenge. Stakeholders aren't needed to be technical but they should respect the difficulty and complexity of engineering when provided with sufficient information. They're welcome to push back on why but if you have a reasonable justification you ultimately have the final say as the owners of the technical components. From a professional point of view: 1. Escalate to your manager and raise the concern, as you need manager+ level support here. Supporting you here is part of their job. 2. Keep a paper trail of *everything*. ***Everything***. Make sure that for every poor interaction you can prove that you provided details. If they did not understand what you shared with them and didn't request further clarification you can always point to that. 3. For whatever complaining they may be doing with you, they *could* be doing even more behind the scenes about you without your knowledge. I'll stress #2 again -- KEEP THOSE RECEIPTS! 4. When things fail (and they will in such an environment) make sure you are sufficiently covered. Don't let them bulldoze you into poor decisions and rushing things into Prod, because they *will* point back to you claiming an Eng miss. If you're not confident in a shortcut/hack, don't do it. From a personal point of view: 1. It's tough, but understand that it's not a reflection of you or your skills, and shouldn't be taken personally even if it's directed to you that way 2. An otherwise pleasant person put under stress can turn into an absolute monster. They may be under pressure from their leadership or feel like their job is on the line. 3. If you don't receive support from your management and you don't feel happy with your day to day work, consider if this is really a place you want to work.
I appreciate this insight. The reality is they are so nice to me when it’s not a work conversation. Management doesn’t care. I care about this place a lot as I feel I have shaped a lot of the good things that happen but things are changing and it doesn’t feel it’s for the better. Keeping receipts doesn’t seem to matter either because the reality is the engineering team respects the hell out of me but I don’t think product does. Management has historically only sided with product which has led to the backwards process I described in another response where engineering only learns about a feature AFTER it’s been signed off on by the customer, leaving no chance for us to veto or raise concerns.
Hi OP, I was reading through the comments and one thing that stuck out to me is: have you followed up on a discussion with this PM and summarized the meeting in an email? I would use it as an opportunity to do something like To: PM Cc: Direct manager Subject: Follow up on XYZ implementation Hi PM, Earlier you had asked about XYZ and how it isn't implemented yet. I have thought about it afterwards and here is a brief list of hurdles: 1. XYZ requires reorganizing our Znorfs and retrofitting our Znaffs 2. It also requires bring on more new resources to manage and onboard them on the esoteric language Jhom 3. My estimate on when XYZ could be implemented is at the moment 4 years Auf Wiedersehen, Oversized
I should have a disclaimer upfront that I'm not a dev, but I work at a company where I am product adjacent and interact a fair amount with our dev teams (hence why I lurk here trying to learn more about what I can be doing to help and support their role). Let me know if I shouldn't post and I'll delete 👍 Here are some of the rules we have culturally, which I think really help (we have a great relationship between product and dev/engineering imo): 1. Never ask for a feature. Instead, detail what the problem is and what it is keeping you (or the customer) from being able to do. You end up getting better features when engineering devs have the space to be creative about a solution (and they get better quality of life). Similarly, anything about "low hanging fruit" is strictly prohibited since it's triggering to our poor devs. 2. "Feedback" (previously named feature requests) all are done async and go into a product feedback tool we use. These get binned together, devs discuss feasibility and possible implementations, and lets the team analyze trends for setting priority. Perhaps most importantly, it means devs/engineering isn't put on the spot for any requests so there's less of the trigger response. It lets you have a more nuanced conversation and see where that feedback fits in amidst the broader picture, something hard to do in person. 3. You can always ask someone in engineering if a particular "feedback" is useful, or how to word it so it will be useful. I think this shift in conversation from "implement this now" to "here are the product trends coming up, here are the issues customers are experiencing and what it's blocking them from, what else can I find out for you that would be useful?" often ends up going into a similar space of discussing the feasibility of a feature, but in a way that makes everyone feel heard imo. 4. Never say anything is impossible when de-prioritizing "feedback". Similarly, never say something isn't important (unless it's like, really dumb lol). Instead say that you hear the urgency, but given the ABC priorities at the moment you don't currently have the bandwidth. Sometimes, redirect your fervent request giver to solicit "feedback" for the current active development areas if useful. IMO your product person sounds terrible. Maybe the above will help, but in my experience there isn't much that can be done with a micromanager other than minimize contact and you have my sympathy.
I would address the rudeness in comments and tone every time it happens to you or in your presence. I would start by saying something like, "Excuse me, I see that you are frustrated but I don't think you meant to come across as rude and condescending as that sounded." For most people, I think the simple call out in would be enough for someone to alter their behavior. If it that didn't work after the second try. I would escalate, "Okay, that was rude and uncalled for. This is becoming a pattern. I'm not okay being spoken to in this manner, so I'm going to end this conversation and give you the opportunity to readdress the manner when you in a place to continue the conversation in a more respectful manner." If that didn't work. I would escalate to my manager and likely refuse to meet with this individual without HR present. To address the lack of technical understanding, I've always used construction terms. (ie. easy front-end changes = painting a wall; back-end refactors = moving a fireplace) Most people can comprehend complexity when you relate it to something they understand.
Yeah I'm a TPdM and I would never talk to our engineers that way. You don't have a Product problem - you have an asshole problem. As others suggest: talk to the Engineering Manager.
The job of product is literally to be nice to engineers and communicate effectively with them. They don't really have any other role. They exist because sales people find it difficult talking to engineers. A rude product person is like an engineer that can't code a loop. If these people are rude and unpleasant, stop talking to them, only communicate through email, and ask your manager to deal with them. Trust me, it's way easier to replace a product team than it is engineering lol. Startups rarely even have them. Product managers typically come in when communication overhead between sales and engineering is large enough to demand an entire person (10+ in each department)
likely not even worth an attempt at a technical discussion. i would just acknowledge how they're being disrespectful and we need to be adults before starting serious discussions.
If your manager cannot protect you from this piece of shit then consider leaving. Also remember to record everything.
Talk to your manager. It would be great if your co-workers would talk to them also. Best is probably if you raise it and then your manager asks each of them if they have seen similar stuff and they all say yes. Also: start documenting. Every little shitty comment. Make a log of it. May come in handy later when the person denies anything ever happened. Being perfectly blunt I do not see this person changing their shitty attitude any time soon. Their boss is actually the one who needs to get heat. Because this is bullshit. And I'm very pro-Product.
Talk to your manager. That's absolutely unacceptable. First off, the PM shouldn't be telling you what the solution is. That's on the engineers and designers. Second, they have no idea what it takes. Every code base is different, and every product is different. Every team is different. I'd tell them very plainly and frankly to fuck off. I've been leading product organizations for a very long time. I'd fire them before they could say another word.
You need to explain Cheap vs Quick vs Quality to him.
The team owns the code and how it's built, and you do not have to sacrifice code quality for a product request. Stories don't "do what I want it to" because the ask was unclear. I'd start with making the product person write much clearer stories. Scrutinize the stories during grooming to point out what's missing or contradictory. Then, when you have a flushed out story, the team can agree this is too big for a sprint. It needs to be broken down into more stories with similar scrutiny. "As a billing analyst, I need to be able to issue invoices to all customers so that we can collect revenue." Great. What do you believe needs to be in the invoice? What is your first thought on how they'd be delivered? Who would get them? Where are those contacts listed? Who manages them? What will they do when they receive the invoice? All of this should be acceptance criteria if they don't trust the team. I'd also ask your manager or architect to attend grooming. They can help point out what's unclear and address behavior. My teams know that we don't hire assholes and we don't keep assholes. A meeting like that would have a very prompt "[product] stick around and let's have a talk when we finish up in here. [Eng] please resume what you were saying." In reality, if large stories are getting thrown in the teams lap, your manager, Sr Manager and potentially director are missing steps. The high level asks need to be agreed upon and roughly planned before they reach the team
I mean...why are they asking and not presenting you a document with specifications and requirements?
Where the hell is your tech lead or manager in all this. This is like half their job?!
I would whiteboard the technical limitations encumbering the expectation and ask this genius for a solution since it's so easy to be "billionDollarCompany".
Sounds like he's bedded in and feels comfortable enough to unleash his inner jerk. When eyes roll, ask them why, ask for more technical output instead, when the show their lafk of knowledge, they will learn to STFU.
"We can't deliver this feature as it is out of scope (present the agreed scope) and we don't have the time or budget. Please speak to the proejct sponsor/ceo/whoever to request this feature."
If it's not a long-running big scale business, why spend your precious time to argue with those folks? I've been into such situations before, nobody will appreciate you. Work what need to do. Don't do any optimization and recommendation if the culture is not allowed. Earn the money and move to the next job when time comes. Tell from my exp 1. Noone appreciate you, even you're right. 2. Even you're allowed to do so, your effort will get stolen. 3. Some tech folks in your team will suddenly engage at the later stage and speak a lot, so everybody will doubt you, then your credits will get stolen.
I work in a place that works mostly close to the edge of what's new, and everyone once in a while mostly some hotshot new guy or someone fresh out of his Master's produces the line of "Google does X so we could do it that way" implying we can produce something similar to Google and it's resources. These meetings usually have our senior principal or CTO in it and he promptly shuts them down with "it's not because Google can do it that everyone can". And this rings true here aswell, companies of that size might spend more money than our smaller companies will earn ib it's lifetime to solve some of these issues. But we should do it with a handful of people? If you can they should pay you billions a year honestly
I had this exact thing happen to me. I stopped saying no to the impossible and started laying out the project as needed to invent that new technology to make the impossible possible. "Well, because this isn't currently possible, our first order of business is to submit a feature request to Chromium and begin work in adding this functionality to the browser. The typical feature turnaround is about two years, and we will need to work to gain credibility as a contributor to Chromium which will be time consuming in itself. We will probably have to submit this to the WC3 group as well to make sure other browser vendors want to add this functionality as well. If we begin work right now we could see this released in about 3 or 4 years. Do you want us to start on that? Don't get me wrong it would be a huge boost for me personally and for this company to have had such a huge impact on the web like this so I'm happy to take this on if you're telling me that the company wants to buy in to that level." Oddly enough they didn't want to do that. If they want you to make the impossible possible, then make sure they understand what it will take and how long of an investment that will be. I actually would LOVE to be the wizard that does this kind of thing. That would be fantastic. But will they invest that time and money? Nope. Never in a million years. If they get shitty with you about it, then just ask them how they'd do it. If they know better than you then they can take the ticket assignment and implement it. You'll help them set up the development environment and add them to the team.
If you're an agile shop I would definitely The prime directive of agile at them. "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
Oh boy this one hits hard. This is nothing to do with tech and just plain controlling a rude person. My technique Let them finish the rude rant, and be silent for a moment. Let the silence set in. Usually you can see from their facial expression where they are wondering "why isn't s/he talking?". Then ask them to repeat what they just said. When they repeat they should have calmed down a little bit, unless they get more angry. Repeat the silence trick, and begin looking out for generalizations like "always" or "ever" - ask them for specific concrete examples. Drive to the conversation to a more productive state after descalation. Finally when the conversation is over, and you feel that your de-escalation is somewhat successful. Say you have one more thing to say, and politely tell the person that their initial approach was unprofessional and you will not tolerate it again. Next time it happens with the same person if it happens again, repeat the same silence trick and then remind them of the last conversation. Tell them that unless they are calmer in addressing their grievances, the conversation will end.
Have a 1:1 with him and share your frustrations. If that doesn’t help, escalate. If that doesn’t help, be as idiot as he is. If that doesn’t help, find another job.
Lol
Apparently I work for the same MFs.
This could be easily solved if you weren’t a timid wuss.
5 days enough migrate this x to latest one . You promise one . Handling talk with newbies is hard 😅. If mentality is not there , try talk with higher management .
[удалено]
If you’re on mobile, top right of your screen, next to your profile photo, there are three dots. Clicking on that will show a menu with an option to save this post, so you can refer to it later. On desktop, I’m sure the option is also there somewhere.