5 ms·

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 t

by BSVino 8y ago

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?

deleted 8y ago
[deleted]
matmann2001 8y ago
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?
- BSVino 8y ago
  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.
yosito 8y ago
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!
JimboOmega 8y ago
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?

by BSVino 8y ago

deleted 8y ago

[deleted]

matmann2001 8y ago

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?

BSVino 8y ago
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.

yosito 8y ago

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!

JimboOmega 8y ago

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?