Don't Get Your Coworker to Agree with You
workaguide.com
workaguide.com
Ultimately it dis resolve my issue with handling disagreements in a manner that would have taken me much longer to understand so clearly.
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.
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. :)
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.
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 ...
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.
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.
The interesting thing is that we programmers still make just as many mistakes -- but there are no angry feelings or animosity when they do because it doesn't hurt anyone else. If I make a pull request that fails linting, or breaks a bunch of tests that I forgot about, it won't affect my teammates, won't get to production, et cetera. It transitions the interaction from "You broke my stuff!" (which causes hurt feelings) to a robot (callously? uncaringly?) informing me that I have more work to do before my stuff is of a caliber that merits merging with the rest of the codebase. Somehow, that doesn't hurt feelings nearly as much.
This also requires the codebase to have extensive enough test coverage that you can trust the tests to catch any breakage -- which requires code review to notice if one forgets to add a test for functionality. The upside is, having that kind of coverage means that you can refactor fearlessly, and can really trust an automated deployment workflow.
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?
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?
Actually don't, it will be counter-productive. But it would be nice if they saw it somehow.
If that does not help, and your role is, de facto or de jure, a brainless 'doer' role, where you're expected to be responsible but not empowered, find a new job.
Seriously.
My wife is in a similar situation. When people make no pretense about the fact that their decisions are based solely out of arrogance (to borrow language from the OP), and their role allows them to do it, and the company sees no problem with allowing a non-knowledgeable resource to make decisions that trump a knowledgeable one, there is no way to fix it from below.
I was constantly being dictated to or ignored as if I was a Jr. Dev, even though I had by far the most experience on the team. I'm sure I am not the best at handling the nuances of interpersonal communication, so I'm sure I'm somewhat to blame. That being said, what can I do when someone argues against me about something they are truly incorrect about? Just let them carry on and do the wrong thing and further sink our codebase into oblivion? I guess so...
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...
The biggest thing I can suggest is to raise your level of thinking from UX to the business metrics. By this I mean, rather than trying to optimize your product for "best UX", try to optimize it for "delivering most value to the customer." Creative people don't like to admit it, but sometimes the creatively optimal thing (good UX/good design/etc) doesn't always imply moving the needle of the business metrics. If you don't believe me, look at how much Amazon sells with their terrible UX. Ultimately the only thing that matters in a business is delivering value to the customer, and if the bad UX doesn't get in the way of that then you can sleep well knowing that your lead's bad UX decision didn't hurt anything.
I've found that thinking in these terms allows me to separate myself and let go of concerns like these. If the poor UX decisions of your manager are having a business impact then you can go find that data and put a dollar amount on it. For example, "I did some A/B tests and we got a 12% lower clickthrough rate with the button there." Your manager may not agree, but at least now you're talking about the customer, not about UX. If you can't produce that data then you still win because the business is unaffected by this mistake and you get to make your lead happy by doing it their way. Winning trust by doing bad UX is still winning trust.
Here's an example-by-story: I was once an engineer tasked with building an automated testing system. Automated tests are easy to understand and so everybody has opinions about how they should work. And so my system's design quickly got bogged down with folks giving the same sort of "i like it better that way" arguments that your lead is giving you. So, rather than engage with any of them, I picked a single battle in the design of my system, something that nobody could argue against, namely that tests should actually be test descriptions, so that the test system can work with declarative data and make decisions about the tests more easily. I showed how that would have a measurable impact on the business (having the test descriptions gives the test system flexibility so we can e.g. filter tests on the fly so that at desk testing times can be kept to a minimum, or easily move tests between BVT and Smoke, or whatever) which sidestepped all of those arguments.
If that doesn't float your boat, I like lostcolony's approach. One possible route of addressing it is to go through the hierarchy. As they mention it can be a tricky approach, you should avoid saying anything negative about your leads or explicitly asking anyone to change their behavior.
You could also try just having an earnest conversation with this person, expressing to them how their behavior makes you feel, and asking them what you should do to gain their trust and the ability to work autonomously. Try to make the conversation not about their behavior, but rather about what actions you can take. "What can I do to take more of these responsibilities on myself?" Then if you hold up your side of the deal, they're more likely to be accommodate you.
It may not be what want to hear, but getting someone else to change their behavior is one of the hardest things you may ever have to do in life and is often impossible. You might have to deal with the fact that this person will always do this. As lostcolony says, you can quit, but I see this as a last resort. You're just going to run into the same problems elsewhere, and it benefits you to learn to deal with the problems where you are.
Good luck!
Jorge
Edit: Looks like sizzle said exactly what I ended up saying but much shorter. And lostcolony's reply to sizzle brings up a good point: You have to present your case delicately, be careful not to make this person look bad, and if they don't respond to hard customer data, maybe it's time to find a team that does.
I'm not sure how much my perspective can be applied to design-related decisions, since I'm a developer. But here are some of the approaches I use as a developer that you may be able to translate into a design domain;
1) Related to your suggestion about having a strong process, I recommend that teams adopt popular coding standards, and then automate the checking of those standards. That way, the nitpicky stuff is the responsibility of zero people, and everyone, at the same time. That helps avoid arguments over inconsequential stuff. Essentially have good, automated QA checking that everyone has agreed to adhere to. In design, that may mean having a dedicated person who enforces things like branding guidelines or solid design principles, I'm not really sure.
2) Related to your suggestion of gathering information and getting the consensus of a team, I'd personally frame it as "clearly defining the problem". But it might be helpful to have a universally respected team lead or design director who is responsible for directing the process of defining the problem. You need some way to unite the team around a single understanding of a problem. It looks like you're pretty much on this track already.
3) Everyone should take the role of both reviewer and reviewee. There should be a formalized review process and everyone should take turns being on both sides. It's important that everyone on the team understands that reviews are not personal criticism of someone's work but working together to help find the best solution to a problem.
4) Reviewers should learn to deliver feedback in a way that is encouraging and considerate. Be kind. Point out the good, as well as the bad. Ask questions instead of making corrections. Remember to encourage and thank people. One condescending comment in a review can take months to recover from.
5) Reviewees should learn to take feedback as an opportunity to learn, grow, and find better solutions. Feedback should never be taken as personal criticism, even if it was written that way. And reviewees should strive to be open to new ideas and to challenging their own.
I hope those ideas help. Thanks for your comment!
But of if course two people disagree on which path is actually correct and which produces more technical debt, what then?
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.
Got rid of the co-worker much earlier on, by the sounds of it.
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.
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.
In this case I would suggest that there should have been a lead or senior overseeing your coworker who was responsible for the quality of their code. This person should have already demonstrated good judgment in code quality, should have some people skill and backbone in dealing with folks who take code reviews personally and have the authority of the team to make the final decision on whether code gets integrated into your mainline branch.
If you're not that person then there's not much that you can do about a coworker's bad code other than push the team towards a stronger structure and process to protect it from bad code.
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.
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.
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 :)
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."
i would like to read some good books on negotiation and conversation. do you have any advice on what the best books that you read on the topics were?
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...
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.
I think there are benefits to being forthright, but you absolutely have to make sure there aren't any Karas first. And be ready to take the article's suggestions to heart if there are, without grumbling.
They picked some traffic lights. Keep in mind, the icon represented the amount of traffic, not whether traffic is stopped, started, or pending change. The icon would have been poor for that task too, since it was in two colors.
The UX designer required explanation as to why their traffic icon wasn't sufficient. Later, the company folded, amongst the other reasons given were that they should have fired the Kara way earlier than they did (for many reasons, including lack of competance and not being able to handle feedback).
Well, it did say you are a smart and socially conscious human being, it didn't say anything about your co-worker.
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.
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.
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.
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.
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?
The point is to avoid getting to a situation where a manager needs to step in and make that call in the first place, because despite its simplicity autocratic control (especially in creative fields!) is a pretty craptastic way to run a company.
Your point that "feelings are saved because roles are clearly defined" just doesn't work in practice. And anyone who's ever been overruled by a boss can tell you that.
I think I’m the domain of the article, design, the guy who is creative director / dept head generally is a good candidate for arbitrating a design or product dispute in companies that promote leaders effectively.
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.
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.
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.
Success by what metric and which statistics?
Kara’s manager can encourage her to work on this, but colleagues cannot realistically. And even the manager’s ability here is extremely limited.
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.
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!
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.
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)?
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.
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.
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
It's either you convince them, or perhaps they convince you.
Logic wins.
But then I thought, nah. I'll just read something else.
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.
> 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.
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."
Either Kara is more than one person, or this is a grammatical error. It may be an intentional grammatical error but an error nonetheless.
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.
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.
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?
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.
I suggest folks read some good books on conversations and negotiations.
Conversations:
Nonviolent Communications:
https://www.amazon.com/Nonviolent-Communication-Language-Lif...
Crucial Conversations:
https://www.amazon.com/Crucial-Conversations-Talking-Stakes-...
Difficult Conversations:
https://www.amazon.com/Difficult-Conversations-Discuss-What-...
Negotiation books:
Bargaining For Advantage:
https://www.amazon.com/Bargaining-Advantage-Negotiation-Stra...
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-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-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.
Otherwise, nice article. Appreciated.
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.
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.
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.
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.
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.
What do you do in this situation?
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.
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.
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.
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.
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.
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.