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.
Don't Get Your Coworker to Agree with You
61–70 of 112 posts
Re: Don't Get Your Coworker to Agree with You
#62This 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…
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 pers…
Hello! It's wonderful that you're joining us here today. I found your article insightful as I'm dealing with a very similar situation at work. I was wondering if I could ask for some further advice. Here's my story:
I'm currently working on a multi-faceted project, where I have essentially become responsible for all things UI related. This is fine, considering UI/UX was a decent part of my educational background and I have experience from doing UI design on pretty much every team I've ever been a part of. However, what I'm struggling with is constantly being overruled by higher-ranking team members.
I feel like I'm just being dictated to, even for the most minute details. I've tried the "just give them what they want, preserve the relationship" route, but that has just led to a compounding of bad UX. I've tried backing up my decisions/ideas with appeals to textbook UI/UX principles, but that has led to the same polarized arguments you've described in your article.
I have no problem with appealing to rank when a decision is difficult to make. But the issue I have is, when someone pulls rank, they don't bother to explain the reasoning behind their decision. When I try to ask questions to better understand, responses basically boil down to "I just think it looks better this way".
I don't feel respected, despite the extensive background (more than the others when it comes to UI/UX, actually) that I bring to the table, and despite the fact that I'm the only one working on this part of the codebase day-in and day-out. I feel like the ideals of meritocracy are not being honored, and decisions are being made by rank before reason. No one seems open to discussion and understanding. And I'm basically being treated like a junior dev when I'm actually a senior-level engineer.
What should I do?
Re: Don't Get Your Coworker to Agree with You
#63Earlier quoted context omitted.
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 arti…
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.
Re: Don't Get Your Coworker to Agree with You
#64In 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 overal…
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…
> 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.
Re: Don't Get Your Coworker to Agree with You
#65This 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…
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 pers…
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 hope those ideas help. Thanks for your comment!
Re: Don't Get Your Coworker to Agree with You
#66Earlier quoted context omitted.
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 pers…
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…
Try forwarding the article.
Actually don't, it will be counter-productive. But it would be nice if they saw it somehow.
Re: Don't Get Your Coworker to Agree with You
#67This 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…
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 pers…
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?
Re: Don't Get Your Coworker to Agree with You
#68I was really expecting a detailed story of kidnapping, water boarding, starvation...
Re: Don't Get Your Coworker to Agree with You
#69I 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 reader…
Agreed. Clickbait title with a promise of results.
Re: Don't Get Your Coworker to Agree with You
#70Earlier quoted context omitted.
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 pers…
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…
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.