
Don't Get Your Coworker to Agree with You - BSVino
https://www.workaguide.com/blog/2018/5/1/how-to-get-your-coworker-to-agree-with-you
======
godot
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.

~~~
master-litty
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.

~~~
BSVino
Hello, article author here. I admit that the title is a bit clickbaity, but I
paid careful attention while writing to make sure that the title is 100%
correct. At the end of the process your coworker will agree with you -- only
it may be because you changed your mind, rather than your coworker.

You're basically spot on with my strategy in writing the article. I stole it
from Extreme Ownership, an excellent book that uses a similar tactic. The
authors begin each chapter telling a story wherein they made a serious
mistake, but leads the reader through their logic in making the mistake such
that the reader is thoroughly convinced that the mistake was the right thing
to do. Then they reveal the mistake and boom! The reader learns. I found it to
be a very effective way of teaching soft skills so I emulated it here.

I don't want to trick anyone into reading an article that doesn't have any
value to them so if folks feel that the title was inaccurate I'm totally OK
with the thread title being changed. But I would point out that it means a
totally different thing now that no longer reflects what's in my article. :)

~~~
master-litty
Thanks for sharing the thought process and for crediting the book, ordering it
now :)

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

~~~
BSVino
Hello there! Author of the article here. I love the point you've made. Often
there are long term costs in e.g. technical debt.

I assumed in this article that the stakes are low (and they are more often
than we think) but I have a future article in mind about how to make team
decisions when the stakes are high, and it'll be something along the lines of:
Have a strong process, and make it the responsibility of one person to follow
the process, which should involve gathering information and driving the
consensus of the team on that issue. Give that responsibility to someone
already established to have good people skills e.g. a lead. What would be your
approach?

~~~
matmann2001
Hello! It's wonderful that you're joining us here today. I found your article
insightful as I'm dealing with a very similar situation at work. I was
wondering if I could ask for some further advice. Here's my story:

I'm currently working on a multi-faceted project, where I have essentially
become responsible for all things UI related. This is fine, considering UI/UX
was a decent part of my educational background and I have experience from
doing UI design on pretty much every team I've ever been a part of. However,
what I'm struggling with is constantly being overruled by higher-ranking team
members.

I feel like I'm just being dictated to, even for the most minute details. I've
tried the "just give them what they want, preserve the relationship" route,
but that has just led to a compounding of bad UX. I've tried backing up my
decisions/ideas with appeals to textbook UI/UX principles, but that has led to
the same polarized arguments you've described in your article.

I have no problem with appealing to rank when a decision is difficult to make.
But the issue I have is, when someone pulls rank, they don't bother to explain
the reasoning behind their decision. When I try to ask questions to better
understand, responses basically boil down to "I just think it looks better
this way".

I don't feel respected, despite the extensive background (more than the others
when it comes to UI/UX, actually) that I bring to the table, and despite the
fact that I'm the only one working on this part of the codebase day-in and
day-out. I feel like the ideals of meritocracy are not being honored, and
decisions are being made by rank before reason. No one seems open to
discussion and understanding. And I'm basically being treated like a junior
dev when I'm actually a senior-level engineer.

What should I do?

~~~
sizzle
Test your design vs their design with 5 people [1] and share the results with
the team. If the results are in your favor, you've effectively elevated the
design decision from this sole person to the greater team at large and are
then presenting objective data that anyone in opposition of your design would
have to publicly admit to colleagues that their reasoning is arbitrary and not
grounded in reality.

As a UX champion on your team, you must bring the user's voice to the table
and that data will make it easier for people pulling rank to agree with you in
my experience, cause they'll never take the time to test designs as they
wouldn't have the skillset for UX research whereas you do (or are learning
it). Cheers.

1\. [https://www.nngroup.com/articles/why-you-only-need-to-
test-w...](https://www.nngroup.com/articles/why-you-only-need-to-test-
with-5-users/)

~~~
lostcolony
They ignored published best practices (per OP), why do you think they won't
also ignore data? "Admit to colleagues" assumes you roped in other managers,
do you really think an individual contributor is going to win the political
game at that level? Because I've seen what happens at that time; all the other
managers nod their heads politely, and then behind closed doors tell the one
you were butting head with "You have to reign in your people". All you end up
doing is undercutting your entire team's authority, you don't elevate your own
above your manager's.

~~~
sizzle
That's a company that isn't going to survive and I'd probably jump ship if
they were leaving the product's success to chance and on the whim product
decision making. They are in for a rude awakening when competitors leverage
full time UX professionals that so the user research to maintain competitive
advantage. I agree you shouldn't be brazenly shaming superiors but take a step
back and make the data speak for itself.

------
dalore
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
> What could one have done instead?

Got rid of the co-worker much earlier on, by the sounds of it.

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

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

~~~
BeetleB
I've read a bunch of negotiation books as well as conversation books. What the
latter heavily emphasized is:

 _Do not ask leading questions_

What you describe is textbook behavior. People usually will know when you are
doing it, and will get defensive. Especially the smarter ones. I look back in
all my years and understand a lot of people's reaction to me: Some people have
literally shouted at me when adopted the Socratic approach. The rest don't
shout, but they do get defensive. The better among them will ask why I'm
probing. But the majority will either answer (but internally think negative of
me and damage the relationship), or will get nasty.

That's not to say you can't ask questions. The key is to ask genuinely curious
questions (the opposite of leading questions). If you have a concern, learn
how to state the concern in a non-threatening manner. Don't try to lead people
to it.

The other thing they all say, which the submission has: "If your goal is to
change someone (be it internally or externally), the chances of having a poor
conversation are high."

~~~
citrablue
A strategy for this is outlined in the (great, IMO) book "Never Split the
Difference": treat the interaction as a negotiation, and adopt a EQ-first
approach. The book has some good phrasing hacks and other subtle messaging
techniques designed to place both people on the same team, solving a common
challenge.

Yes, it can be exhausting if you do this in every interaction. But I've been
picking 1 interaction per day and implementing those techniques to significant
success.

[edit] Relevant article from the author's site:
[http://blog.blackswanltd.com/the-edge/the-key-to-
disarming-t...](http://blog.blackswanltd.com/the-edge/the-key-to-disarming-
the-attack)

~~~
BeetleB
I was debating if I should mention the book, and was worried someone else
would.

Of all the negotiation books I've read, it is the best book at explaining the
psychological aspects of negotiation. However, the tone and ego of the author
is incredibly off putting - especially his continual bashing of the other well
known books that are used in MBA curricula. He often makes claims about those
books that aren't true and ridicules them (the straws are thick in the book).
And then over 80% of what he does advocate is also in those books he
criticizes. I usually don't mention the book because I worry that people will
read it and have a biased view against all the other good books out there.

As for his "phrasing hacks" \- some are great, some less so. I think this is a
product of his background - he was an FBI negotiator and most of his
negotiations are one-off. He is not going to interact with his counterparts
once the negotiation is complete, so he is not aware of the long term
consequences. Finding clever ways of asking "How can I do that?" works in the
short run, but will often damage relations in the long run - people do wisen
up to it. These days I have to deal with someone who keeps asking what the
author would call "calibrated questions", like "Yes, but how will I know X?".
I'm at the point where I just respond with "Yes that's a good question. How
_will_ you know X?". And likewise to all the other questions.

Some of the calibrated questions are really effective. Others are not. I
suspect because most of his interactions are one-off, he cannot distinguish.

One of the books I read (Bargaining For Advantage) formalizes this a little:
You have two axes and 4 quadrants. One axis is: How much you care about the
outcome. The other is: How important is the relationship to you?

The toughest is when both are important. The quadrant where you care about the
outcome but not the relationship is easier, but can be challenging too
(examples are divorce and negotiating the price in a market). When the
relationship is important but the outcome isn't, the advice is to focus on
making the other person happy - this can also be the perspective of an
employer who wants to hire a good candidate - if the candidate asked for an
average salary or less, give him an above average salary. For the final
quadrant where neither is important, society usually has protocols that people
just follow so that time isn't wasted on negotiating trivialities.

But I agree - there is good stuff in the book. And of all the ones I've read,
it is the most "down-to-earth" in terms of putting what you learn into
practice.

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

~~~
lostcolony
And the best part was the person making the decision was completely non-
technical, and unaware of the actual considerations. Their decision was likely
based on as much valid insight as a coin flip. Had a coin flip been agreed
upon earlier, not only would the results likely have been the same, but morale
would have been better, and costs would have been lowered.

Not necessarily advocating for a coin flip approach, just, you know your
company is unhealthy when decisions can be made equally well if not better via
random chance as by allowing your process to handle them.

~~~
Bartweiss
Hah, this was actually my thought when I first heard it.

Anywhere in that entire chain, two equal-power managers could have said "this
really isn't a big deal, I'll flip you for it". It would have saved time and
money, and probably produced less resentment than the 'intelligent' decision.

We already know the average stock picker is at 'random chance' levels of
quality - I wonder how many other parts of corporate life could be replaced
with a dartboard?

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

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

------
redwolf2
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
>Stubborn people are more successful then non-stubborn people if you look at
statistics.

Success by what metric and which statistics?

~~~
redwolf2
[https://www.independent.co.uk/news/science/why-stubborn-
chil...](https://www.independent.co.uk/news/science/why-stubborn-children-are-
more-likely-to-become-successful-a6864966.html)

[https://my.apa.org/apa/idm/login.seam?ERIGHTS_TARGET=http%3A...](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)

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

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

~~~
thekingofh
The takeaway from this is that management defines reality. Opinions and
objectivity goes out the door if management doesn't like the decision. This is
why a clear chain of command is vital. Humans need it to function in groups if
the group is to stay together as one unit.

~~~
jschwartzi
No, management does not define reality. Validation and verification define
reality. In a rational engineering organization, you and Kara would agree to
test her change and see how well it works instead of having an argument from
first principles.

------
postalrat
It's safe to assume Kara wrote this article.

~~~
_zachs
I feel like this is the only comment that needs to be here.

------
toopok4k3
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
Agreed. This must be written by someone out on the west coast.

~~~
dang
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)

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

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

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

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

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

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

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

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

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

~~~
zerocrates
For a _hypothetical_ person? I don't buy the distinction (ignoring the small
aside where the author says Kara was "a real person).

I sincerely doubt that the poster I replied to would be fine with the article
if all instances of "Kara" were simply replaced by "[your/my/a] coworker."

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

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

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

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

------
BeetleB
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-
Lif...](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)

Crucial Conversations:

[https://www.amazon.com/Crucial-Conversations-Talking-
Stakes-...](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)

Difficult Conversations:

[https://www.amazon.com/Difficult-Conversations-Discuss-
What-...](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)

Negotiation books:

Bargaining For Advantage:

[https://www.amazon.com/Bargaining-Advantage-Negotiation-
Stra...](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)

Getting To Yes:

[https://www.amazon.com/Getting-Yes-Negotiating-Agreement-
Wit...](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)

Getting Past No (billed as a negotiations book, but really more of a
conversations book):

[https://www.amazon.com/Getting-Past-Negotiating-Difficult-
Si...](https://www.amazon.com/Getting-Past-Negotiating-Difficult-
Situations/dp/0553371312)

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-
Rober...](https://www.amazon.com/Influence-Psychology-Persuasion-Robert-
Cialdini/dp/006124189X/ref=sr_1_3?ie=UTF8&qid=1525274472&sr=8-3&keywords=Influence)

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.

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

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

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

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

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

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

------
discussedbefore
Be likeable or get fired

[https://news.ycombinator.com/item?id=16883882](https://news.ycombinator.com/item?id=16883882)

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

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

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

~~~
chaosite
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
“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
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.

~~~
leibnizwasright
I have the understanding from experience that people will always give a reason
for doing something that I could not imagine.

So 1st, make questions, understand what is the objective with that code you
see on screen. 2nd, make more questions too see if other use cases were
considered.

3rd, there are best practices, literature that provide a common way of
working, discuss how to apply this.

There are no ways of understanding without making questions.

On this specific case, besides the lack of OO design knowledge, there were
also a misunderstand on the page object pattern , how web apps are build and
what is the web app and what is part of the browser.

And this is why I also talk with my team on my ideas to develop something
before or while developing it. It should not be a surprise, no matter how nice
and commented the code is.

------
rhapsodic
TL;DR: Let your coworker have their way.

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

