BSVino

You make a good point. The junior team members I'm thinking about felt they didn't have the authority and so didn't approach leadership with a plan. I'm not saying they should assume responsibilities without direction of leadership, but rather that they can follow step 1 in the article regardless of their level in the organization. Even a senior person must follow the direction of leadership, the difference is that the senior person knows that they can approach leadership with a plan.

Hello. Article author here. I agree, people should only follow good ideas. I didn't explicitly mention this in the article, but I believe that a person in a healthy work environment who genuinely follows the process of feedback as outlines will eventually turn their bad or mediocre ideas into good ideas as they integrate feedback, or else the leadership won't approve their change and the team will refuse to adopt the idea. After all, it's tough to get people to voluntarily adopt a bad idea.

Hello. Article author here. You can do this and it might be the appropriate approach in some situations, but you run the risk of degrading your reputation with management. Putting aside the personal risk, I tend to think of maintaining your reputation with your teammates as more important in the long run than accomplishing something or being right about any particular issue, since it preserves your ability to persuade them in the future.

Also I've found that if management is resistant to change they usually have good reasons, even if sometimes they can't or won't share them, so circumventing them can sometimes be counter-productive. Usually better to just be on the up-and-up.

Hello, author of the article here. Kara is a "they". Many people use "they/their" as their singular pronoun. My coworker was one such person. :)

Hi, author of the article here.

Security can be a pretty significant cost to the business and if your teammates aren't concerned about it then that's a red flag that maybe you're in the wrong place.

But for the time being, yes, consider not. First, consider whether security on your team is a concern at all, for example you're working on an internal tool and you can trust your teammates not to go looking for buffer overflows.

Otherwise, the question I have is, why is there no process for dealing with security flaws? Whose responsibility is it to set up that process? Send your discovered flaw to that person and suggest that they set up such a process so that you can submit any future flaws, and then your obligation to the customer is done. If you burn your relationship with your teammates, you give up any chance of influencing them to improve their security practices in the future.

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. :)

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.

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!

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.