> I am assigned a feature ... that I feel adds unnecessary complexity > [My] managers ... minds are already made up. One of the things that I found helped me

> I am assigned a feature ... that I feel adds unnecessary complexity > [My] managers ... minds are already made up. One of the things that I found helped me the most when dealing with features like this is to Let Go of Caring about that particular thing. We fight for what we believe is best, but when a customer, manager, or other higher-ranking stakeholder decides otherwise, it's out of our hands. You did your professional duty by arguing for the Better way (as you see it), but now it's time to make the new direction work. UX team decides buttons should be the way that pisses you off the most? It's OK, you're not the main user. Manager decides that a "Calculate" button is better than auto-re-calculating? That's ok: the users are happier using that. (We can transition later.) They want an e-mail based workflow for approving things, rather than a web-based one? That's OK: these execs spend most of their time with their phones, and don't want to be logging into the website. Often what we feel is "unnecessary complexity" is a workaround for a key use case that we didn't realize, or yields customer happiness because it's what they asked for. In that case, it's __necessary__ complexity, just like a bit of ugly code that patches a bug. Try looking at it from the perspective of the user or the manager, and really understand why they feel it is important -- quite often, it's addressing a weakness of your software product that you were not aware of, or which you felt was unimportant.