Live data from Hacker News

Don't Get Your Coworker to Agree with You

workaguide.com

31–40 of 112 posts

Re: Don't Get Your Coworker to Agree with You

#31
> Kara, the icon is wrong

Well, no kidding, if you're literally going up and saying /that/, which doesn't help anything but your ego IMHO.

Learn to deliver criticism properly! How about "I think the icon is misleading: I saw customer X interpret it as ..." or "I think the icon doesn't fit the style of the rest of the thing, look at how all the other ones are using pastel colors and this one ..." or "The icon is too low-res and looks pixelated on my monitor" etc? The point isn't that they are wrong and you are right, it's that it could / should be better in a certain way.

Also, go in with some dignity and not with the assumption that the person is incompetent: perhaps they had some other goal or an absurd deadline or a constraint that they were working around and not "you missed this obvious thing that even I could see, doofus".

Also, first tell the person privately and casually, in an environment where they don't feel pressured to maintain appearances: like it or not, there is a stigma around making mistakes in most offices (or learned behavior on some people's part) that doesn't work to anyone's advantage. So don't blurt out "the icon is wrong" out of nowhere in the middle of a meeting with superiors or "ha ha, GEEEZ DID YOU MESS THIS ONE UP" in the middle of the open office.

Sure, if you've been tactful and helpful and still being ignored and it's important, then raise the issue above the person. But gosh, being tactful is a learnable skill.

---

Edit: I think the quality of the interaction mostly really comes down to: does the person think you're genuinely trying to be helpful or that you're just trying to point out that they're wrong (and perhaps get brownie points yourself)?

Re: Don't Get Your Coworker to Agree with You

#32
Sorry BSVino, but this has been the total opposite of my experience working in UX and UI. I've seen this exact attitude leading to mindless groupthink, and the accumulation of technical or design debt. It doesn't work because it's entirely opinion based, in which case the stronger personality/authority will just force their viewpoint.

What I find works best is to clearly define what results you want from a design change. For example, if you can both agree that it's very important a particular icon is NEVER misunderstood, agreeing on an icon becomes much simpler. If you really disagree, you now have an objective way to measure if it succeeds in it's goal.

Re: Don't Get Your Coworker to Agree with You

#33
For all the critics. "If the cost of reversing the decision and walking back through the door is relatively low, then why should you and your coworker even talk about it?"

The "if the cost is relatively low" is important. We are talking about god damn icon, which can reverted any time, even before going to production.

And now you made me argue with you, instead of let it go. Damn I failed :D

Re: Don't Get Your Coworker to Agree with You

#34
We've all met people like Kara. We have also all met people who think they are always right. So, instead of looking for ways to "win friends and influence people", how about we focus on how to have a productive dialog with coworkers.

It's either you convince them, or perhaps they convince you.

Logic wins.

Re: Don't Get Your Coworker to Agree with You

#35
I think people constantly confuse arguments with fights. Arguments are good they involve an exchange of ideas from which both parties might potentially learn from. All of the best engineering teams I have been part of were built on the backs of people who argued very well.

Fighting is terrible and if it happens in an office context something has gone super wrong.

The idea of letting an argument be won by letting the feature happen and then rolling it back was clearly written by someone who works in a company big enough where projects can swallow the budgetary loss of losing a week of work into something that can't go into production.

Re: Don't Get Your Coworker to Agree with You

#38
post #13

This works well in situations where the cost of a mistake is low and reversible. But often in software the cost is accumulating technical debt that will rarely, if ever, be paid off and driving a potentially successful project to the ground. I don't believe you can have a successful software team with individuals who can't take a code review well. Edit: That being said, there are definitely tactful ways to deliver a…

i'm a pretty mild mannered personality, very reluctant to get angry with other people. i try to be diplomatic with people, at least, in person. one of my worst experiences working on a dev team was checking in code that broke the build. the alpha came into my office and got quite angry with me. it left new emotional wounds and reopened old wounds. it didn't help me become a better programmer, just more fearful and st…

Hey, what happened to "move fast and break things?". Put that poster on your wall, it will work wonders.

In all seriousness though, writing code (and especially production deployments) can sometimes be stressful. Smart people do stupid things sometimes, or some random event occurs, and makes them look that way... after a while, you learn to separate your persona from your work product.

One other thing you start to value after a while, is directness. While sugarcoating things sometimes makes people feel better, most effective teams are good at delivering facts, or if it's an opinion - making a logical case to support it.

Re: Don't Get Your Coworker to Agree with You

#39
As someone who works as a contractor/consultant most of the time, I think this article is ok. In my position I can't just go around tearing into other peoples' work because I have absolutely no social capital (and I like it that way, keeps me from getting into office politics). That means that my coworkers and I have had to learn how to be diplomatic and understanding in disagreements about how the work should be done.

If someone has done X and you think they did it poorly and you think it's important enough to broach the discussion, it's very important to frame the conversation in a constructive way. There's a reason why they did X the way they did, and it almost never comes down to straight negligence. Approach the conversation as a way to understand why they did it that way instead of a way to make them understand why they did it wrong. It's also important to keep in mind that no one likes to be told they did a shit job. Not even you!

Often there are misunderstandings about (not exhaustively):

* Who the stakeholders are

* What the business requirements are

* What the time and resource budget is

* What is the most important thing to get right and what isn't as critical

* What constitutes good work

If multiple viewpoints on these sorts of questions cannot be reconciled by discussion, then it's a problem of leadership and management. Making it a conflict between two individuals is exactly the worst thing to do here. Hopefully discussion can clarify and localize where the disagreements are and those issues can be brought to the attention of the stakeholders that all parties agree should have a say in the decision.

Most importantly, a lot of decision-making comes down to experience. It's virtually impossible to tell someone your experience in a way that teaches them the lesson you learned. This is almost universally the case, whether it's about code architecture or UI design or management decisions or anything. Sometimes you have to let people make the same mistakes you've made in the past and let them learn from them. In such situations it's important to make sure they own the decision that is made so that if and when issues arise later they can get the feedback they need to learn the lesson. The worst case scenario is that they get their way in the decision and someone else has to clean it up later. No one wins from that.

I like being a contractor because I get to work in lots of different environments without being bound to them. I meet a lot of different people who work in very different ways. I've met some people who are truly incompetent (mostly because they refuse to learn anything), but the majority of people I've met who have made mistakes* are willing to improve their craft and will do so if you can create a trusting and constructive relationship with them.

* Let's be honest, the majority of mistakes I've seen have been my own.

Re: Don't Get Your Coworker to Agree with You

#40

Earlier quoted context omitted.

I agree with you, it is important to let the person fail and learn. But sometimes, this can be costly and fixing it may be hard. My approach is to ask the person question and understand what is the objective trying to be achieved, and hope with the answers given, the person realize it is doing a mistake. I also hope that the person respect my experience and is able to learn from my mistakes and do not need to do the…

The problem with Socratic questioning is that it assumes a teacher-student type of relationship, or at least a superior-subordinate one. If that's not the case, and once someone recognizes what it is that you're doing, they may become rightly offended at the arrogance you're displaying by choosing the teacher role for yourself.

“Socratic questioning” implies only a collegial relationship. If you cannot walk over to a colleague and ask them questions about their work without them getting offended, your office politics are extremely unhealthy.

Or else you are probably wearing an expression of disapproval when you ask them these questions. If you go in with an honest “I want to learn and understand” stance, normal people will generally be happy to answer.

Post reply on HN