13 ms·

Don't Get Your Coworker to Agree with You

189 points by BSVino 8y ago

nealdt 8y ago
I'd check that cup again, BSVino - if I were you. I'm sure a lot of people on HN can have similar or greater claims of success as you do on your 'about me'. We wouldn't want to 'display arrogance', would we? :-) Otherwise, nice article. Appreciated.
deleted 8y ago
[deleted]
some_account 8y ago
The problem is that if you are actually do know best, everybody else has to make that mistake and learn, and while doing so, is halting progress that could be made in the right direction. In my world as a software developer, I've found that if my group of colleagues and the boss has very different culture and skills than you do, it's very hard or impossible to influence change. Because the entire group would have to be on the same level of technical experience OR have enough respect for titles or experience to follow someone else, in order for progress to happen.
- leibnizwasright 8y ago
  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 same mistakes in order to learn. But I do not always succeeds in these endeavors. Once a colleague was developing some page objects for Selenium tests and creating classes with only one attribute, which was the full URL of the page. Of course tests would not word when executed in several environments and to have this files were useless. But to fix exactly this, I saw it required more knowledge on OO design than a simple talk could give.
  - LandR 8y ago
    >> But to fix exactly this, I saw it required more knowledge on OO design than a simple talk could give. What do you do in this situation?
    - leibnizwasright 8y ago
      I think that 1st we have to understand that to solve this, every solution is slow. 1st I send some links on OO designs and SOLID principles. 2nd I made a few comments on the code review that tacked more real problem like maintenance, change of URL since we were still in development phase and other pages and dialogs that do not have a URL and how this mixed with the rest that have. 3rd was to have design discussion pior development - which we did not have. For last, some hours during week with the whole team to talk on design and coding, in order to have evryone on a similar level of knowledge.
  - chaosite 8y ago
    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.
    - dpark 8y ago
      “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.
      - chaosite 8y ago
        Of course you can and should always ask your colleagues questions in order to understand their point of view and way of thinking. But that's not what Socratic questioning is. It is specifically when you ask pointed questions, pretending that you don't know the answer already, in order to make the student work out the line of thinking herself, or perhaps force her to flesh out her thinking more completely. It's more about making the askee think than transferring information. As such, trying to mask that behind "I'm just asking questions" is rude.
- pcrh 8y ago
  The article describes a situation where your co-worker is potentially doing something unproductive, and how you can get them to change. The situation where your own boss is making a mistake, and you yourself have to carry out their instructions is much trickier, as you might find yourself being blamed for the inevitable poor outcome.
- iamcasen 8y ago
  This is so spot on it hurts. At my last job, everyone was going about building things completely wrong, and to them it was completely normal! I found it very difficult to work with them because they didn't view me as their superior, so they weren't receptive to me teaching them anything, and whenever I would suggest an idea on a design, they wouldn't have any opinions because they didn't know any better. They would often times ask me to explain why it should be done one way or another, and have me to it in a 30 minute meeting. In reality, it would take us reading a few volumes of computer science text books before they had enough knowledge to understand where I'm even coming from. It was endlessly frustrating.
kennethh 8y ago
Good advice in the article, the relationship is more important than to fight over details but I would recommend using standards. Regarding the change, ask her why she want to change it? How would it give a business advantage for the business? It is a bigger change, write it down so you can evaluate in retrospect -> this is how we improve. If it does not give any business value why should we do it? As they say in the article do not go directly against the proposed change because the person will not remember your arguments only the feeling they had when you said it.
dalore 8y ago
I went through this phase with a difficult coworker over code, would take code reviews personally, developed long running branches in an ivory tower with no input or discussion. Learned to let go and he has his parts of the code base and I have mine. Not ideal, but worked as we were a 2 man dev team at the time. Then he left and we grew the team. Now we got a few minefields left in the code base that anytime we need to add a feature or work in the area we have issues due to technical debt. What could one have done instead? Anyways the situation is a lot better, the new team all mesh well and discuss issues without taking it personally. Take away (probably obvious) is that good communication amongst team members is vital.
- taneq 8y ago
  > What could one have done instead? Got rid of the co-worker much earlier on, by the sounds of it.
  - mikekchar 8y ago
    This is half of the right answer. The part where the OP's story breaks down is "he has his parts of the code base and I have mine". "Letting go" is different than "giving up". "Letting go" means realising that a single decision is not going to destroy the world (unless it is -- then don't let go ;-)). "Giving up" means never trying to find consensus on the rest of the issues. If you can't find a way to work together so that your code is sensible, then one of you should leave -- as quickly as possible. Over a long period of time, if you shut down your communication channels, then you will grow even further apart. This is what leads to the problem. Some people are inflexible. They have a need to have things their own way. They panic if the code is not how they would like it. Don't be that person and don't accept anyone else on the team like that either. Be compassionate and help the person improve, but don't enable their poor behaviour. You're the one who will ultimately pay. But you can't help everyone. And sometimes you can't leave. That's life. Not every situation is fixable.
- majormajor 8y ago
  There's a lot in here that might boil down to how you asked the questions/gave the feedback, but there are also certainly cases where you just aren't getting through to someone. Something I often do there is sanity check my approach with my manager and some trusted coworkers. Did you talk to anyone else about where the two of your coworkers communication was breaking down? Sometimes others have additional perspective on why you aren't getting through to someone since they have a different vantage point. I've also had cases where my manager basically tells me "no, I don't think you're doing anything wrong, let me do some investigation myself" - and if other people have had the same experience as me, that's occasionally led to positive organizational changes such as shifting people around onto different projects where their skills fit better.
samnwa 8y ago
The flaw here is that you assume that "Kara" will learn from her mistakes. Not always the case. Especially in "creative" personality types. Find a creative, rational person if you can.
- flatfilefan 8y ago
  Hehe, or, they will will get replaced as soon as they learn enough to find a better paying position. It’s really a triple choice: 1. Shirtfront the stupidity 2. Build the relationship 3. Avoid the whole thing and work with people who are on the same wavelength
- mirceal 8y ago
  Hah. The tricky part is that some people will learn, some won’t. Some people will look back and cherrypick only things that worked and call it experience. At the end of the day, the question to ask is: who is responsible for the product? If the product owner/boss/ceo is okay with it, who are you to question it? What I do is try to talk through the pros/cons of what the other person wants to do. I will try to challenge what they’re doing with data and/or ask them to show me their data. I am open to being wrong at any point in time (ie try not to come across as judgmental or saying it’s a bad thing). Also, if you’ve seen the same thing in the past, walk through what happened and what you think the worst case scenario is. If your colleague is insecure/anti-social/not interested in learning, you don’t want to work w/ them. I’ve had my share of ‘cowboy’ coders that were ‘moving fast and breaking things’. That’s not sustainable. You need to try to do something about it and not just hopw they will learn their lesson. Huge difference between lack of experience and sloppiness.
hashkb 8y ago
> If the icon is implemented and then Kara realizes their mistake and reverts it, then Kara has learned a valuable lesson that they couldn't have learned otherwise. Plus, they will remember that you were right about this issue when you spoke about it, and that you were respectful about presenting your concerns. In reality... Kara moves the goalposts, declares the icon a success, and implements more useless icons. Your objections are categorized as "crying wolf". Kara gets a promotion, you get managed out, company slowly bleeds cash while everyone rearranges icons.
yosito 8y ago
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 code review. I also don't believe you can have a successful software team with individuals who can't give a code review respectfully.
- HillaryBriss 8y ago
  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 stressed. i've reflected many times on how that message could have been conveyed better. multiple years later, a manager i was working for decided he needed to start writing code and he checked in something that broke the build i was working on. of course, now that the shoe was on the other foot, what do you think i did? i reacted angrily! (lucky for me, he's a good guy with a lot of class and didn't just fire me on the spot. he didn't even react in a negative way.) the lesson i learned is that i need to become classier. still working on that ...
  - Aeolun 8y ago
    As far as comments on a checkin go. The main thing I find is that the way to phrase things is very important. Whatever you do, write any of your thoughts as suggestions instead of tasks to be completed. If you have a decent coworker, they'll know when something is really a problem, and when something is actually up for discussion.
  - mv4 8y ago
    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.
quantumofmalice 8y ago
I have seen more technical damage done by nice and competent people deferring to bullies in the workplace than by legitimate disagreements expressed passionately.
postalrat 8y ago
It's safe to assume Kara wrote this article.
- _zachs 8y ago
  I feel like this is the only comment that needs to be here.
nkg 8y ago
See also: "Dealing with freaking artists when building software on short deadlines"
thisisit 8y ago
But you are a smart and socially conscious human being. You know that you can’t just go to Kara’s desk and tell them “Kara, the icon is wrong.” Kara would get defensive and argue for the the icon. I never understood this logic. How is Kara being offended a smart and socially conscious decision? A better way to handle criticism is to ask for people's opinions and not get defensive. After reading couple of negotiation and similar articles, I started to try and reason with people with carefully crafted questions to guide them towards my goal. But the end result always is that once people realize what I am trying to do, have them remove an icon, they get defensive irrespective. And then argument ensues. The only way I found around this was to build trust. And it takes time, you cannot arrive at a company and start a discussion with Kara. Small talk about family etc helps build some trust. Or if systems fails and resolving it without shaming the original developers helps too. This obviously is not perfect because the time you spend building trust, you are also acquiring issues. But it helps in long run.
- mseebach 8y ago
  > I never understood this logic. How is Kara being offended a smart and socially conscious decision? Because Kara is a human, and humans are weird, emotional creatures. Our primary instinct is to scan any interaction for signs of attack. Thus, your recommendation to build trust is the right one, with trust Kara's prime instinct isn't that you're a potential attacker (and that's the main value of having high trust in teams in general - they are more efficient because they have less friction in communications). But empathy is also important: Kara didn't select the icon because she's a moron, bent on anti-social behaviour. Saying "the icon is wrong" can be understood to imply that, and that implication is, indeed, an attack. Your experience in trying to reason with people might (I obviously don't know you) stem from some measure of lack of empathy - do you enter those interactions with a belief that you're right and the other person is wrong? Try entering them in the spirit of assuming that the other person made the choice they did in good faith, but perhaps did not have all the information you do, then listen, and remember that perhaps you don't have all the information they have, either.
- nhaehnle 8y ago
  > How is Kara being offended a smart and socially conscious decision? That's not what the article is saying. The article is not saying that Kara being offended is smart and socially conscious. The article does not judge whether being offended here is smart or stupid or whatever. What the article is saying is that it is smart and socially conscious to be aware of the fact that Kara is likely going to be offended. It is certainly true that awareness of others' likely reactions is smart and socially conscious. The rest of your comment is pretty much a restatement of the conclusion of the article :)
toopok4k3 8y ago
I'm sorry but no. This is terrible advice. Shit quality will be shit quality. If you really know shit has been done, you need to say so. Not communicating it will just keep the shit flowing. Have some pride in your work!
- underthelevel 8y ago
  Agreed. This must be written by someone out on the west coast.
  - dang 8y ago
    Could you please not post flamebait to Hacker News? We're hoping for better than this here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
bluedino 8y ago
And this is how you end up with a terrible, in-cohesive product.
nchudleigh 8y ago
Parts of this article make sense but only in the reversible case. Arguments are rough- there are many ways to circumvent them. I find with review as long as you provide sound reasoning on why something is wrong and compliment the rest of the work. It's generally received well. Hairy reviews can be avoided by specifying how a project is to be approached beforehand. A one pager on the layout of a project and its components before work gets done does wonders to avoid huge changes at review time.
finchisko 8y ago
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
mbostleman 8y ago
If Kara's emotions and defensiveness can't handle a clearly articulated, rational, objective argument against design decisions, then for the sake of the product and the company, she probably needs to find another job. Avoiding discussions doesn't work for me. I'm happy Steve Jobs didn't read this post.
- dpark 8y ago
  Of course. The obvious answer is always to just fire people. Improving your own communication skills couldn’t possibly be the solution.
  - mbostleman 8y ago
    It's a two way street. Improving one's listening skills and not reacting emotionally is just as important. The general tone of the article sounds to me as if it does not give much priority to the latter. This strikes me as an expression of an over protective approach to people's emotions that limits rational discussion. I see this often and in my experience I find that it has negative effects on organizations and relationships and, in cases like the one in the article, quality and business success.
    - dpark 8y ago
      Sure but you can’t change anyone except yourself. Pressing on Kara and telling her to stop being defensive probably doesn’t accomplish anything except destroying that relationship and making yourself look like the office bully. Kara’s manager can encourage her to work on this, but colleagues cannot realistically. And even the manager’s ability here is extremely limited.
- alleyshack 8y ago
  The thing is, Kara almost certainly has clearly articulated, rational, objective arguments for the design decision in question. If she didn't, she wouldn't be making the decision in the first place. (If she's prone to making decisions willy-nilly with no idea why they're being made, that's a different issue.) So from Kara's point of view, you're getting just as emotional and defensive about, and ignoring clearly articulated, rational, objective arguments for, the decision as you claim she is. Which is the point of the article - if someone goes into a discussion assuming they are the only one who is "objectively correct", they've already failed. I've used the method outlined in the article very often in my career and it almost always works. Often it turns out I was right and we shouldn't have done X - but sometimes it turns out that Kara knew something I didn't, and X worked out way better than I expected.
makmanalp 8y ago
> 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)?
superhuzza 8y ago
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.
mv4 8y ago
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.
batoure 8y ago
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.
Bahamut 8y ago
I think this article misses the important point - you should be able to trust the coworker’s expertise. Present the facts, but leave the decision about the person’s domain to that person.
- dpark 8y ago
  For a trivial issue like the one the article covers, sure. But often decisions have larger impact. The cost of a bad decision can be higher than the cost of fighting for the right decision. If Kara weren’t just designing a single new icon but electing to, say, replace nearly the entire suite of icons with flat iconography, that’s a pretty impactful decision. This significantly impacts the design choices that other designers will have to make. Domain expertise is not always unique to the other person, either. When negotiating with a coworker on a design or feature request, it’s entirely possible that the person asking for the change has more domain expertise than the person empowered to make the choice.
- BSVino 8y ago
  Hello, author of the article here. You're right, I did miss that important point, thanks for pointing it out. I've made some minor updates to the article to account for it. Thanks!
snvzz 8y ago
People who can't take criticism and instead do e.g. get offended should just be given the boot.
danharaj 8y ago
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.
BeetleB 8y ago
I see posts like these once in a while on HN. I suggest folks read some good books on conversations and negotiations. Conversations: Nonviolent Communications: https://www.amazon.com/Nonviolent-Communication-Language-Life-Changing-Relationships/dp/189200528X/ref=sr_1_1?ie=UTF8&qid=1525274332&sr=8-1&keywords=nonviolent+communication https://www.amazon.com/Nonviolent-Communication-Language-Lif... Crucial Conversations: https://www.amazon.com/Crucial-Conversations-Talking-Stakes-Second/dp/0071771328/ref=sr_1_2?ie=UTF8&qid=1525274360&sr=8-2&keywords=crucial+conversations https://www.amazon.com/Crucial-Conversations-Talking-Stakes-... Difficult Conversations: https://www.amazon.com/Difficult-Conversations-Discuss-What-Matters/dp/0143118447/ref=sr_1_2?ie=UTF8&qid=1525274398&sr=8-2&keywords=difficult+conversations https://www.amazon.com/Difficult-Conversations-Discuss-What-... Negotiation books: Bargaining For Advantage: https://www.amazon.com/Bargaining-Advantage-Negotiation-Strategies-Reasonable/dp/0143036971/ref=sr_1_1?ie=UTF8&qid=1525274423&sr=8-1&keywords=bargaining+for+advantage https://www.amazon.com/Bargaining-Advantage-Negotiation-Stra... Getting To Yes: https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Without/dp/0143118757/ref=sr_1_2?ie=UTF8&qid=1525301902&sr=8-2&keywords=Getting+To+yes https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Wit... Getting Past No (billed as a negotiations book, but really more of a conversations book): https://www.amazon.com/Getting-Past-Negotiating-Difficult-Situations/dp/0553371312 https://www.amazon.com/Getting-Past-Negotiating-Difficult-Si... I strongly recommend reading Influence before you read these - much of what is in the books above will make more sense once you've read Influence. https://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/006124189X/ref=sr_1_3?ie=UTF8&qid=1525274472&sr=8-3&keywords=Influence https://www.amazon.com/Influence-Psychology-Persuasion-Rober... When you read these, keep in mind: Change is hard. Don't expect to read these and become good communicators quickly. It may take a few years of stumbling and practice. I see a mixture of comments agreeing and disagreeing with the original submission. For those who disagree: Most of what the author is saying is in agreement with what the books say: If your goal is to change someone, you will either fail, or will succeed at the cost of the relationship (and relationships at work do matter). Another important related point: If you cannot summarize why the other person is acting this way without using phrases like "stubborn", "irrational" or similar negatives, then it means you have no idea about the other person's concerns and motives, and are being lazy. It is easier to label, and much harder to probe effectively. Additionally, people often act stubborn because they realize you are not really interested in their perspective. Internally their thought process (which is very rational) is "This person does not really want to hear me out, so I'm not going to invoke too many neurons engaging with him and will just dig in my heels." - which is why a lot of books focus a lot on listening skills (which includes skills to signal that you are listening - you may in reality be listening just fine but the other person does not know it - so you signal it by summarizing their stance). A lot of the comments here are invoking false dichotomies. Since HN has a comment limit, I'll address some here: >I don't believe you can have a successful software team with individuals who can't take a code review well. This is tangential. You can give feedback in a code review poorly, or efficiently. Both ways allow for you to point out problems with the other's code. One way will not be taken well. The other way has a higher chance of being taken well. A big step forward is to realize you can have your cake and eat it too. >I started to try and reason with people with carefully crafted questions to guide them towards my goal. Leading questions is a bad idea (all the communications books say it). Learn how to state your concerns. It is OK to ask questions if genuinely curious. But if you want to point something out, learn how to state it in a non-defensive manner. (3 separate comments below): >If Kara's emotions and defensiveness can't handle a clearly articulated, rational, objective argument against design decisions, then for the sake of the product and the company, she probably needs to find another job. Avoiding discussions doesn't work for me. >Learned to let go and he has his parts of the code base and I have mine. >And this is how you end up with a terrible, in-cohesive product. Again, false dichotomies. The solution is not to be quiet and let it go. The solution is to learn how to talk about the issues effectively. One of the books calls this "The Fool's Choice" - thinking that either you have to be quiet and not air your concerns (to save relationships), or that you have to air them and damage the relationship. >It's either you convince them, or perhaps they convince you. Logic wins. Logic alone rarely wins. One key point in one of the books: Don't pretend that emotions should not be part of the decision making process. The reality is that emotions are already part of the decision making process. If you get angry that someone cannot take your feedback well, emotions are present. >It's safe to assume Kara wrote this article. It is safe to assume that the author of this comment is unwilling to question his views on the topic. That's what assumptions get you. >I have seen more technical damage done by nice and competent people deferring to bullies in the workplace than by legitimate disagreements expressed passionately. Another false dichotomy. What the submission describes is normal among non-bullies. >The flaw here is that you assume that "Kara" will learn from her mistakes. Not always the case. It is a similar flaw to assume that merely telling her what mistakes she made will make her learn from them. Definitely often not the case.
jlukic 8y ago
In situations with clear org structure the final decision between product disagreements can always be handled by the chain of command. When two product people disagree on a feature, the one higher up the org chart can then make the final call. Feelings are saved because roles are clearly defined, and those with greater product knowledge have the authority they need to "make the call", making the product better overall. For those stuck lower in the org chart, they can rest assured knowing the more good ideas they contribute, the quicker they will rise up the ranks in decision-making authority. When job mobility is also meritocratic and has efficient review processes, those middle managers should be correctly rewarded or punished for making good or bad calls. The problem arises for confrontation more frequently in startups because org-structure is often very loose. It's seen as "undemocratic" to force an issue because of seniority, even if someone may have more experience in a topic. Startups generally the traditional business hierarchy as being inefficient for decision making, because many institutions also fail to properly reward decision-making, or punish bad managers.
- jbattle 8y ago
  We've worked at different companies. I've seen the opposite. In smaller organizations there's more of a ... for lack of a better word ... team spirit. Conflicts rarely devolve to a zero-sum faceoff and people are more likely to be interested in the same goal (i.e. moving the product forward). The bigger the organization, the more muddy the waters. Cryptic territorial fights, all up and down the chain, become a shade coloring a great many decisions. Passing decisions up the chain of command doesn't really sidestep the issues in the article though - cause you still have to decide when to escalate something from "hey, what about this?" to "hey, you are wrong". If anything that's a more drastic step now that you are bringing an issue to An Authority Figure. I do agree that a lot of problems fester because of a lack of clarity about RACI-matrix. That can happen in any size organization, definitely worse in smaller ones.
  - Bartweiss 8y ago
    > The bigger the organization, the more muddy the waters. Cryptic territorial fights, all up and down the chain, become a shade coloring a great many decisions. I heard a story recently of a fairly simple decision that put two territorial groups in conflict. It escalated to the person at the split between branches, who made the decision. Which is fine, except that the arguing parties didn't overlap one or two levels up. A question of "who wins over this one task at one site" landed on the desk of a senior VP overseeing dozens of sites after wasting the time of a half dozen managers who escalated it and fought with each other. At a conservative guess, it cost $2,000 in salary just to decide who would do the task. I think people undervalue how much benefit startups get just from having fewer disagreements that Need An Adult. Passing decisions down from the top is fine, but pushing conflicts up and back down is ridiculously expensive in time, money, and goodwill.
rhapsodic 8y ago
TL;DR: Let your coworker have their way.
godot 8y ago
I actually absolutely agree with everything in this article; but I did find it amusing that the article is titled "How To Get Your Coworker To Agree With You", and the answer is actually, "Don't." The three sections can be summarized into: 1) Stop the first reaction of trying to do it, 2) Check yourself also, 3) Let go. Again, I actually agree with the author, just thought this was amusing, and may not be what readers are expecting going into the article.
- deagle50 8y ago
  Agreed. Clickbait title with a promise of results.
  - karmakaze 8y ago
    The original title doesn't seem like typical clickbait to me though. Literally, the title is inaccurate but does bring in the right audience. I clicked it wanting to solve this issue and was completely turned around by the article. Ultimately it dis resolve my issue with handling disagreements in a manner that would have taken me much longer to understand so clearly.
- dang 8y ago
  Ok, let's try replacing "How to" with "Don't". Or perhaps it should say "How to not"?
- master-litty 8y ago
  Beyond amusing, it's great writing. I see we've already changed the title but I wish we hadn't! I bet it's really persuasive for offenders. 1. Lull the reader into a false sense of security: This article is going to help you with a problem! 2. Really dig into it: Share a highly relevant story and connect with the reader's current frustration. Make it as clear as possible that the reader is understood. 3. Now that you have a shared foundation, introduce your argument. Discussions that start with the argument immediately don't stick as well to a lot of people. Give them a reason to listen.
  - 8y ago
cbsmith 8y ago
I was really expecting a detailed story of kidnapping, water boarding, starvation...
kelvin0 8y ago
Zen of persuasion: don't try to convince others and they will respect you and your opinions. Simple yet quite elegant.
redwolf2 8y ago
My approach would be: 1. Talk to Kara, why she prefers her approach and not yours. Don't tell her that the icon is wrong. Ask her, if the icon could be changed to the other. Maybe she is right and you are wrong. She's the expert in this scenario, not you. If shes professional and her approach is wrong, she will see the mistake and adopt your idea. After that, let it pass and don't go out and tell everyone she was wrong. That's not very humble and fair. 2. If you really think you are right, be subborn. Stubborn people are more successfull then non-stubborn people if you look at statistics. That's why most subborn people are working in management. 3. Don't approach disputes based on a single formula. Be diplomatic, stubborn, helping and supportive. Fight the good fight. 4. Don't talk about the fight club.
- master-litty 8y ago
  >Stubborn people are more successful then non-stubborn people if you look at statistics. Success by what metric and which statistics?
  - redwolf2 8y ago
    https://www.independent.co.uk/news/science/why-stubborn-children-are-more-likely-to-become-successful-a6864966.html https://www.independent.co.uk/news/science/why-stubborn-chil... https://my.apa.org/apa/idm/login.seam?ERIGHTS_TARGET=http%3A%2F%2Fpsycnet.apa.org%2F%3F%26fa%3Dmain.doiLanding%26doi%3D10.1037%2Fdev0000025 https://my.apa.org/apa/idm/login.seam?ERIGHTS_TARGET=http%3A...
ams6110 8y ago
Thought immediately about posting a rant on the obsessive use of "they/their" in a singular context. Pick a pronoun for Kara and use it. Whether he is a she or she is a he, Kara is not a "they" But then I thought, nah. I'll just read something else.
- BSVino 8y ago
  Hello, author of the article here. Kara is a "they". Many people use "they/their" as their singular pronoun. My coworker was one such person. :)
- timtas 8y ago
  "Their resentment may even cause them to push for keeping the icon after it has proven not to be the right thing for your product." Either Kara is more than one person, or this is a grammatical error. It may be an intentional grammatical error but an error nonetheless.
- zerocrates 8y ago
  That's a pretty petty reason. Also, you're only going to see usage of the singular "they" increase, so you'll be skipping a fair amount of content with that policy. Especially in the workplace context, assignment of a particular gender for an example like this is often an issue. Many people (myself included) take the reasonable opinion that "they" is preferable to "he or she," if only on aesthetic grounds.
  - dragonwriter 8y ago
    Singular “they” is a different issue than singular l specific “they”, which is what is used in the article; singular ”they” is a very long established usage, but “they” for a specific named person (even if a hypothetical one) is about as well accepted as “it” for that use. > Many people (myself included) take the reasonable opinion that "they" is preferable to "he or she," if only on aesthetic grounds. “he or she" and similar constructs are also not generally accepted for specific named individuals.
    - 8y ago
lambdasquirrel 8y ago
There's some caveats to all this. The most obvious is that you're right and Kara's wrong. The problem in creative orgs is that it's often hard to tell you apart from Kara. Learning and unlearning are important abilities in a creative setting. Otherwise, it wouldn't be a creative setting. How many of us (in ops) have had to argue with coworkers about the usefulness of configuration management (back when that was becoming the best way to do things), and who now have to talk with coworkers about the need to containerize our build and deployment? So, what might've been wrong (or right) at some point in history, may not be wrong (or right) now. And yes, as others have pointed out, there is usually a lot of technical debt at stake. In UI/UX settings, agreeing with your coworkers (as someone who's done design, talking about engineers), it usually means that you end up with a real stinking pile of a UX, where the designer gets overruled every time unless product intervenes. There's just more engineers than there are designers, and all of the engineers are living in the same bubble. That leads into the other caveat. This strategy works okay when you are in an org with enough clearheaded people (who have the power). With a critical mass of clearheaded people, you can carry forth and the cumulative effect of things going wrong doesn't overwhelm the org's ability to repair them. Are there meta-abilities involved with creativity? I know for my own individual flow, it was important to recognize when I was stuck, and to take a walk. Creative people are often very stubborn, and, maybe this works well in a traditional, management context, but, I'm pretty sure this works against us in our creative bread-and-butter. And, I'm not sure there really is a general way to teach creative ability (whatever that is) that works for everyone, including this fictitious Kara.
- opportune 8y ago
  I think the main point is that it's not about being right. You need to pick the right battles to fight, it's not worth ruining workplace relationships when people dig in their heels over a disagreement about something relatively small
PurpleBoxDragon 8y ago
>The only person who you're responsible for is you. Kara may or may not be making a mistake with the icon, but you're not responsible for it. What happens when the issue is security related? Personally I find myself in a situation where I feel like I'm wasting political capital and hurting myself trying to advocate for security. Is the solution to just... not?
- BSVino 8y ago
  Hi, author of the article here. Security can be a pretty significant cost to the business and if your teammates aren't concerned about it then that's a red flag that maybe you're in the wrong place. But for the time being, yes, consider not. First, consider whether security on your team is a concern at all, for example you're working on an internal tool and you can trust your teammates not to go looking for buffer overflows. Otherwise, the question I have is, why is there no process for dealing with security flaws? Whose responsibility is it to set up that process? Send your discovered flaw to that person and suggest that they set up such a process so that you can submit any future flaws, and then your obligation to the customer is done. If you burn your relationship with your teammates, you give up any chance of influencing them to improve their security practices in the future.
pier25 8y ago
1) If you are responsible for someone else's work and will be blamed for the mistakes of that person you should be able to ask them to change something without any drama. Designers and developers are very prone to drama regarding their work. I've seen this again and again. They become attached to what they've done and can't be objective about it. 2) If you are not responsible for that person's work then, yes, by all means express your opinion in a respectful way and see what happens down the road.
discussedbefore 8y ago
Be likeable or get fired https://news.ycombinator.com/item?id=16883882 https://news.ycombinator.com/item?id=16883882

189 points by BSVino 8y ago

I'd check that cup again, BSVino - if I were you. I'm sure a lot of people on HN can have similar or greater claims of success as you do on your 'about me'. We wouldn't want to 'display arrogance', would we? :-) Otherwise, nice article. Appreciated.

deleted 8y ago

[deleted]

some_account 8y ago

The problem is that if you are actually do know best, everybody else has to make that mistake and learn, and while doing so, is halting progress that could be made in the right direction. In my world as a software developer, I've found that if my group of colleagues and the boss has very different culture and skills than you do, it's very hard or impossible to influence change. Because the entire group would have to be on the same level of technical experience OR have enough respect for titles or experience to follow someone else, in order for progress to happen.

leibnizwasright 8y ago
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 same mistakes in order to learn. But I do not always succeeds in these endeavors. Once a colleague was developing some page objects for Selenium tests and creating classes with only one attribute, which was the full URL of the page. Of course tests would not word when executed in several environments and to have this files were useless. But to fix exactly this, I saw it required more knowledge on OO design than a simple talk could give.
- LandR 8y ago
  >> But to fix exactly this, I saw it required more knowledge on OO design than a simple talk could give. What do you do in this situation?
  - leibnizwasright 8y ago
    I think that 1st we have to understand that to solve this, every solution is slow. 1st I send some links on OO designs and SOLID principles. 2nd I made a few comments on the code review that tacked more real problem like maintenance, change of URL since we were still in development phase and other pages and dialogs that do not have a URL and how this mixed with the rest that have. 3rd was to have design discussion pior development - which we did not have. For last, some hours during week with the whole team to talk on design and coding, in order to have evryone on a similar level of knowledge.
- chaosite 8y ago
  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.
  - dpark 8y ago
    “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.
    - chaosite 8y ago
      Of course you can and should always ask your colleagues questions in order to understand their point of view and way of thinking. But that's not what Socratic questioning is. It is specifically when you ask pointed questions, pretending that you don't know the answer already, in order to make the student work out the line of thinking herself, or perhaps force her to flesh out her thinking more completely. It's more about making the askee think than transferring information. As such, trying to mask that behind "I'm just asking questions" is rude.
pcrh 8y ago
The article describes a situation where your co-worker is potentially doing something unproductive, and how you can get them to change. The situation where your own boss is making a mistake, and you yourself have to carry out their instructions is much trickier, as you might find yourself being blamed for the inevitable poor outcome.
iamcasen 8y ago
This is so spot on it hurts. At my last job, everyone was going about building things completely wrong, and to them it was completely normal! I found it very difficult to work with them because they didn't view me as their superior, so they weren't receptive to me teaching them anything, and whenever I would suggest an idea on a design, they wouldn't have any opinions because they didn't know any better. They would often times ask me to explain why it should be done one way or another, and have me to it in a 30 minute meeting. In reality, it would take us reading a few volumes of computer science text books before they had enough knowledge to understand where I'm even coming from. It was endlessly frustrating.

kennethh 8y ago

Good advice in the article, the relationship is more important than to fight over details but I would recommend using standards. Regarding the change, ask her why she want to change it? How would it give a business advantage for the business? It is a bigger change, write it down so you can evaluate in retrospect -> this is how we improve. If it does not give any business value why should we do it? As they say in the article do not go directly against the proposed change because the person will not remember your arguments only the feeling they had when you said it.

dalore 8y ago

I went through this phase with a difficult coworker over code, would take code reviews personally, developed long running branches in an ivory tower with no input or discussion. Learned to let go and he has his parts of the code base and I have mine. Not ideal, but worked as we were a 2 man dev team at the time. Then he left and we grew the team. Now we got a few minefields left in the code base that anytime we need to add a feature or work in the area we have issues due to technical debt. What could one have done instead? Anyways the situation is a lot better, the new team all mesh well and discuss issues without taking it personally. Take away (probably obvious) is that good communication amongst team members is vital.

taneq 8y ago
> What could one have done instead? Got rid of the co-worker much earlier on, by the sounds of it.
- mikekchar 8y ago
  This is half of the right answer. The part where the OP's story breaks down is "he has his parts of the code base and I have mine". "Letting go" is different than "giving up". "Letting go" means realising that a single decision is not going to destroy the world (unless it is -- then don't let go ;-)). "Giving up" means never trying to find consensus on the rest of the issues. If you can't find a way to work together so that your code is sensible, then one of you should leave -- as quickly as possible. Over a long period of time, if you shut down your communication channels, then you will grow even further apart. This is what leads to the problem. Some people are inflexible. They have a need to have things their own way. They panic if the code is not how they would like it. Don't be that person and don't accept anyone else on the team like that either. Be compassionate and help the person improve, but don't enable their poor behaviour. You're the one who will ultimately pay. But you can't help everyone. And sometimes you can't leave. That's life. Not every situation is fixable.
majormajor 8y ago
There's a lot in here that might boil down to how you asked the questions/gave the feedback, but there are also certainly cases where you just aren't getting through to someone. Something I often do there is sanity check my approach with my manager and some trusted coworkers. Did you talk to anyone else about where the two of your coworkers communication was breaking down? Sometimes others have additional perspective on why you aren't getting through to someone since they have a different vantage point. I've also had cases where my manager basically tells me "no, I don't think you're doing anything wrong, let me do some investigation myself" - and if other people have had the same experience as me, that's occasionally led to positive organizational changes such as shifting people around onto different projects where their skills fit better.

samnwa 8y ago

The flaw here is that you assume that "Kara" will learn from her mistakes. Not always the case. Especially in "creative" personality types. Find a creative, rational person if you can.

flatfilefan 8y ago
Hehe, or, they will will get replaced as soon as they learn enough to find a better paying position. It’s really a triple choice: 1. Shirtfront the stupidity 2. Build the relationship 3. Avoid the whole thing and work with people who are on the same wavelength
mirceal 8y ago
Hah. The tricky part is that some people will learn, some won’t. Some people will look back and cherrypick only things that worked and call it experience. At the end of the day, the question to ask is: who is responsible for the product? If the product owner/boss/ceo is okay with it, who are you to question it? What I do is try to talk through the pros/cons of what the other person wants to do. I will try to challenge what they’re doing with data and/or ask them to show me their data. I am open to being wrong at any point in time (ie try not to come across as judgmental or saying it’s a bad thing). Also, if you’ve seen the same thing in the past, walk through what happened and what you think the worst case scenario is. If your colleague is insecure/anti-social/not interested in learning, you don’t want to work w/ them. I’ve had my share of ‘cowboy’ coders that were ‘moving fast and breaking things’. That’s not sustainable. You need to try to do something about it and not just hopw they will learn their lesson. Huge difference between lack of experience and sloppiness.

hashkb 8y ago

> If the icon is implemented and then Kara realizes their mistake and reverts it, then Kara has learned a valuable lesson that they couldn't have learned otherwise. Plus, they will remember that you were right about this issue when you spoke about it, and that you were respectful about presenting your concerns. In reality... Kara moves the goalposts, declares the icon a success, and implements more useless icons. Your objections are categorized as "crying wolf". Kara gets a promotion, you get managed out, company slowly bleeds cash while everyone rearranges icons.

yosito 8y ago

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 code review. I also don't believe you can have a successful software team with individuals who can't give a code review respectfully.

HillaryBriss 8y ago
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 stressed. i've reflected many times on how that message could have been conveyed better. multiple years later, a manager i was working for decided he needed to start writing code and he checked in something that broke the build i was working on. of course, now that the shoe was on the other foot, what do you think i did? i reacted angrily! (lucky for me, he's a good guy with a lot of class and didn't just fire me on the spot. he didn't even react in a negative way.) the lesson i learned is that i need to become classier. still working on that ...
- Aeolun 8y ago
  As far as comments on a checkin go. The main thing I find is that the way to phrase things is very important. Whatever you do, write any of your thoughts as suggestions instead of tasks to be completed. If you have a decent coworker, they'll know when something is really a problem, and when something is actually up for discussion.
- mv4 8y ago
  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.

quantumofmalice 8y ago

I have seen more technical damage done by nice and competent people deferring to bullies in the workplace than by legitimate disagreements expressed passionately.

postalrat 8y ago

It's safe to assume Kara wrote this article.

_zachs 8y ago
I feel like this is the only comment that needs to be here.

nkg 8y ago

See also: "Dealing with freaking artists when building software on short deadlines"

thisisit 8y ago

But you are a smart and socially conscious human being. You know that you can’t just go to Kara’s desk and tell them “Kara, the icon is wrong.” Kara would get defensive and argue for the the icon. I never understood this logic. How is Kara being offended a smart and socially conscious decision? A better way to handle criticism is to ask for people's opinions and not get defensive. After reading couple of negotiation and similar articles, I started to try and reason with people with carefully crafted questions to guide them towards my goal. But the end result always is that once people realize what I am trying to do, have them remove an icon, they get defensive irrespective. And then argument ensues. The only way I found around this was to build trust. And it takes time, you cannot arrive at a company and start a discussion with Kara. Small talk about family etc helps build some trust. Or if systems fails and resolving it without shaming the original developers helps too. This obviously is not perfect because the time you spend building trust, you are also acquiring issues. But it helps in long run.

mseebach 8y ago
> I never understood this logic. How is Kara being offended a smart and socially conscious decision? Because Kara is a human, and humans are weird, emotional creatures. Our primary instinct is to scan any interaction for signs of attack. Thus, your recommendation to build trust is the right one, with trust Kara's prime instinct isn't that you're a potential attacker (and that's the main value of having high trust in teams in general - they are more efficient because they have less friction in communications). But empathy is also important: Kara didn't select the icon because she's a moron, bent on anti-social behaviour. Saying "the icon is wrong" can be understood to imply that, and that implication is, indeed, an attack. Your experience in trying to reason with people might (I obviously don't know you) stem from some measure of lack of empathy - do you enter those interactions with a belief that you're right and the other person is wrong? Try entering them in the spirit of assuming that the other person made the choice they did in good faith, but perhaps did not have all the information you do, then listen, and remember that perhaps you don't have all the information they have, either.
nhaehnle 8y ago
> How is Kara being offended a smart and socially conscious decision? That's not what the article is saying. The article is not saying that Kara being offended is smart and socially conscious. The article does not judge whether being offended here is smart or stupid or whatever. What the article is saying is that it is smart and socially conscious to be aware of the fact that Kara is likely going to be offended. It is certainly true that awareness of others' likely reactions is smart and socially conscious. The rest of your comment is pretty much a restatement of the conclusion of the article :)

toopok4k3 8y ago

I'm sorry but no. This is terrible advice. Shit quality will be shit quality. If you really know shit has been done, you need to say so. Not communicating it will just keep the shit flowing. Have some pride in your work!

underthelevel 8y ago
Agreed. This must be written by someone out on the west coast.
- dang 8y ago
  Could you please not post flamebait to Hacker News? We're hoping for better than this here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

bluedino 8y ago

And this is how you end up with a terrible, in-cohesive product.

nchudleigh 8y ago

Parts of this article make sense but only in the reversible case. Arguments are rough- there are many ways to circumvent them. I find with review as long as you provide sound reasoning on why something is wrong and compliment the rest of the work. It's generally received well. Hairy reviews can be avoided by specifying how a project is to be approached beforehand. A one pager on the layout of a project and its components before work gets done does wonders to avoid huge changes at review time.

finchisko 8y ago

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

mbostleman 8y ago

If Kara's emotions and defensiveness can't handle a clearly articulated, rational, objective argument against design decisions, then for the sake of the product and the company, she probably needs to find another job. Avoiding discussions doesn't work for me. I'm happy Steve Jobs didn't read this post.

dpark 8y ago
Of course. The obvious answer is always to just fire people. Improving your own communication skills couldn’t possibly be the solution.
- mbostleman 8y ago
  It's a two way street. Improving one's listening skills and not reacting emotionally is just as important. The general tone of the article sounds to me as if it does not give much priority to the latter. This strikes me as an expression of an over protective approach to people's emotions that limits rational discussion. I see this often and in my experience I find that it has negative effects on organizations and relationships and, in cases like the one in the article, quality and business success.
  - dpark 8y ago
    Sure but you can’t change anyone except yourself. Pressing on Kara and telling her to stop being defensive probably doesn’t accomplish anything except destroying that relationship and making yourself look like the office bully. Kara’s manager can encourage her to work on this, but colleagues cannot realistically. And even the manager’s ability here is extremely limited.
alleyshack 8y ago
The thing is, Kara almost certainly has clearly articulated, rational, objective arguments for the design decision in question. If she didn't, she wouldn't be making the decision in the first place. (If she's prone to making decisions willy-nilly with no idea why they're being made, that's a different issue.) So from Kara's point of view, you're getting just as emotional and defensive about, and ignoring clearly articulated, rational, objective arguments for, the decision as you claim she is. Which is the point of the article - if someone goes into a discussion assuming they are the only one who is "objectively correct", they've already failed. I've used the method outlined in the article very often in my career and it almost always works. Often it turns out I was right and we shouldn't have done X - but sometimes it turns out that Kara knew something I didn't, and X worked out way better than I expected.

makmanalp 8y ago

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

superhuzza 8y ago

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.

mv4 8y ago

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.

batoure 8y ago

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.

Bahamut 8y ago

I think this article misses the important point - you should be able to trust the coworker’s expertise. Present the facts, but leave the decision about the person’s domain to that person.

dpark 8y ago
For a trivial issue like the one the article covers, sure. But often decisions have larger impact. The cost of a bad decision can be higher than the cost of fighting for the right decision. If Kara weren’t just designing a single new icon but electing to, say, replace nearly the entire suite of icons with flat iconography, that’s a pretty impactful decision. This significantly impacts the design choices that other designers will have to make. Domain expertise is not always unique to the other person, either. When negotiating with a coworker on a design or feature request, it’s entirely possible that the person asking for the change has more domain expertise than the person empowered to make the choice.
BSVino 8y ago
Hello, author of the article here. You're right, I did miss that important point, thanks for pointing it out. I've made some minor updates to the article to account for it. Thanks!

snvzz 8y ago

People who can't take criticism and instead do e.g. get offended should just be given the boot.

danharaj 8y ago

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.

BeetleB 8y ago

I see posts like these once in a while on HN. I suggest folks read some good books on conversations and negotiations. Conversations: Nonviolent Communications: https://www.amazon.com/Nonviolent-Communication-Language-Life-Changing-Relationships/dp/189200528X/ref=sr_1_1?ie=UTF8&qid=1525274332&sr=8-1&keywords=nonviolent+communication https://www.amazon.com/Nonviolent-Communication-Language-Lif... Crucial Conversations: https://www.amazon.com/Crucial-Conversations-Talking-Stakes-Second/dp/0071771328/ref=sr_1_2?ie=UTF8&qid=1525274360&sr=8-2&keywords=crucial+conversations https://www.amazon.com/Crucial-Conversations-Talking-Stakes-... Difficult Conversations: https://www.amazon.com/Difficult-Conversations-Discuss-What-Matters/dp/0143118447/ref=sr_1_2?ie=UTF8&qid=1525274398&sr=8-2&keywords=difficult+conversations https://www.amazon.com/Difficult-Conversations-Discuss-What-... Negotiation books: Bargaining For Advantage: https://www.amazon.com/Bargaining-Advantage-Negotiation-Strategies-Reasonable/dp/0143036971/ref=sr_1_1?ie=UTF8&qid=1525274423&sr=8-1&keywords=bargaining+for+advantage https://www.amazon.com/Bargaining-Advantage-Negotiation-Stra... Getting To Yes: https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Without/dp/0143118757/ref=sr_1_2?ie=UTF8&qid=1525301902&sr=8-2&keywords=Getting+To+yes https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Wit... Getting Past No (billed as a negotiations book, but really more of a conversations book): https://www.amazon.com/Getting-Past-Negotiating-Difficult-Situations/dp/0553371312 https://www.amazon.com/Getting-Past-Negotiating-Difficult-Si... I strongly recommend reading Influence before you read these - much of what is in the books above will make more sense once you've read Influence. https://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/006124189X/ref=sr_1_3?ie=UTF8&qid=1525274472&sr=8-3&keywords=Influence https://www.amazon.com/Influence-Psychology-Persuasion-Rober... When you read these, keep in mind: Change is hard. Don't expect to read these and become good communicators quickly. It may take a few years of stumbling and practice. I see a mixture of comments agreeing and disagreeing with the original submission. For those who disagree: Most of what the author is saying is in agreement with what the books say: If your goal is to change someone, you will either fail, or will succeed at the cost of the relationship (and relationships at work do matter). Another important related point: If you cannot summarize why the other person is acting this way without using phrases like "stubborn", "irrational" or similar negatives, then it means you have no idea about the other person's concerns and motives, and are being lazy. It is easier to label, and much harder to probe effectively. Additionally, people often act stubborn because they realize you are not really interested in their perspective. Internally their thought process (which is very rational) is "This person does not really want to hear me out, so I'm not going to invoke too many neurons engaging with him and will just dig in my heels." - which is why a lot of books focus a lot on listening skills (which includes skills to signal that you are listening - you may in reality be listening just fine but the other person does not know it - so you signal it by summarizing their stance). A lot of the comments here are invoking false dichotomies. Since HN has a comment limit, I'll address some here: >I don't believe you can have a successful software team with individuals who can't take a code review well. This is tangential. You can give feedback in a code review poorly, or efficiently. Both ways allow for you to point out problems with the other's code. One way will not be taken well. The other way has a higher chance of being taken well. A big step forward is to realize you can have your cake and eat it too. >I started to try and reason with people with carefully crafted questions to guide them towards my goal. Leading questions is a bad idea (all the communications books say it). Learn how to state your concerns. It is OK to ask questions if genuinely curious. But if you want to point something out, learn how to state it in a non-defensive manner. (3 separate comments below): >If Kara's emotions and defensiveness can't handle a clearly articulated, rational, objective argument against design decisions, then for the sake of the product and the company, she probably needs to find another job. Avoiding discussions doesn't work for me. >Learned to let go and he has his parts of the code base and I have mine. >And this is how you end up with a terrible, in-cohesive product. Again, false dichotomies. The solution is not to be quiet and let it go. The solution is to learn how to talk about the issues effectively. One of the books calls this "The Fool's Choice" - thinking that either you have to be quiet and not air your concerns (to save relationships), or that you have to air them and damage the relationship. >It's either you convince them, or perhaps they convince you. Logic wins. Logic alone rarely wins. One key point in one of the books: Don't pretend that emotions should not be part of the decision making process. The reality is that emotions are already part of the decision making process. If you get angry that someone cannot take your feedback well, emotions are present. >It's safe to assume Kara wrote this article. It is safe to assume that the author of this comment is unwilling to question his views on the topic. That's what assumptions get you. >I have seen more technical damage done by nice and competent people deferring to bullies in the workplace than by legitimate disagreements expressed passionately. Another false dichotomy. What the submission describes is normal among non-bullies. >The flaw here is that you assume that "Kara" will learn from her mistakes. Not always the case. It is a similar flaw to assume that merely telling her what mistakes she made will make her learn from them. Definitely often not the case.

jlukic 8y ago

In situations with clear org structure the final decision between product disagreements can always be handled by the chain of command. When two product people disagree on a feature, the one higher up the org chart can then make the final call. Feelings are saved because roles are clearly defined, and those with greater product knowledge have the authority they need to "make the call", making the product better overall. For those stuck lower in the org chart, they can rest assured knowing the more good ideas they contribute, the quicker they will rise up the ranks in decision-making authority. When job mobility is also meritocratic and has efficient review processes, those middle managers should be correctly rewarded or punished for making good or bad calls. The problem arises for confrontation more frequently in startups because org-structure is often very loose. It's seen as "undemocratic" to force an issue because of seniority, even if someone may have more experience in a topic. Startups generally the traditional business hierarchy as being inefficient for decision making, because many institutions also fail to properly reward decision-making, or punish bad managers.

jbattle 8y ago
We've worked at different companies. I've seen the opposite. In smaller organizations there's more of a ... for lack of a better word ... team spirit. Conflicts rarely devolve to a zero-sum faceoff and people are more likely to be interested in the same goal (i.e. moving the product forward). The bigger the organization, the more muddy the waters. Cryptic territorial fights, all up and down the chain, become a shade coloring a great many decisions. Passing decisions up the chain of command doesn't really sidestep the issues in the article though - cause you still have to decide when to escalate something from "hey, what about this?" to "hey, you are wrong". If anything that's a more drastic step now that you are bringing an issue to An Authority Figure. I do agree that a lot of problems fester because of a lack of clarity about RACI-matrix. That can happen in any size organization, definitely worse in smaller ones.
- Bartweiss 8y ago
  > The bigger the organization, the more muddy the waters. Cryptic territorial fights, all up and down the chain, become a shade coloring a great many decisions. I heard a story recently of a fairly simple decision that put two territorial groups in conflict. It escalated to the person at the split between branches, who made the decision. Which is fine, except that the arguing parties didn't overlap one or two levels up. A question of "who wins over this one task at one site" landed on the desk of a senior VP overseeing dozens of sites after wasting the time of a half dozen managers who escalated it and fought with each other. At a conservative guess, it cost $2,000 in salary just to decide who would do the task. I think people undervalue how much benefit startups get just from having fewer disagreements that Need An Adult. Passing decisions down from the top is fine, but pushing conflicts up and back down is ridiculously expensive in time, money, and goodwill.

rhapsodic 8y ago

TL;DR: Let your coworker have their way.

godot 8y ago

I actually absolutely agree with everything in this article; but I did find it amusing that the article is titled "How To Get Your Coworker To Agree With You", and the answer is actually, "Don't." The three sections can be summarized into: 1) Stop the first reaction of trying to do it, 2) Check yourself also, 3) Let go. Again, I actually agree with the author, just thought this was amusing, and may not be what readers are expecting going into the article.

deagle50 8y ago
Agreed. Clickbait title with a promise of results.
- karmakaze 8y ago
  The original title doesn't seem like typical clickbait to me though. Literally, the title is inaccurate but does bring in the right audience. I clicked it wanting to solve this issue and was completely turned around by the article. Ultimately it dis resolve my issue with handling disagreements in a manner that would have taken me much longer to understand so clearly.
dang 8y ago
Ok, let's try replacing "How to" with "Don't". Or perhaps it should say "How to not"?
master-litty 8y ago
Beyond amusing, it's great writing. I see we've already changed the title but I wish we hadn't! I bet it's really persuasive for offenders. 1. Lull the reader into a false sense of security: This article is going to help you with a problem! 2. Really dig into it: Share a highly relevant story and connect with the reader's current frustration. Make it as clear as possible that the reader is understood. 3. Now that you have a shared foundation, introduce your argument. Discussions that start with the argument immediately don't stick as well to a lot of people. Give them a reason to listen.
- 8y ago

cbsmith 8y ago

I was really expecting a detailed story of kidnapping, water boarding, starvation...

kelvin0 8y ago

Zen of persuasion: don't try to convince others and they will respect you and your opinions. Simple yet quite elegant.

redwolf2 8y ago

My approach would be: 1. Talk to Kara, why she prefers her approach and not yours. Don't tell her that the icon is wrong. Ask her, if the icon could be changed to the other. Maybe she is right and you are wrong. She's the expert in this scenario, not you. If shes professional and her approach is wrong, she will see the mistake and adopt your idea. After that, let it pass and don't go out and tell everyone she was wrong. That's not very humble and fair. 2. If you really think you are right, be subborn. Stubborn people are more successfull then non-stubborn people if you look at statistics. That's why most subborn people are working in management. 3. Don't approach disputes based on a single formula. Be diplomatic, stubborn, helping and supportive. Fight the good fight. 4. Don't talk about the fight club.

master-litty 8y ago
>Stubborn people are more successful then non-stubborn people if you look at statistics. Success by what metric and which statistics?
- redwolf2 8y ago
  https://www.independent.co.uk/news/science/why-stubborn-children-are-more-likely-to-become-successful-a6864966.html https://www.independent.co.uk/news/science/why-stubborn-chil... https://my.apa.org/apa/idm/login.seam?ERIGHTS_TARGET=http%3A%2F%2Fpsycnet.apa.org%2F%3F%26fa%3Dmain.doiLanding%26doi%3D10.1037%2Fdev0000025 https://my.apa.org/apa/idm/login.seam?ERIGHTS_TARGET=http%3A...

ams6110 8y ago

Thought immediately about posting a rant on the obsessive use of "they/their" in a singular context. Pick a pronoun for Kara and use it. Whether he is a she or she is a he, Kara is not a "they" But then I thought, nah. I'll just read something else.

BSVino 8y ago
Hello, author of the article here. Kara is a "they". Many people use "they/their" as their singular pronoun. My coworker was one such person. :)
timtas 8y ago
"Their resentment may even cause them to push for keeping the icon after it has proven not to be the right thing for your product." Either Kara is more than one person, or this is a grammatical error. It may be an intentional grammatical error but an error nonetheless.
zerocrates 8y ago
That's a pretty petty reason. Also, you're only going to see usage of the singular "they" increase, so you'll be skipping a fair amount of content with that policy. Especially in the workplace context, assignment of a particular gender for an example like this is often an issue. Many people (myself included) take the reasonable opinion that "they" is preferable to "he or she," if only on aesthetic grounds.
- dragonwriter 8y ago
  Singular “they” is a different issue than singular l specific “they”, which is what is used in the article; singular ”they” is a very long established usage, but “they” for a specific named person (even if a hypothetical one) is about as well accepted as “it” for that use. > Many people (myself included) take the reasonable opinion that "they" is preferable to "he or she," if only on aesthetic grounds. “he or she" and similar constructs are also not generally accepted for specific named individuals.
  - 8y ago

lambdasquirrel 8y ago

There's some caveats to all this. The most obvious is that you're right and Kara's wrong. The problem in creative orgs is that it's often hard to tell you apart from Kara. Learning and unlearning are important abilities in a creative setting. Otherwise, it wouldn't be a creative setting. How many of us (in ops) have had to argue with coworkers about the usefulness of configuration management (back when that was becoming the best way to do things), and who now have to talk with coworkers about the need to containerize our build and deployment? So, what might've been wrong (or right) at some point in history, may not be wrong (or right) now. And yes, as others have pointed out, there is usually a lot of technical debt at stake. In UI/UX settings, agreeing with your coworkers (as someone who's done design, talking about engineers), it usually means that you end up with a real stinking pile of a UX, where the designer gets overruled every time unless product intervenes. There's just more engineers than there are designers, and all of the engineers are living in the same bubble. That leads into the other caveat. This strategy works okay when you are in an org with enough clearheaded people (who have the power). With a critical mass of clearheaded people, you can carry forth and the cumulative effect of things going wrong doesn't overwhelm the org's ability to repair them. Are there meta-abilities involved with creativity? I know for my own individual flow, it was important to recognize when I was stuck, and to take a walk. Creative people are often very stubborn, and, maybe this works well in a traditional, management context, but, I'm pretty sure this works against us in our creative bread-and-butter. And, I'm not sure there really is a general way to teach creative ability (whatever that is) that works for everyone, including this fictitious Kara.

opportune 8y ago
I think the main point is that it's not about being right. You need to pick the right battles to fight, it's not worth ruining workplace relationships when people dig in their heels over a disagreement about something relatively small

PurpleBoxDragon 8y ago

>The only person who you're responsible for is you. Kara may or may not be making a mistake with the icon, but you're not responsible for it. What happens when the issue is security related? Personally I find myself in a situation where I feel like I'm wasting political capital and hurting myself trying to advocate for security. Is the solution to just... not?

BSVino 8y ago
Hi, author of the article here. Security can be a pretty significant cost to the business and if your teammates aren't concerned about it then that's a red flag that maybe you're in the wrong place. But for the time being, yes, consider not. First, consider whether security on your team is a concern at all, for example you're working on an internal tool and you can trust your teammates not to go looking for buffer overflows. Otherwise, the question I have is, why is there no process for dealing with security flaws? Whose responsibility is it to set up that process? Send your discovered flaw to that person and suggest that they set up such a process so that you can submit any future flaws, and then your obligation to the customer is done. If you burn your relationship with your teammates, you give up any chance of influencing them to improve their security practices in the future.

pier25 8y ago

1) If you are responsible for someone else's work and will be blamed for the mistakes of that person you should be able to ask them to change something without any drama. Designers and developers are very prone to drama regarding their work. I've seen this again and again. They become attached to what they've done and can't be objective about it. 2) If you are not responsible for that person's work then, yes, by all means express your opinion in a respectful way and see what happens down the road.

discussedbefore 8y ago

Be likeable or get fired https://news.ycombinator.com/item?id=16883882 https://news.ycombinator.com/item?id=16883882