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.
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.
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. :)
The original title doesn't seem like typical clickbait to me though. Literally, the title is inaccurate but does bring in the right audience. I clicked it wanting to solve this issue and was completely turned around by the article.
Ultimately it dis resolve my issue with handling disagreements in a manner that would have taken me much longer to understand so clearly.
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.
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?
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.
I was in your shoes at my last job. I tried many techniques for over 2 years, but eventually I had to resign because nothing was going to change no matter what I did.
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...
First, talk to HR and their boss. Explain that you are confused about roles; is their role to dictate these decisions? Get clarity on that; is your position expected to be the knowledge asset, or are you just a 'doer', as it were, someone to take orders. If the former, explain that that is not being adhered to, and maintain a dialog with the people you talk to to help get it fixed (HR can work with your boss' boss better define your and your boss' role, to coach them, etc, and possibly, if necessary, reassign your boss or you to a different team, if possible, or let your boss go...or, technically, let you go, though you will almost certainly get an inkling that they do not want to be helpful before you push things to the point they'd feel that step was necessary).
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.
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.
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.
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.
Hey there! Sorry you're having to deal with this. There's not necessarily one solution or any silver bullet, but there are many things you can try.
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.
Hey! Thanks for your article, and thanks for joining the discussion. I think a follow-up article would be great. :)
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've heard technical debt (abstractly) as a reason for a lot of these arguments. IE, we can't step back from this argument because the code is important, it will cause all these problems down the road.
But of if course two people disagree on which path is actually correct and which produces more technical debt, what then?
i'm a pretty mild mannered personality, very reluctant to get angry with other people. i try to be diplomatic with people, at least, in person.
one of my worst experiences working on a dev team was checking in code that broke the build. the alpha came into my office and got quite angry with me. it left new emotional wounds and reopened old wounds. it didn't help me become a better programmer, just more fearful and stressed. i've reflected many times on how that message could have been conveyed better.
multiple years later, a manager i was working for decided he needed to start writing code and he checked in something that broke the build i was working on. of course, now that the shoe was on the other foot, what do you think i did? i reacted angrily! (lucky for me, he's a good guy with a lot of class and didn't just fire me on the spot. he didn't even react in a negative way.)
the lesson i learned is that i need to become classier. still working on that ...
I hope this doesn't come off as snarky, but you and your team may find many benefits from making infrastructure changes that prevent anyone from breaking the build. One way we do this is to have CI run for all pull requests, and prevent merges if there are any test failures, and the other is that we have a staging site where we run even more tests to ensure mistakes don't go to production (very often).
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.
Hey, what happened to "move fast and break things?". Put that poster on your wall, it will work wonders.
In all seriousness though, writing code (and especially production deployments) can sometimes be stressful. Smart people do stupid things sometimes, or some random event occurs, and makes them look that way... after a while, you learn to separate your persona from your work product.
One other thing you start to value after a while, is directness. While sugarcoating things sometimes makes people feel better, most effective teams are good at delivering facts, or if it's an opinion - making a logical case to support it.
As far as comments on a checkin go. The main thing I find is that the way to phrase things is very important.
Whatever you do, write any of your thoughts as suggestions instead of tasks to be completed. If you have a decent coworker, they'll know when something is really a problem, and when something is actually up for discussion.
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.
There's a lot in here that might boil down to how you asked the questions/gave the feedback, but there are also certainly cases where you just aren't getting through to someone.
Something I often do there is sanity check my approach with my manager and some trusted coworkers. Did you talk to anyone else about where the two of your coworkers communication was breaking down? Sometimes others have additional perspective on why you aren't getting through to someone since they have a different vantage point.
I've also had cases where my manager basically tells me "no, I don't think you're doing anything wrong, let me do some investigation myself" - and if other people have had the same experience as me, that's occasionally led to positive organizational changes such as shifting people around onto different projects where their skills fit better.
Hello there, author of the article here. You bring up a great point: This is a case in which the stakes are high and some things I said in the article don't apply.
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.
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.
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.
> How is Kara being offended a smart and socially conscious decision?
That's not what the article is saying. The article is not saying that Kara being offended is smart and socially conscious. The article does not judge whether being offended here is smart or stupid or whatever.
What the article is saying is that it is smart and socially conscious to be aware of the fact that Kara is likely going to be offended. It is certainly true that awareness of others' likely reactions is smart and socially conscious.
The rest of your comment is pretty much a restatement of the conclusion of the article :)
> I never understood this logic. How is Kara being offended a smart and socially conscious decision?
Because Kara is a human, and humans are weird, emotional creatures. Our primary instinct is to scan any interaction for signs of attack. Thus, your recommendation to build trust is the right one, with trust Kara's prime instinct isn't that you're a potential attacker (and that's the main value of having high trust in teams in general - they are more efficient because they have less friction in communications). But empathy is also important: Kara didn't select the icon because she's a moron, bent on anti-social behaviour. Saying "the icon is wrong" can be understood to imply that, and that implication is, indeed, an attack.
Your experience in trying to reason with people might (I obviously don't know you) stem from some measure of lack of empathy - do you enter those interactions with a belief that you're right and the other person is wrong? Try entering them in the spirit of assuming that the other person made the choice they did in good faith, but perhaps did not have all the information you do, then listen, and remember that perhaps you don't have all the information they have, either.
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."
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.
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.
On the other end of the stick from the other explanations here, I've worked in at least one team where there were no Karas. Our boss would come up to us and say "this is totally wrong", and we would discuss it without missing a beat.
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.
I once had a UX designer who was tasked with creating, or picking (with appropriate license) an icon to represent the volume of traffic on a keyword on the Twitter firehose.
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).
You can't affect her being offended. All you can do is respond to it. Yes, maybe Kara should be less defensive, but that's not something you have control over; and trying to argue your way into convincing someone to not be offended is only going to make things worse
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.
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.
> 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.
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.
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?
That's not really responsive to the point of the article though. The goal isn't actually to "arrive at a decision". Any manager can do that. A military-style chain of command with autocratic power exerted feudally at each level is like the simplest possible form of organization.
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 still think when handled correctly seniority is the best incentive to reward correct decision making. The problem arises in the (quite frequent) circumstance where people who get to positions of power aren’t there because they have the best guidance / deepest expertise. This is an issue with implementation, not a fault of heirarchy.
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.
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.
> 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.
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.
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.
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.
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.
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.
It's a two way street. Improving one's listening skills and not reacting emotionally is just as important. The general tone of the article sounds to me as if it does not give much priority to the latter. This strikes me as an expression of an over protective approach to people's emotions that limits rational discussion. I see this often and in my experience I find that it has negative effects on organizations and relationships and, in cases like the one in the article, quality and business success.
Sure but you can’t change anyone except yourself. Pressing on Kara and telling her to stop being defensive probably doesn’t accomplish anything except destroying that relationship and making yourself look like the office bully.
Kara’s manager can encourage her to work on this, but colleagues cannot realistically. And even the manager’s ability here is extremely limited.
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!
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.
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)?
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.
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
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.
I have seen more technical damage done by nice and competent people deferring to bullies in the workplace than by legitimate disagreements expressed passionately.
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
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.
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.
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.
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.
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."
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.
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.
>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?
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.
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.
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? :-)
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.
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.
Hehe, or, they will will get replaced as soon as they learn enough to find a better paying position.
It’s really a triple choice: 1. Shirtfront the stupidity
2. Build the relationship
3. Avoid the whole thing and work with people who are on the same wavelength
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.
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.
Hello, author of the article here. You're right, I did miss that important point, thanks for pointing it out. I've made some minor updates to the article to account for it. Thanks!
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.
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.
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.
The problem with Socratic questioning is that it assumes a teacher-student type of relationship, or at least a superior-subordinate one.
If that's not the case, and once someone recognizes what it is that you're doing, they may become rightly offended at the arrogance you're displaying by choosing the teacher role for yourself.
“Socratic questioning” implies only a collegial relationship. If you cannot walk over to a colleague and ask them questions about their work without them getting offended, your office politics are extremely unhealthy.
Or else you are probably wearing an expression of disapproval when you ask them these questions. If you go in with an honest “I want to learn and understand” stance, normal people will generally be happy to answer.
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.
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.
You can go into a session like this with your mind made up and still legitimately ask these questions. This questioning should hopefully show the other party why they are wrong or show you why they are correct. Either is a great outcome and the questions are the same either way.
I think that 1st we have to understand that to solve this, every solution is slow.
1st I send some links on OO designs and SOLID principles.
2nd I made a few comments on the code review that tacked more real problem like maintenance, change of URL since we were still in development phase and other pages and dialogs that do not have a URL and how this mixed with the rest that have.
3rd was to have design discussion pior development - which we did not have.
For last, some hours during week with the whole team to talk on design and coding, in order to have evryone on a similar level of knowledge.
This is so spot on it hurts. At my last job, everyone was going about building things completely wrong, and to them it was completely normal! I found it very difficult to work with them because they didn't view me as their superior, so they weren't receptive to me teaching them anything, and whenever I would suggest an idea on a design, they wouldn't have any opinions because they didn't know any better.
They would often times ask me to explain why it should be done one way or another, and have me to it in a 30 minute meeting. In reality, it would take us reading a few volumes of computer science text books before they had enough knowledge to understand where I'm even coming from.
The article describes a situation where your co-worker is potentially doing something unproductive, and how you can get them to change.
The situation where your own boss is making a mistake, and you yourself have to carry out their instructions is much trickier, as you might find yourself being blamed for the inevitable poor outcome.
