What to do when my ideas aren't chosen, when I strongly disagree with the chosen solution? Unicorn Meta Zoo #1: Why another podcast? Announcing the arrival of Valued Associate #679: Cesar ManaraI am demotivated because my product owner does not care for project success, ideas for coping?What can an employee do when the employer does not assign any tasks?When given the choice in a test, should I use the older technology that I'm most comfortable with or a newer technology that I might struggle with?New supposedly experienced software developer disrupting my existing work in volunteer organisationWhat to do when the developer whose code I review becomes defensive?What to do when a Senior Employee is adding to the task each week and not letting me complete the ticket?What to do when manager has assigned me a project and I don't have the necessary product specific pre-requisite knowledge to do it?

Determinant of a matrix with 2 equal rows

using NDEigensystem to solve the Mathieu equation

What is the evidence that custom checks in Northern Ireland are going to result in violence?

What's parked in Mil Moscow helicopter plant?

Why aren't road bicycle wheels tiny?

Was there ever a LEGO store in Miami International Airport?

Is Bran literally the world's memory?

Is a self contained air-bullet cartridge feasible?

Are there existing rules/lore for MTG planeswalkers?

RIP Packet Format

What's called a person who works as someone who puts products on shelves in stores?

Why does Java have support for time zone offsets with seconds precision?

What is ls Largest Number Formed by only moving two sticks in 508?

My admission is revoked after accepting the admission offer

How long can a nation maintain a technological edge over the rest of the world?

Why did Europeans not widely domesticate foxes?

Why isPrototypeOf() returns false?

Where can I find how to tex symbols for different fonts?

Why isn't everyone flabbergasted about Bran's "gift"?

Why is arima in R one time step off?

How did Elite on the NES work?

Arriving in Atlanta after US Preclearance in Dublin. Will I go through TSA security in Atlanta to transfer to a connecting flight?

Why do people think Winterfell crypts is the safest place for women, children and old people?

Page Layouts : 1 column , 2 columns-left , 2 columns-right , 3 column



What to do when my ideas aren't chosen, when I strongly disagree with the chosen solution?



Unicorn Meta Zoo #1: Why another podcast?
Announcing the arrival of Valued Associate #679: Cesar ManaraI am demotivated because my product owner does not care for project success, ideas for coping?What can an employee do when the employer does not assign any tasks?When given the choice in a test, should I use the older technology that I'm most comfortable with or a newer technology that I might struggle with?New supposedly experienced software developer disrupting my existing work in volunteer organisationWhat to do when the developer whose code I review becomes defensive?What to do when a Senior Employee is adding to the task each week and not letting me complete the ticket?What to do when manager has assigned me a project and I don't have the necessary product specific pre-requisite knowledge to do it?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








58















Bit of a psychological question I have here in relation to working as a programmer.



In your work environment, when you're working on a particular system and that system needs to change due to requirements introduced or thought-up by others that you disagree with (either because you feel the change is unnecessary, or you disagree with the direction of the change), how do you deal with this conflict once it has been decided that this is something that must go ahead, if you feel strongly against the change?



I find that this severely impacts my mental state (either by making me feel less motivated, agitated, angry/frustrated, or what have you), and I'd like a solution.



To elaborate further we had a team meeting and my proposed solution was not the chosen one. The other participants of the meeting considered their approach as the correct one, but I disagreed with their perspective. This has happened several times and each time it happens I find myself feeling the way described in my post.



For example, one recent discussion was whether we should move certain state responsibilities to the backend to make the frontend easier to manage, and another was whether we should allow customers to alter their personal information without approval from an admin.



I strongly disagreed with the chosen outcome, which was settled based on majority (we're a team of 3 co-founders), and so I'm not sure how to reconcile the feeling of having to do work to support a path I don't agree with.










share|improve this question



















  • 3





    The title of your answer doesn't match the content. Did a single decision not be what you hoped, or have you lost all decision making power?

    – Gregory Currie
    Mar 25 at 12:25






  • 64





    How much experience do you have as a professional programmer? I ask, because one of the most important lessons I learned, after a few years, is to separate myself from my code. That doesn't mean there are times you shouldn't fight for what is "correct", but it is to learn to accept that other people are going to do things differently than you would, and the vast majority of time, what they are proposing is also okay.

    – dan.m was user2321368
    Mar 25 at 13:06











  • @dan.mwasuser2321368 I've been a professional programmer for over 10 years, however these are new circumstances in my life (where I have as much authority and control as my other cofounders).

    – jrichie911
    Mar 25 at 13:21






  • 12





    I will just add, I don't think I see enough to think there are several mental health issues, more like an impact on mental state. Having been in charge of projects that have been pulled away from me (and mutilated - in my opinion) I can understand the... grief... that comes with it. It's natural when you're invested in something.

    – Gregory Currie
    Mar 25 at 14:51






  • 2





    @GregoryCurrie I dont think he mean OP is sick. Maybe he just need the right tools to handle the grief, and a mental health professional can help with that.

    – Juan Carlos Oropeza
    Mar 25 at 15:20

















58















Bit of a psychological question I have here in relation to working as a programmer.



In your work environment, when you're working on a particular system and that system needs to change due to requirements introduced or thought-up by others that you disagree with (either because you feel the change is unnecessary, or you disagree with the direction of the change), how do you deal with this conflict once it has been decided that this is something that must go ahead, if you feel strongly against the change?



I find that this severely impacts my mental state (either by making me feel less motivated, agitated, angry/frustrated, or what have you), and I'd like a solution.



To elaborate further we had a team meeting and my proposed solution was not the chosen one. The other participants of the meeting considered their approach as the correct one, but I disagreed with their perspective. This has happened several times and each time it happens I find myself feeling the way described in my post.



For example, one recent discussion was whether we should move certain state responsibilities to the backend to make the frontend easier to manage, and another was whether we should allow customers to alter their personal information without approval from an admin.



I strongly disagreed with the chosen outcome, which was settled based on majority (we're a team of 3 co-founders), and so I'm not sure how to reconcile the feeling of having to do work to support a path I don't agree with.










share|improve this question



















  • 3





    The title of your answer doesn't match the content. Did a single decision not be what you hoped, or have you lost all decision making power?

    – Gregory Currie
    Mar 25 at 12:25






  • 64





    How much experience do you have as a professional programmer? I ask, because one of the most important lessons I learned, after a few years, is to separate myself from my code. That doesn't mean there are times you shouldn't fight for what is "correct", but it is to learn to accept that other people are going to do things differently than you would, and the vast majority of time, what they are proposing is also okay.

    – dan.m was user2321368
    Mar 25 at 13:06











  • @dan.mwasuser2321368 I've been a professional programmer for over 10 years, however these are new circumstances in my life (where I have as much authority and control as my other cofounders).

    – jrichie911
    Mar 25 at 13:21






  • 12





    I will just add, I don't think I see enough to think there are several mental health issues, more like an impact on mental state. Having been in charge of projects that have been pulled away from me (and mutilated - in my opinion) I can understand the... grief... that comes with it. It's natural when you're invested in something.

    – Gregory Currie
    Mar 25 at 14:51






  • 2





    @GregoryCurrie I dont think he mean OP is sick. Maybe he just need the right tools to handle the grief, and a mental health professional can help with that.

    – Juan Carlos Oropeza
    Mar 25 at 15:20













58












58








58


9






Bit of a psychological question I have here in relation to working as a programmer.



In your work environment, when you're working on a particular system and that system needs to change due to requirements introduced or thought-up by others that you disagree with (either because you feel the change is unnecessary, or you disagree with the direction of the change), how do you deal with this conflict once it has been decided that this is something that must go ahead, if you feel strongly against the change?



I find that this severely impacts my mental state (either by making me feel less motivated, agitated, angry/frustrated, or what have you), and I'd like a solution.



To elaborate further we had a team meeting and my proposed solution was not the chosen one. The other participants of the meeting considered their approach as the correct one, but I disagreed with their perspective. This has happened several times and each time it happens I find myself feeling the way described in my post.



For example, one recent discussion was whether we should move certain state responsibilities to the backend to make the frontend easier to manage, and another was whether we should allow customers to alter their personal information without approval from an admin.



I strongly disagreed with the chosen outcome, which was settled based on majority (we're a team of 3 co-founders), and so I'm not sure how to reconcile the feeling of having to do work to support a path I don't agree with.










share|improve this question
















Bit of a psychological question I have here in relation to working as a programmer.



In your work environment, when you're working on a particular system and that system needs to change due to requirements introduced or thought-up by others that you disagree with (either because you feel the change is unnecessary, or you disagree with the direction of the change), how do you deal with this conflict once it has been decided that this is something that must go ahead, if you feel strongly against the change?



I find that this severely impacts my mental state (either by making me feel less motivated, agitated, angry/frustrated, or what have you), and I'd like a solution.



To elaborate further we had a team meeting and my proposed solution was not the chosen one. The other participants of the meeting considered their approach as the correct one, but I disagreed with their perspective. This has happened several times and each time it happens I find myself feeling the way described in my post.



For example, one recent discussion was whether we should move certain state responsibilities to the backend to make the frontend easier to manage, and another was whether we should allow customers to alter their personal information without approval from an admin.



I strongly disagreed with the chosen outcome, which was settled based on majority (we're a team of 3 co-founders), and so I'm not sure how to reconcile the feeling of having to do work to support a path I don't agree with.







software-development developer motivation task-management psychology






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 25 at 22:49









Zymus

2,1581612




2,1581612










asked Mar 25 at 12:00









jrichie911jrichie911

399126




399126







  • 3





    The title of your answer doesn't match the content. Did a single decision not be what you hoped, or have you lost all decision making power?

    – Gregory Currie
    Mar 25 at 12:25






  • 64





    How much experience do you have as a professional programmer? I ask, because one of the most important lessons I learned, after a few years, is to separate myself from my code. That doesn't mean there are times you shouldn't fight for what is "correct", but it is to learn to accept that other people are going to do things differently than you would, and the vast majority of time, what they are proposing is also okay.

    – dan.m was user2321368
    Mar 25 at 13:06











  • @dan.mwasuser2321368 I've been a professional programmer for over 10 years, however these are new circumstances in my life (where I have as much authority and control as my other cofounders).

    – jrichie911
    Mar 25 at 13:21






  • 12





    I will just add, I don't think I see enough to think there are several mental health issues, more like an impact on mental state. Having been in charge of projects that have been pulled away from me (and mutilated - in my opinion) I can understand the... grief... that comes with it. It's natural when you're invested in something.

    – Gregory Currie
    Mar 25 at 14:51






  • 2





    @GregoryCurrie I dont think he mean OP is sick. Maybe he just need the right tools to handle the grief, and a mental health professional can help with that.

    – Juan Carlos Oropeza
    Mar 25 at 15:20












  • 3





    The title of your answer doesn't match the content. Did a single decision not be what you hoped, or have you lost all decision making power?

    – Gregory Currie
    Mar 25 at 12:25






  • 64





    How much experience do you have as a professional programmer? I ask, because one of the most important lessons I learned, after a few years, is to separate myself from my code. That doesn't mean there are times you shouldn't fight for what is "correct", but it is to learn to accept that other people are going to do things differently than you would, and the vast majority of time, what they are proposing is also okay.

    – dan.m was user2321368
    Mar 25 at 13:06











  • @dan.mwasuser2321368 I've been a professional programmer for over 10 years, however these are new circumstances in my life (where I have as much authority and control as my other cofounders).

    – jrichie911
    Mar 25 at 13:21






  • 12





    I will just add, I don't think I see enough to think there are several mental health issues, more like an impact on mental state. Having been in charge of projects that have been pulled away from me (and mutilated - in my opinion) I can understand the... grief... that comes with it. It's natural when you're invested in something.

    – Gregory Currie
    Mar 25 at 14:51






  • 2





    @GregoryCurrie I dont think he mean OP is sick. Maybe he just need the right tools to handle the grief, and a mental health professional can help with that.

    – Juan Carlos Oropeza
    Mar 25 at 15:20







3




3





The title of your answer doesn't match the content. Did a single decision not be what you hoped, or have you lost all decision making power?

– Gregory Currie
Mar 25 at 12:25





The title of your answer doesn't match the content. Did a single decision not be what you hoped, or have you lost all decision making power?

– Gregory Currie
Mar 25 at 12:25




64




64





How much experience do you have as a professional programmer? I ask, because one of the most important lessons I learned, after a few years, is to separate myself from my code. That doesn't mean there are times you shouldn't fight for what is "correct", but it is to learn to accept that other people are going to do things differently than you would, and the vast majority of time, what they are proposing is also okay.

– dan.m was user2321368
Mar 25 at 13:06





How much experience do you have as a professional programmer? I ask, because one of the most important lessons I learned, after a few years, is to separate myself from my code. That doesn't mean there are times you shouldn't fight for what is "correct", but it is to learn to accept that other people are going to do things differently than you would, and the vast majority of time, what they are proposing is also okay.

– dan.m was user2321368
Mar 25 at 13:06













@dan.mwasuser2321368 I've been a professional programmer for over 10 years, however these are new circumstances in my life (where I have as much authority and control as my other cofounders).

– jrichie911
Mar 25 at 13:21





@dan.mwasuser2321368 I've been a professional programmer for over 10 years, however these are new circumstances in my life (where I have as much authority and control as my other cofounders).

– jrichie911
Mar 25 at 13:21




12




12





I will just add, I don't think I see enough to think there are several mental health issues, more like an impact on mental state. Having been in charge of projects that have been pulled away from me (and mutilated - in my opinion) I can understand the... grief... that comes with it. It's natural when you're invested in something.

– Gregory Currie
Mar 25 at 14:51





I will just add, I don't think I see enough to think there are several mental health issues, more like an impact on mental state. Having been in charge of projects that have been pulled away from me (and mutilated - in my opinion) I can understand the... grief... that comes with it. It's natural when you're invested in something.

– Gregory Currie
Mar 25 at 14:51




2




2





@GregoryCurrie I dont think he mean OP is sick. Maybe he just need the right tools to handle the grief, and a mental health professional can help with that.

– Juan Carlos Oropeza
Mar 25 at 15:20





@GregoryCurrie I dont think he mean OP is sick. Maybe he just need the right tools to handle the grief, and a mental health professional can help with that.

– Juan Carlos Oropeza
Mar 25 at 15:20










13 Answers
13






active

oldest

votes


















55















how do you deal with this conflict once it has been decided that this is something that must go ahead, if you feel strongly against the change?




My way of dealing with this is considering what my role in the company is. Am I there as a developer? As an analyst? As a team lead? As a project manager?



If I'm the developer (which I surmise you are), then you never had "decision making power" to begin with. You simply had some decision making privilege that was extended to you because someone (with actual power) chose to follow your decision.



Edit: you mention the three of you are co-founders, but the answer remains the same. You don't have any power, only a majority of you wields any power. In this case, you are not part of the majority.



If you're not holding the wheel, you're not steering the ship and thus cannot override the decision that is made by whoever is holding the wheel. You can ask them (which you did), but they can ignore/deny/disagree with your request. Not your circus, not your monkeys.



You informatively raised a concern, it was ignored. Accept the outcome and follow the plan as agreed upon. You and your two colleagues are there as a team, not as a darwinian competition.
Even if you were right, the other two developers clearly did not think so and will have to make the mistake before they realize it was a mistake. Everyone does what they consider to be the best thing, until they understand that it's not actually the best thing. In some cases, that means having to learn the hard way. This can apply to either you or your colleages, only time will tell.



If you want to be the one steering the ship, you must first be in a position to do so. But if you're unable to deal with things not going your way, I'm apprehensive about your compatibility in a leadership role, as it entails much more compromise than outsiders seem to think it does.




I find that this severely impacts my mental state (either by making me feel less motivated, agitated, angry/frustrated, or what have you), and I'd like a solution.




The short answer, in the words of Disney's Frozen, let it go. That's easier said than done, but it will boil down to this.



Look inwards and ask yourself why you care so much that you're willing to die on this particular hill. Is it because you only want to do things your way? It is because you are unwilling to learn a different way of doing things? Is it because you have a different appraoch to developing and abhor the alternative?



How can you be sure that you are objectively more correct than the others? If you are, then why did you not used that irrefutible evidence to make your case before the vote?



Never lose sight of the big picture: you're an employee of the company, and you're there to do the work the company tells you to do (within the boundaries defined in your contract). You don't get to decide which work you get to do.



Let it go, and accept that when someone else overrides your decision, the consequences of that decision fall on them. You are not personally responsible for the company's wellbeing against the company's own wishes.




I strongly disagreed with the chosen outcome, which was settled based on majority (we're a team of 3 co-founders), and so I'm not sure how to reconcile the feeling of having to do work to support a path I don't agree with.




First of all: you agreed to a vote, you partook in a vote, and now that the decision hasn't gone your way, you're wanting to pipe up about it. At first glance, I would consider whether you're being a sore loser here.



The fact that a vote needed to take place suggests that the decision was not unanimous, which inherently means that someone was always going to "lose". This time, it is you. So you have two options: you accept the outcome, or you don't.



Imagine if everyone who didn't get their way did not accept anything other than what they wanted. How much progress do you think you'd make if the other two developers blocked you every time one of them did not agree?

As a real world example, imagine if everyone in a democracy had veto power over everyone else, and you could only get things done when every citizen unanimously agrees. Nothing would ever get done.



If you do make a fuss, and let's say you even manage to get your way eventually, you will be known as a sore loser and unwilling to work in a team or compromise. All of these observations will be much more detrimental to your career than the minor benefit of being right.






share|improve this answer




















  • 2





    "Never lose sight of the big picture: you're an employee of the company" - I find this the easiest thing to forget sometimes. If you tie your personal identity to the company it can make you feel that the company failing is you failing. In reality, you are a separate human, who is simply paid to do a job - if the company fails or releases bad products, it does not mean you failed. Your personal value != the value of the company.

    – Bilkokuya
    Mar 26 at 13:19












  • @Bilkokuya: With the right mindset, the company making a bad decision that leads to a buggy product can be a form of job security. That's how I try to look at it when I hit a wall when trying to proactively (and pre-emptively) trying to improve things.

    – Flater
    Mar 26 at 14:53












  • @Flater To some degree. At some point, the company is gone, the job is gone.

    – gnasher729
    Mar 31 at 19:42


















34














You've expressed your idea clearly and they decided they did not want to accept your decision and this bothers you. Well of course it bothers you. You've made an excellent case for a particular technology to be used and they flat out denied it.



Though remember that politics are always at play, and you cannot understand all the underlying reasons behind any given decision. Even if this were not the case, you should always keep in mind that it isn't a direct attack on you, nor is it saying that you are incapable of making good choices in this matter.



As a programmer myself, you learn to go with the flow and respect the decisions of your colleagues, even if you disagree. Fight the battles that deserve fighting for, when you think that it would be a seriously bad choice otherwise. Being a team player is every bit as important as making the right technical choices, and you should learn to trust in your colleagues just as they should learn to trust in you.



However, this only addresses the inward issue. If you feel that a mistake is being made, then the proper approach is to make it clear first and foremost to your colleagues, and should they not agree, with your boss directly. It need not be a personal vendetta, but rather something you're making clear. After this point, you cannot be held accountable for potential problems which may result from this (though they can still ask you to fix it).



TL;DR - Try to pick your battles, but not at the expense of trust from your fellow colleagues. If you absolutely must object to a decision, simply make it clear, and then continue to be a team player.



Edit: In light of your edited question, then I suppose not much can be done. If perhaps you are the expert in this regard, then you could put in an argument that in such matters, you should be given full control (but strictly for technical issues such as this). Though if I understand you correctly, that isn't the case.



So the next best thing is trying to make their proposed solution work as best as possible. While it can't be your idea, at least you can make it work well, and there is some small satisfaction in this. It would be ill-advised to sabotage the idea to prove your solution correct. Ultimately, they are co-founders, and so you must respect their decision just as they must respect yours should you and another co-founder agree on something which the third does not.






share|improve this answer




















  • 8





    Good answer. I will just say, sometimes it's not even "politics", but just non-technical things. There can be time pressures, money pressures, patents, sensitive clients, etc. A whole stack of reasons that a manager may not mention to a programmer, but is important anyway.

    – Gregory Currie
    Mar 25 at 12:23











  • @Neil Appreciate your answer, thank you very much. Just to clarify, this is a project with myself and two other co-founders, so I'm not answering to management here. I've also added a bit of further clarification as a reply to a comment in my original post if you care to read more on the circumstances.

    – jrichie911
    Mar 25 at 13:24












  • @jrichie911 I expanded on my answer. I hope that answers your question.

    – Neil
    Mar 25 at 13:41











  • @Neil thank you very much.

    – jrichie911
    Mar 25 at 14:33






  • 1





    @jrichie911 the fact there is no manager above does not invalidate this answer at all. I would even say it's more on the spot than the accepted one. You may consider why your suggestions were discarded to do better in the future. Maybe there was a flaw in your assumptions? Maybe you weren't clear enough? Maybe the two colleagues have better bonds and you're treated as some sort of an outsider now?

    – Ister
    Mar 27 at 11:54


















18














It's a completely understandable reaction and a human one.



You know you tried to influence the decision making process, you tried your hardest, and things didn't end up as you think they should.



What I find with a lot of things is if I understand everybody wants the best outcome, it makes it easier for me. If I can work with a bunch of people who are committed to everyone understanding the pros and cons of each solution, that gives me confidence that on average, the best solution is often decided.



Often what it comes down to is a slight disagreement in perceived importance. For instance, one person may think performance is more important than code clarity.



You have to remember, the best teams operate when there are disagreements. If you have a team of "yes men" as a team, you are not likely to do great work. So there will often be somebody that's a bit disappointed. But the team not deciding to go down a path doesn't mean everything you said is wasted. Quite often it will stay at the back of people's minds.



As you point out, once a course of action is decided, you do have to commit to it. If you have concerns, you should explore how they may be mitigated within the context of the decided solution. But you shouldn't compromise your team.



Also, something to keep in mind, often there are a lot of non-technical reasons why the best solution is not followed.



You will get used to this, just as I have.






share|improve this answer

























  • Nicely expressed.

    – Sourav Ghosh
    Mar 25 at 12:45











  • "I understand everybody wants the best outcome" - this is the critical part in my opinion.

    – afaulconbridge
    Mar 25 at 15:51


















9














Addressing this solely from the psychological stance asked for, I find there are a few things that help me get over a "bad choice" (in my opinion).



The first is simply a little time - if I have to start coding the "wrong thing" immediately, my mind is replaying all of the arguments against this, not trying to see the best way to create it. Usually if I can put it off for a day or two, I've accepted the decision and am more relaxed about it, particularly after sleeping on it (so my brain stops the cycle of "but the reasons against it are x.... y.... etc")



Second, there can be a feeling that your opinion wasn't heeded or that you are powerless because you can't change this decision. Going back to the code and doing something else that I do want done (that has been agreed or I have the power to choose) can help me feel back in control and that I am contributing good changes to the code-base.



Third, when I do come to designing/coding the required change, I am looking into how to make it work as smoothly as possible ("even if it's wrong we're going to do it well"). Trying to maximize the benefits that were used to make this decision and reduce what I saw as the problems with it helps to get me invested in making this solution work and usually I find I get to the point of "not the best decision, but actually not as bad as I thought".






share|improve this answer


















  • 2





    +1 First answer I've seen that actually seems to understand the problem the OP is having and addresses it in a way that might be helpful (edit: as much as I don't want to insult the other answers or the genuine helpfulness of the people giving them, OP is dealing with a very acute and uncommon problem of executive function (psychology term) and motivation. Many people seem to not experience this problem the same way, thus lack the mind interferometry skills to pick up on it, and don't know how to help another mind find the consciously controllable cognition needed to overcome the problem.)

    – mtraceur
    Mar 25 at 22:28












  • Fourth, Look forward to your glee when, once the feature is done, everybody else will see how it sucks. Not because you implemented it as badly as possible, but despite you put your best effort into it. Getting it done as quickly as possible will minimize your losses when they finally decide to say you're right and abandon the whole thing, and doing it as well as possible will minimize the "oh, let's change this and that to get it right" cycles. When people insist on shooting themselves in the foot, sometimes you'll have to allow them feel the pain. Petty? yes. But it might help motivate you.

    – Guntram Blohm
    Mar 26 at 7:04


















4














Simple concept: "feeling" is not a driver for a change (or lack thereof). It is a fact driven event. Given there are enough facts to support the change, it'll happen, despite you like it or not.



You need to learn how to work with a team, and also need to learn, how to adjust yourself with a rejection. Remember this: you don't "own" anything in a team discussion, you are a participant.



There are reasons, valid reasons, for any proposal being accepted or turned down. There are ways to showcase your disagreement and providing the proofs, like, having PoCs, SWOT analysis result etc, getting angry or frustrated or agitated is not one of them. At end of the day, not up to you to make the final decision, so let it go.



Direct your "anger" or "frustration" towards a positive side: For example,



  • Do better homework on the topics being discussed next time.

  • Invest more in finding the downsides of the other proposed solutions, and also present ideas which promise to solve the downsides you have identified. In other words, don't just point out the shortcomings, also find ways to mitigate them.


  • Do not try to "compete", rather "collaborate". Don't expect everyone to accept what you propose, and at the same time, don't blindly reject everyone else's idea because you have one of your own.



    Compare, collate and collaborate - that way you may find every idea has some contribution from your own.







share|improve this answer
































    1














    Although the other answers provide fair points, let me explore a possibility that seems to me it was not properly considered in some of them.



    I have 20+ years of experience as a developer and until last year I never had any issue with the outcome of design sessions. Usually, such sessions would end like this:



    • My solution was accepted verbatim (10%)

    • My solution had flaws and it was improved by the team or merged with other solution (50%)

    • There was a better solution from someone else (40%)

    The accepted design represented an overall view of the team and at least I never had a trouble going forward with it, because I always thought we got a good solution on the end.



    However, last year I joined a team, composed of people from different backgrounds, that were working together for 6 months beforehand. They had a complete different set of priorities in their thinking, that clashed directly with mine most of the time.



    For me, their designs were brittle, hardcoded and somewhat inflexible. For them, my proposals were fancy, over-engineered.



    It was very hard for me to accept, for example, to create a parser engine whose outcome would depend on the name of the json file. I tried to explain to them that we would have more advantages having metadata inside the json instead of simply relying in its name, but the collective decision was that asking the users to create additional fields was unnecessary.



    Then they decided to create the code without unit tests, instead having integration tests to check everything end-to-end (3 minutes of execution time). And then came several other decisions that I couldn't simply agree with.



    For almost an year, I tried to reason with them. I applied several suggestions from the agile coaches of the company, asked fellow engineers to evaluate if I was wrong in my assessments, suggested to do spikes to compare solutions with facts not opinions, among other strategies, including taking 3 soft skills courses to see if it would help.



    With time, some situations arose that showed them the problems in our solutions, and eventually they recognized that some of them would have been avoided with a "fancy" design. But most of the time, I was still the absolute minority in the design sessions.



    In the end, I asked and changed to another team. that solved the issue for me, but it is not the case here for you.



    In your case, I would suggest:



    1. are the decisions so bad that you can't live with them? Can you try to tolerate them to see if time can show the chosen design was not the best one?


    2. in your relationship with these other founders, can you openly tell them how you feel about this?


    3. try some soft skills courses, to see if this can enable you to better communicate your ideas


    4. can you bring somebody else to support you? being only founders, this may be impossible or awkward, but I don't know your environment. a professional coach, for example, may assist/mediate your discussions and help you see the social dynamics happening while you make decisions






    share|improve this answer























    • It seems like you clashed at the beginning and it is very hard to recover from that. It is almost always better to learn how and why things are done the way they are because there's usually a historical reason for it. Prior to pushing ideas you should also earn some respect for your skills and knowledge. Once you learn the lay of the land and people 'trust' you, which could take quite a few months then you pick the low hanging fruit with the most bang for the buck which further increases people's trust in you as your impact is noticeable.

      – Dunk
      Mar 25 at 21:50







    • 1





      Being the newbie telling everyone they are doing it wrong seldom gets you anywhere other than people to begin tuning you out even when you have good ideas to share.

      – Dunk
      Mar 25 at 21:52











    • @Dunk You are right - criticism isn't easily accepted from "outsiders". But teams differ a lot in terms of embracing criticism in general. There aren't many (but they do exist) teams that openly admit that their "historical reasons" were as typical - sometimes in fact identical - as the more recent reasons, i.e. "we were too lazy to fix it" or "it was done by 2 people over a single Sunday evening" or "this decision was just one giant ego trip of our CTO" or "it's a workaround for a problem that doesn't exist anymore".

      – kubanczyk
      Mar 26 at 0:38











    • Hi @Dunk, just to clarify, I was transferred to the team to develop with them a completely new feature, from scratch. I didn't offer criticism on existing implementations, we were talking about the design for a new project. We were reading the requirements, raising questions and proposing solutions. That was when we start diverging. I completely agree with what you said, it is pretty easy to come later and judge previous decisions made by a team, but that was not what I have done here, at least in my view.

      – Quaestor Lucem
      Mar 26 at 13:27


















    1














    As others have said, what you're feeling is normal, and understandable.



    First and foremost, I'd assume good faith from everyone else. Second, I'd ask for more information about people's reasoning. And third, use that information to help you in the future.



    To elaborate, first and foremost, you have to assume that the other people involved in making the decision are rational, and have reasons for what they're doing. So either you don't understand their reasons, or you disagree with them. So I'd talk to them and get a better idea for why they went with a different option. Why are they prioritizing those concerns over the things you value? I know that as an engineer, it can be very hard to balance technical correctness/best practices versus actually shipping a product.



    For example, they think that moving logic from the backend to the frontend will make certain things easier to manage, and they want to allow people to make certain changes you think an admin should make, which again seems like it will minimize the amount of management you/the admin needs to do. You probably prioritize other characteristics, or disagree that those changes will minimize the amount of management time.



    So one thing you could do, going forward, is at least think about changing your metrics for decision to match those of your other cofounders, and/or focus your energy on the areas that you think will maximize whatever characteristics you care about. And be prepared to not "win" all the discussions. Worst case, if everything goes horribly wrong, you can always say "I told you so."






    share|improve this answer






























      1














      Much of it is about the mindset you enter the meeting with. If you want them to pick your solution and they don't, that's a defeat. And it sucks extra hard because as a co-equal co-founder you now need to slave away for those who defeated you.



      Try these to avoid the feeling of defeat:



      1. Chose your battles, early.


      2. Learn how to convince people.


      3. Invest in partial victories.


      Chose your battles



      Emotional investment, as the word says, is an investment. Invest wisely. You see their approach, it's good enough, and arguing about it costs more than the benefits of your approach? Spend the time improving their approach instead. Oftentimes keeping momentum and focus is far more important than getting things perfect, especially in a startup. But sometimes it isn't. Try to tell the 2 apart, and learn to see benefits where you haven't seen them before.



      Learn how to convince people



      This is way too long for this format, so to keep it brief: there are management courses for exactly that. It includes not just how to talk, but also how you dress, your body language, and how you listen to people.



      Invest in partial victories



      You mustn't want people to pick your solution. When you go into strategy meetings, the ideal outcome is that together you come up with a solution that has the potential to be better than the one you had. The minimal outcome must be that they hear and acknowledge your concerns. Your solution isn't what's important. Your concerns about the chosen solution are what's important.






      share|improve this answer






























        0














        Just talking generally, I think there's two basic things to consider here:



        1. The responsibility of the leader/manager/boss/person with authority. It is, at least partially, the job of a leader to make sure their employees are in a good mental condition and stay motivated; if you repeatedly feel slighted, I suggest you try to communicate. This shouldn't affect the end decisions, but it may affect your ability to accept them; it might also cause change in the behavior of your colleagues, maybe change the way they present their ideas, or the way they respond to yours.

        2. The responsibility of you as a professional. You should realize (not just consciously, but on an emotional level) that sometimes you might not be right, or you may not have all the information; it is entirely possible your idea was wrong, maybe not for you personally, but for the project/team/company as a whole. Of course, it's also possible you were right; in that case, keep in mind that you presented your idea and got it rejected; at that point, the responsibility doesn't lie with you. If your colleagues keep making decisions that turn out to be wrong, that might be a sign you might want someone else (potentially you) calling the shots, at least in certain fields; but if that's not the case, then maybe you're just wrong sometimes.





        share|improve this answer






























          0














          Having recently encountered this myself, I would highlight you're a team of 3 co-founders, you've been outvoted; and you'd be equally annoyed if it was the other way around where someone was demanding something but had been outvoted.



          Ultimately, you've made your case, and presented the pro's and con's; but if they don't want to listen to your experience then you must walk away with the knowledge that people need to learn from their mistakes. The first is on whatever you were discussing, and the second is to ignore the experience which is why I assume you were brought onto the team... just don't say "I told you so".



          Lastly, your mistake is to get overly stressed by this. The decision has been made, and unless you can bring new evidence or reasoning; then you're unlikely to convince the others to change.






          share|improve this answer






























            0














            I would like to add to the existing answers, that the very excellent book "The Five Dysfunctions of a Team" by Patrick Lencioni has a whole chapter about this, and is a very relaxed read.



            In summary, what the book says is that team dysfunction often happens as a pyramid, which starts as lack of trust between team members (in the sense that they can be trusted that they all share a common goal first and are able to put personal benefits second). Without trust, you can't get creative and constructive 'conflict', and instead you avoid trouble by going quiet, which leads to 'artificial harmony'.



            The next step up in the dysfunctional pyramid is where you're at. If it becomes impossible for you to create constructive 'conflict' and have your ideas discussed on their merit, whatever decision is chosen will leave you feel 'wronged', and like you didn't have a stake in it. In other words, there will be no 'buy-in'. This in turn leads to the next dysfunction, which is, you will not care to keep either yourself or others accountable when things don't go according to plan; you will simply shrug and say "well it was never my idea in the first place".



            So, it appears, you are in a somewhat dysfunctional team, despite presumably best intentions. And, the 'blame' lies with both you and your team (as led by your manager). You, because you failed to conflict creatively to make your points, and instead accepted the resolution without having your concerns adequately addressed, and your manager because they didn't pick up on this.



            In an ideal team, there doesn't have to be a consensus of decision, there only has to be buy-in. In other words, I feel that what you feel is wrong here isn't that people chose the wrong decision per se, but the fact they chose it without listening to your concerns and discussing why they felt they were an appropriate risk etc.



            Going past this point, however, if your views have been discussed adequately and your points addressed and dismissed in a professionally appropriate context of a functional team, then you should accept the outcome, and hold yourself accountable to it as if it was your idea. If you feel the context was not appropriate, raise it with your manager, and state your concerns. Who knows, maybe they'll discuss your concerns with you and either have another meeting with the 'good' points you raised, or manage to convince you that your ideas were heard, and that there were valid reasons to take a different route (which may have been less technical and more business in nature, etc).






            share|improve this answer






























              0














              I would not care about psychological aspects. Use the competence you have to figure out which of the following four happened:



              • Your proposal is not good and the alternative was better. Nothing horrible.

              • Unable to find good enough arguments, they finally took the opinion of someone maybe slightly senior to you. This difference in seniority may be tiny and not worth to worry about.

              • It was something primarily opinion based, like Python vs C#. It may be completely different view in another workplace.

              • Not less probable than others - they have made the wrong decision. They will pay the price and probably will listen more carefully for you next time.





              share|improve this answer






























                0














                This question has already generated some excellent answers, but i feel one aspect has not been covered yet.



                When choosing between two possible directions, it is not the pros- and cons but the weights you have assigned them, you are comparing. You colleagues feel the pros of their approach outweight the cons, when compared to your approach. Maybe they are not entirely wrong?



                Years ago we needed to get a daily data-dump from one db to another. My manager wanted me to implement this by transferring an excel file and reading it into the db.
                I was livid! This would unnecessarily complicate things, i would be writing code just to deal with excel.



                His stance was that we needed to be able to check what was transferred in case the numbers didnt look right, or 'if we just needed to check'. I tried to explain there were other other ways, and anyway, running software is like a car: you test it before you take in on the road, you don't open the hood while driving on the highway 'just to check'.
                He won and i was very very angry.



                Years later I am much milder. I've seen cases where users found the numbers didn't add up, and being able to have them check intermediate steps is helpful. (still, csv would have been easier)






                share|improve this answer





















                  protected by mcknz Mar 26 at 16:33



                  Thank you for your interest in this question.
                  Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                  Would you like to answer one of these unanswered questions instead?














                  13 Answers
                  13






                  active

                  oldest

                  votes








                  13 Answers
                  13






                  active

                  oldest

                  votes









                  active

                  oldest

                  votes






                  active

                  oldest

                  votes









                  55















                  how do you deal with this conflict once it has been decided that this is something that must go ahead, if you feel strongly against the change?




                  My way of dealing with this is considering what my role in the company is. Am I there as a developer? As an analyst? As a team lead? As a project manager?



                  If I'm the developer (which I surmise you are), then you never had "decision making power" to begin with. You simply had some decision making privilege that was extended to you because someone (with actual power) chose to follow your decision.



                  Edit: you mention the three of you are co-founders, but the answer remains the same. You don't have any power, only a majority of you wields any power. In this case, you are not part of the majority.



                  If you're not holding the wheel, you're not steering the ship and thus cannot override the decision that is made by whoever is holding the wheel. You can ask them (which you did), but they can ignore/deny/disagree with your request. Not your circus, not your monkeys.



                  You informatively raised a concern, it was ignored. Accept the outcome and follow the plan as agreed upon. You and your two colleagues are there as a team, not as a darwinian competition.
                  Even if you were right, the other two developers clearly did not think so and will have to make the mistake before they realize it was a mistake. Everyone does what they consider to be the best thing, until they understand that it's not actually the best thing. In some cases, that means having to learn the hard way. This can apply to either you or your colleages, only time will tell.



                  If you want to be the one steering the ship, you must first be in a position to do so. But if you're unable to deal with things not going your way, I'm apprehensive about your compatibility in a leadership role, as it entails much more compromise than outsiders seem to think it does.




                  I find that this severely impacts my mental state (either by making me feel less motivated, agitated, angry/frustrated, or what have you), and I'd like a solution.




                  The short answer, in the words of Disney's Frozen, let it go. That's easier said than done, but it will boil down to this.



                  Look inwards and ask yourself why you care so much that you're willing to die on this particular hill. Is it because you only want to do things your way? It is because you are unwilling to learn a different way of doing things? Is it because you have a different appraoch to developing and abhor the alternative?



                  How can you be sure that you are objectively more correct than the others? If you are, then why did you not used that irrefutible evidence to make your case before the vote?



                  Never lose sight of the big picture: you're an employee of the company, and you're there to do the work the company tells you to do (within the boundaries defined in your contract). You don't get to decide which work you get to do.



                  Let it go, and accept that when someone else overrides your decision, the consequences of that decision fall on them. You are not personally responsible for the company's wellbeing against the company's own wishes.




                  I strongly disagreed with the chosen outcome, which was settled based on majority (we're a team of 3 co-founders), and so I'm not sure how to reconcile the feeling of having to do work to support a path I don't agree with.




                  First of all: you agreed to a vote, you partook in a vote, and now that the decision hasn't gone your way, you're wanting to pipe up about it. At first glance, I would consider whether you're being a sore loser here.



                  The fact that a vote needed to take place suggests that the decision was not unanimous, which inherently means that someone was always going to "lose". This time, it is you. So you have two options: you accept the outcome, or you don't.



                  Imagine if everyone who didn't get their way did not accept anything other than what they wanted. How much progress do you think you'd make if the other two developers blocked you every time one of them did not agree?

                  As a real world example, imagine if everyone in a democracy had veto power over everyone else, and you could only get things done when every citizen unanimously agrees. Nothing would ever get done.



                  If you do make a fuss, and let's say you even manage to get your way eventually, you will be known as a sore loser and unwilling to work in a team or compromise. All of these observations will be much more detrimental to your career than the minor benefit of being right.






                  share|improve this answer




















                  • 2





                    "Never lose sight of the big picture: you're an employee of the company" - I find this the easiest thing to forget sometimes. If you tie your personal identity to the company it can make you feel that the company failing is you failing. In reality, you are a separate human, who is simply paid to do a job - if the company fails or releases bad products, it does not mean you failed. Your personal value != the value of the company.

                    – Bilkokuya
                    Mar 26 at 13:19












                  • @Bilkokuya: With the right mindset, the company making a bad decision that leads to a buggy product can be a form of job security. That's how I try to look at it when I hit a wall when trying to proactively (and pre-emptively) trying to improve things.

                    – Flater
                    Mar 26 at 14:53












                  • @Flater To some degree. At some point, the company is gone, the job is gone.

                    – gnasher729
                    Mar 31 at 19:42















                  55















                  how do you deal with this conflict once it has been decided that this is something that must go ahead, if you feel strongly against the change?




                  My way of dealing with this is considering what my role in the company is. Am I there as a developer? As an analyst? As a team lead? As a project manager?



                  If I'm the developer (which I surmise you are), then you never had "decision making power" to begin with. You simply had some decision making privilege that was extended to you because someone (with actual power) chose to follow your decision.



                  Edit: you mention the three of you are co-founders, but the answer remains the same. You don't have any power, only a majority of you wields any power. In this case, you are not part of the majority.



                  If you're not holding the wheel, you're not steering the ship and thus cannot override the decision that is made by whoever is holding the wheel. You can ask them (which you did), but they can ignore/deny/disagree with your request. Not your circus, not your monkeys.



                  You informatively raised a concern, it was ignored. Accept the outcome and follow the plan as agreed upon. You and your two colleagues are there as a team, not as a darwinian competition.
                  Even if you were right, the other two developers clearly did not think so and will have to make the mistake before they realize it was a mistake. Everyone does what they consider to be the best thing, until they understand that it's not actually the best thing. In some cases, that means having to learn the hard way. This can apply to either you or your colleages, only time will tell.



                  If you want to be the one steering the ship, you must first be in a position to do so. But if you're unable to deal with things not going your way, I'm apprehensive about your compatibility in a leadership role, as it entails much more compromise than outsiders seem to think it does.




                  I find that this severely impacts my mental state (either by making me feel less motivated, agitated, angry/frustrated, or what have you), and I'd like a solution.




                  The short answer, in the words of Disney's Frozen, let it go. That's easier said than done, but it will boil down to this.



                  Look inwards and ask yourself why you care so much that you're willing to die on this particular hill. Is it because you only want to do things your way? It is because you are unwilling to learn a different way of doing things? Is it because you have a different appraoch to developing and abhor the alternative?



                  How can you be sure that you are objectively more correct than the others? If you are, then why did you not used that irrefutible evidence to make your case before the vote?



                  Never lose sight of the big picture: you're an employee of the company, and you're there to do the work the company tells you to do (within the boundaries defined in your contract). You don't get to decide which work you get to do.



                  Let it go, and accept that when someone else overrides your decision, the consequences of that decision fall on them. You are not personally responsible for the company's wellbeing against the company's own wishes.




                  I strongly disagreed with the chosen outcome, which was settled based on majority (we're a team of 3 co-founders), and so I'm not sure how to reconcile the feeling of having to do work to support a path I don't agree with.




                  First of all: you agreed to a vote, you partook in a vote, and now that the decision hasn't gone your way, you're wanting to pipe up about it. At first glance, I would consider whether you're being a sore loser here.



                  The fact that a vote needed to take place suggests that the decision was not unanimous, which inherently means that someone was always going to "lose". This time, it is you. So you have two options: you accept the outcome, or you don't.



                  Imagine if everyone who didn't get their way did not accept anything other than what they wanted. How much progress do you think you'd make if the other two developers blocked you every time one of them did not agree?

                  As a real world example, imagine if everyone in a democracy had veto power over everyone else, and you could only get things done when every citizen unanimously agrees. Nothing would ever get done.



                  If you do make a fuss, and let's say you even manage to get your way eventually, you will be known as a sore loser and unwilling to work in a team or compromise. All of these observations will be much more detrimental to your career than the minor benefit of being right.






                  share|improve this answer




















                  • 2





                    "Never lose sight of the big picture: you're an employee of the company" - I find this the easiest thing to forget sometimes. If you tie your personal identity to the company it can make you feel that the company failing is you failing. In reality, you are a separate human, who is simply paid to do a job - if the company fails or releases bad products, it does not mean you failed. Your personal value != the value of the company.

                    – Bilkokuya
                    Mar 26 at 13:19












                  • @Bilkokuya: With the right mindset, the company making a bad decision that leads to a buggy product can be a form of job security. That's how I try to look at it when I hit a wall when trying to proactively (and pre-emptively) trying to improve things.

                    – Flater
                    Mar 26 at 14:53












                  • @Flater To some degree. At some point, the company is gone, the job is gone.

                    – gnasher729
                    Mar 31 at 19:42













                  55












                  55








                  55








                  how do you deal with this conflict once it has been decided that this is something that must go ahead, if you feel strongly against the change?




                  My way of dealing with this is considering what my role in the company is. Am I there as a developer? As an analyst? As a team lead? As a project manager?



                  If I'm the developer (which I surmise you are), then you never had "decision making power" to begin with. You simply had some decision making privilege that was extended to you because someone (with actual power) chose to follow your decision.



                  Edit: you mention the three of you are co-founders, but the answer remains the same. You don't have any power, only a majority of you wields any power. In this case, you are not part of the majority.



                  If you're not holding the wheel, you're not steering the ship and thus cannot override the decision that is made by whoever is holding the wheel. You can ask them (which you did), but they can ignore/deny/disagree with your request. Not your circus, not your monkeys.



                  You informatively raised a concern, it was ignored. Accept the outcome and follow the plan as agreed upon. You and your two colleagues are there as a team, not as a darwinian competition.
                  Even if you were right, the other two developers clearly did not think so and will have to make the mistake before they realize it was a mistake. Everyone does what they consider to be the best thing, until they understand that it's not actually the best thing. In some cases, that means having to learn the hard way. This can apply to either you or your colleages, only time will tell.



                  If you want to be the one steering the ship, you must first be in a position to do so. But if you're unable to deal with things not going your way, I'm apprehensive about your compatibility in a leadership role, as it entails much more compromise than outsiders seem to think it does.




                  I find that this severely impacts my mental state (either by making me feel less motivated, agitated, angry/frustrated, or what have you), and I'd like a solution.




                  The short answer, in the words of Disney's Frozen, let it go. That's easier said than done, but it will boil down to this.



                  Look inwards and ask yourself why you care so much that you're willing to die on this particular hill. Is it because you only want to do things your way? It is because you are unwilling to learn a different way of doing things? Is it because you have a different appraoch to developing and abhor the alternative?



                  How can you be sure that you are objectively more correct than the others? If you are, then why did you not used that irrefutible evidence to make your case before the vote?



                  Never lose sight of the big picture: you're an employee of the company, and you're there to do the work the company tells you to do (within the boundaries defined in your contract). You don't get to decide which work you get to do.



                  Let it go, and accept that when someone else overrides your decision, the consequences of that decision fall on them. You are not personally responsible for the company's wellbeing against the company's own wishes.




                  I strongly disagreed with the chosen outcome, which was settled based on majority (we're a team of 3 co-founders), and so I'm not sure how to reconcile the feeling of having to do work to support a path I don't agree with.




                  First of all: you agreed to a vote, you partook in a vote, and now that the decision hasn't gone your way, you're wanting to pipe up about it. At first glance, I would consider whether you're being a sore loser here.



                  The fact that a vote needed to take place suggests that the decision was not unanimous, which inherently means that someone was always going to "lose". This time, it is you. So you have two options: you accept the outcome, or you don't.



                  Imagine if everyone who didn't get their way did not accept anything other than what they wanted. How much progress do you think you'd make if the other two developers blocked you every time one of them did not agree?

                  As a real world example, imagine if everyone in a democracy had veto power over everyone else, and you could only get things done when every citizen unanimously agrees. Nothing would ever get done.



                  If you do make a fuss, and let's say you even manage to get your way eventually, you will be known as a sore loser and unwilling to work in a team or compromise. All of these observations will be much more detrimental to your career than the minor benefit of being right.






                  share|improve this answer
















                  how do you deal with this conflict once it has been decided that this is something that must go ahead, if you feel strongly against the change?




                  My way of dealing with this is considering what my role in the company is. Am I there as a developer? As an analyst? As a team lead? As a project manager?



                  If I'm the developer (which I surmise you are), then you never had "decision making power" to begin with. You simply had some decision making privilege that was extended to you because someone (with actual power) chose to follow your decision.



                  Edit: you mention the three of you are co-founders, but the answer remains the same. You don't have any power, only a majority of you wields any power. In this case, you are not part of the majority.



                  If you're not holding the wheel, you're not steering the ship and thus cannot override the decision that is made by whoever is holding the wheel. You can ask them (which you did), but they can ignore/deny/disagree with your request. Not your circus, not your monkeys.



                  You informatively raised a concern, it was ignored. Accept the outcome and follow the plan as agreed upon. You and your two colleagues are there as a team, not as a darwinian competition.
                  Even if you were right, the other two developers clearly did not think so and will have to make the mistake before they realize it was a mistake. Everyone does what they consider to be the best thing, until they understand that it's not actually the best thing. In some cases, that means having to learn the hard way. This can apply to either you or your colleages, only time will tell.



                  If you want to be the one steering the ship, you must first be in a position to do so. But if you're unable to deal with things not going your way, I'm apprehensive about your compatibility in a leadership role, as it entails much more compromise than outsiders seem to think it does.




                  I find that this severely impacts my mental state (either by making me feel less motivated, agitated, angry/frustrated, or what have you), and I'd like a solution.




                  The short answer, in the words of Disney's Frozen, let it go. That's easier said than done, but it will boil down to this.



                  Look inwards and ask yourself why you care so much that you're willing to die on this particular hill. Is it because you only want to do things your way? It is because you are unwilling to learn a different way of doing things? Is it because you have a different appraoch to developing and abhor the alternative?



                  How can you be sure that you are objectively more correct than the others? If you are, then why did you not used that irrefutible evidence to make your case before the vote?



                  Never lose sight of the big picture: you're an employee of the company, and you're there to do the work the company tells you to do (within the boundaries defined in your contract). You don't get to decide which work you get to do.



                  Let it go, and accept that when someone else overrides your decision, the consequences of that decision fall on them. You are not personally responsible for the company's wellbeing against the company's own wishes.




                  I strongly disagreed with the chosen outcome, which was settled based on majority (we're a team of 3 co-founders), and so I'm not sure how to reconcile the feeling of having to do work to support a path I don't agree with.




                  First of all: you agreed to a vote, you partook in a vote, and now that the decision hasn't gone your way, you're wanting to pipe up about it. At first glance, I would consider whether you're being a sore loser here.



                  The fact that a vote needed to take place suggests that the decision was not unanimous, which inherently means that someone was always going to "lose". This time, it is you. So you have two options: you accept the outcome, or you don't.



                  Imagine if everyone who didn't get their way did not accept anything other than what they wanted. How much progress do you think you'd make if the other two developers blocked you every time one of them did not agree?

                  As a real world example, imagine if everyone in a democracy had veto power over everyone else, and you could only get things done when every citizen unanimously agrees. Nothing would ever get done.



                  If you do make a fuss, and let's say you even manage to get your way eventually, you will be known as a sore loser and unwilling to work in a team or compromise. All of these observations will be much more detrimental to your career than the minor benefit of being right.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Mar 25 at 16:46

























                  answered Mar 25 at 13:29









                  FlaterFlater

                  3,22111218




                  3,22111218







                  • 2





                    "Never lose sight of the big picture: you're an employee of the company" - I find this the easiest thing to forget sometimes. If you tie your personal identity to the company it can make you feel that the company failing is you failing. In reality, you are a separate human, who is simply paid to do a job - if the company fails or releases bad products, it does not mean you failed. Your personal value != the value of the company.

                    – Bilkokuya
                    Mar 26 at 13:19












                  • @Bilkokuya: With the right mindset, the company making a bad decision that leads to a buggy product can be a form of job security. That's how I try to look at it when I hit a wall when trying to proactively (and pre-emptively) trying to improve things.

                    – Flater
                    Mar 26 at 14:53












                  • @Flater To some degree. At some point, the company is gone, the job is gone.

                    – gnasher729
                    Mar 31 at 19:42












                  • 2





                    "Never lose sight of the big picture: you're an employee of the company" - I find this the easiest thing to forget sometimes. If you tie your personal identity to the company it can make you feel that the company failing is you failing. In reality, you are a separate human, who is simply paid to do a job - if the company fails or releases bad products, it does not mean you failed. Your personal value != the value of the company.

                    – Bilkokuya
                    Mar 26 at 13:19












                  • @Bilkokuya: With the right mindset, the company making a bad decision that leads to a buggy product can be a form of job security. That's how I try to look at it when I hit a wall when trying to proactively (and pre-emptively) trying to improve things.

                    – Flater
                    Mar 26 at 14:53












                  • @Flater To some degree. At some point, the company is gone, the job is gone.

                    – gnasher729
                    Mar 31 at 19:42







                  2




                  2





                  "Never lose sight of the big picture: you're an employee of the company" - I find this the easiest thing to forget sometimes. If you tie your personal identity to the company it can make you feel that the company failing is you failing. In reality, you are a separate human, who is simply paid to do a job - if the company fails or releases bad products, it does not mean you failed. Your personal value != the value of the company.

                  – Bilkokuya
                  Mar 26 at 13:19






                  "Never lose sight of the big picture: you're an employee of the company" - I find this the easiest thing to forget sometimes. If you tie your personal identity to the company it can make you feel that the company failing is you failing. In reality, you are a separate human, who is simply paid to do a job - if the company fails or releases bad products, it does not mean you failed. Your personal value != the value of the company.

                  – Bilkokuya
                  Mar 26 at 13:19














                  @Bilkokuya: With the right mindset, the company making a bad decision that leads to a buggy product can be a form of job security. That's how I try to look at it when I hit a wall when trying to proactively (and pre-emptively) trying to improve things.

                  – Flater
                  Mar 26 at 14:53






                  @Bilkokuya: With the right mindset, the company making a bad decision that leads to a buggy product can be a form of job security. That's how I try to look at it when I hit a wall when trying to proactively (and pre-emptively) trying to improve things.

                  – Flater
                  Mar 26 at 14:53














                  @Flater To some degree. At some point, the company is gone, the job is gone.

                  – gnasher729
                  Mar 31 at 19:42





                  @Flater To some degree. At some point, the company is gone, the job is gone.

                  – gnasher729
                  Mar 31 at 19:42













                  34














                  You've expressed your idea clearly and they decided they did not want to accept your decision and this bothers you. Well of course it bothers you. You've made an excellent case for a particular technology to be used and they flat out denied it.



                  Though remember that politics are always at play, and you cannot understand all the underlying reasons behind any given decision. Even if this were not the case, you should always keep in mind that it isn't a direct attack on you, nor is it saying that you are incapable of making good choices in this matter.



                  As a programmer myself, you learn to go with the flow and respect the decisions of your colleagues, even if you disagree. Fight the battles that deserve fighting for, when you think that it would be a seriously bad choice otherwise. Being a team player is every bit as important as making the right technical choices, and you should learn to trust in your colleagues just as they should learn to trust in you.



                  However, this only addresses the inward issue. If you feel that a mistake is being made, then the proper approach is to make it clear first and foremost to your colleagues, and should they not agree, with your boss directly. It need not be a personal vendetta, but rather something you're making clear. After this point, you cannot be held accountable for potential problems which may result from this (though they can still ask you to fix it).



                  TL;DR - Try to pick your battles, but not at the expense of trust from your fellow colleagues. If you absolutely must object to a decision, simply make it clear, and then continue to be a team player.



                  Edit: In light of your edited question, then I suppose not much can be done. If perhaps you are the expert in this regard, then you could put in an argument that in such matters, you should be given full control (but strictly for technical issues such as this). Though if I understand you correctly, that isn't the case.



                  So the next best thing is trying to make their proposed solution work as best as possible. While it can't be your idea, at least you can make it work well, and there is some small satisfaction in this. It would be ill-advised to sabotage the idea to prove your solution correct. Ultimately, they are co-founders, and so you must respect their decision just as they must respect yours should you and another co-founder agree on something which the third does not.






                  share|improve this answer




















                  • 8





                    Good answer. I will just say, sometimes it's not even "politics", but just non-technical things. There can be time pressures, money pressures, patents, sensitive clients, etc. A whole stack of reasons that a manager may not mention to a programmer, but is important anyway.

                    – Gregory Currie
                    Mar 25 at 12:23











                  • @Neil Appreciate your answer, thank you very much. Just to clarify, this is a project with myself and two other co-founders, so I'm not answering to management here. I've also added a bit of further clarification as a reply to a comment in my original post if you care to read more on the circumstances.

                    – jrichie911
                    Mar 25 at 13:24












                  • @jrichie911 I expanded on my answer. I hope that answers your question.

                    – Neil
                    Mar 25 at 13:41











                  • @Neil thank you very much.

                    – jrichie911
                    Mar 25 at 14:33






                  • 1





                    @jrichie911 the fact there is no manager above does not invalidate this answer at all. I would even say it's more on the spot than the accepted one. You may consider why your suggestions were discarded to do better in the future. Maybe there was a flaw in your assumptions? Maybe you weren't clear enough? Maybe the two colleagues have better bonds and you're treated as some sort of an outsider now?

                    – Ister
                    Mar 27 at 11:54















                  34














                  You've expressed your idea clearly and they decided they did not want to accept your decision and this bothers you. Well of course it bothers you. You've made an excellent case for a particular technology to be used and they flat out denied it.



                  Though remember that politics are always at play, and you cannot understand all the underlying reasons behind any given decision. Even if this were not the case, you should always keep in mind that it isn't a direct attack on you, nor is it saying that you are incapable of making good choices in this matter.



                  As a programmer myself, you learn to go with the flow and respect the decisions of your colleagues, even if you disagree. Fight the battles that deserve fighting for, when you think that it would be a seriously bad choice otherwise. Being a team player is every bit as important as making the right technical choices, and you should learn to trust in your colleagues just as they should learn to trust in you.



                  However, this only addresses the inward issue. If you feel that a mistake is being made, then the proper approach is to make it clear first and foremost to your colleagues, and should they not agree, with your boss directly. It need not be a personal vendetta, but rather something you're making clear. After this point, you cannot be held accountable for potential problems which may result from this (though they can still ask you to fix it).



                  TL;DR - Try to pick your battles, but not at the expense of trust from your fellow colleagues. If you absolutely must object to a decision, simply make it clear, and then continue to be a team player.



                  Edit: In light of your edited question, then I suppose not much can be done. If perhaps you are the expert in this regard, then you could put in an argument that in such matters, you should be given full control (but strictly for technical issues such as this). Though if I understand you correctly, that isn't the case.



                  So the next best thing is trying to make their proposed solution work as best as possible. While it can't be your idea, at least you can make it work well, and there is some small satisfaction in this. It would be ill-advised to sabotage the idea to prove your solution correct. Ultimately, they are co-founders, and so you must respect their decision just as they must respect yours should you and another co-founder agree on something which the third does not.






                  share|improve this answer




















                  • 8





                    Good answer. I will just say, sometimes it's not even "politics", but just non-technical things. There can be time pressures, money pressures, patents, sensitive clients, etc. A whole stack of reasons that a manager may not mention to a programmer, but is important anyway.

                    – Gregory Currie
                    Mar 25 at 12:23











                  • @Neil Appreciate your answer, thank you very much. Just to clarify, this is a project with myself and two other co-founders, so I'm not answering to management here. I've also added a bit of further clarification as a reply to a comment in my original post if you care to read more on the circumstances.

                    – jrichie911
                    Mar 25 at 13:24












                  • @jrichie911 I expanded on my answer. I hope that answers your question.

                    – Neil
                    Mar 25 at 13:41











                  • @Neil thank you very much.

                    – jrichie911
                    Mar 25 at 14:33






                  • 1





                    @jrichie911 the fact there is no manager above does not invalidate this answer at all. I would even say it's more on the spot than the accepted one. You may consider why your suggestions were discarded to do better in the future. Maybe there was a flaw in your assumptions? Maybe you weren't clear enough? Maybe the two colleagues have better bonds and you're treated as some sort of an outsider now?

                    – Ister
                    Mar 27 at 11:54













                  34












                  34








                  34







                  You've expressed your idea clearly and they decided they did not want to accept your decision and this bothers you. Well of course it bothers you. You've made an excellent case for a particular technology to be used and they flat out denied it.



                  Though remember that politics are always at play, and you cannot understand all the underlying reasons behind any given decision. Even if this were not the case, you should always keep in mind that it isn't a direct attack on you, nor is it saying that you are incapable of making good choices in this matter.



                  As a programmer myself, you learn to go with the flow and respect the decisions of your colleagues, even if you disagree. Fight the battles that deserve fighting for, when you think that it would be a seriously bad choice otherwise. Being a team player is every bit as important as making the right technical choices, and you should learn to trust in your colleagues just as they should learn to trust in you.



                  However, this only addresses the inward issue. If you feel that a mistake is being made, then the proper approach is to make it clear first and foremost to your colleagues, and should they not agree, with your boss directly. It need not be a personal vendetta, but rather something you're making clear. After this point, you cannot be held accountable for potential problems which may result from this (though they can still ask you to fix it).



                  TL;DR - Try to pick your battles, but not at the expense of trust from your fellow colleagues. If you absolutely must object to a decision, simply make it clear, and then continue to be a team player.



                  Edit: In light of your edited question, then I suppose not much can be done. If perhaps you are the expert in this regard, then you could put in an argument that in such matters, you should be given full control (but strictly for technical issues such as this). Though if I understand you correctly, that isn't the case.



                  So the next best thing is trying to make their proposed solution work as best as possible. While it can't be your idea, at least you can make it work well, and there is some small satisfaction in this. It would be ill-advised to sabotage the idea to prove your solution correct. Ultimately, they are co-founders, and so you must respect their decision just as they must respect yours should you and another co-founder agree on something which the third does not.






                  share|improve this answer















                  You've expressed your idea clearly and they decided they did not want to accept your decision and this bothers you. Well of course it bothers you. You've made an excellent case for a particular technology to be used and they flat out denied it.



                  Though remember that politics are always at play, and you cannot understand all the underlying reasons behind any given decision. Even if this were not the case, you should always keep in mind that it isn't a direct attack on you, nor is it saying that you are incapable of making good choices in this matter.



                  As a programmer myself, you learn to go with the flow and respect the decisions of your colleagues, even if you disagree. Fight the battles that deserve fighting for, when you think that it would be a seriously bad choice otherwise. Being a team player is every bit as important as making the right technical choices, and you should learn to trust in your colleagues just as they should learn to trust in you.



                  However, this only addresses the inward issue. If you feel that a mistake is being made, then the proper approach is to make it clear first and foremost to your colleagues, and should they not agree, with your boss directly. It need not be a personal vendetta, but rather something you're making clear. After this point, you cannot be held accountable for potential problems which may result from this (though they can still ask you to fix it).



                  TL;DR - Try to pick your battles, but not at the expense of trust from your fellow colleagues. If you absolutely must object to a decision, simply make it clear, and then continue to be a team player.



                  Edit: In light of your edited question, then I suppose not much can be done. If perhaps you are the expert in this regard, then you could put in an argument that in such matters, you should be given full control (but strictly for technical issues such as this). Though if I understand you correctly, that isn't the case.



                  So the next best thing is trying to make their proposed solution work as best as possible. While it can't be your idea, at least you can make it work well, and there is some small satisfaction in this. It would be ill-advised to sabotage the idea to prove your solution correct. Ultimately, they are co-founders, and so you must respect their decision just as they must respect yours should you and another co-founder agree on something which the third does not.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Mar 25 at 19:59









                  gfos

                  1054




                  1054










                  answered Mar 25 at 12:13









                  NeilNeil

                  411117




                  411117







                  • 8





                    Good answer. I will just say, sometimes it's not even "politics", but just non-technical things. There can be time pressures, money pressures, patents, sensitive clients, etc. A whole stack of reasons that a manager may not mention to a programmer, but is important anyway.

                    – Gregory Currie
                    Mar 25 at 12:23











                  • @Neil Appreciate your answer, thank you very much. Just to clarify, this is a project with myself and two other co-founders, so I'm not answering to management here. I've also added a bit of further clarification as a reply to a comment in my original post if you care to read more on the circumstances.

                    – jrichie911
                    Mar 25 at 13:24












                  • @jrichie911 I expanded on my answer. I hope that answers your question.

                    – Neil
                    Mar 25 at 13:41











                  • @Neil thank you very much.

                    – jrichie911
                    Mar 25 at 14:33






                  • 1





                    @jrichie911 the fact there is no manager above does not invalidate this answer at all. I would even say it's more on the spot than the accepted one. You may consider why your suggestions were discarded to do better in the future. Maybe there was a flaw in your assumptions? Maybe you weren't clear enough? Maybe the two colleagues have better bonds and you're treated as some sort of an outsider now?

                    – Ister
                    Mar 27 at 11:54












                  • 8





                    Good answer. I will just say, sometimes it's not even "politics", but just non-technical things. There can be time pressures, money pressures, patents, sensitive clients, etc. A whole stack of reasons that a manager may not mention to a programmer, but is important anyway.

                    – Gregory Currie
                    Mar 25 at 12:23











                  • @Neil Appreciate your answer, thank you very much. Just to clarify, this is a project with myself and two other co-founders, so I'm not answering to management here. I've also added a bit of further clarification as a reply to a comment in my original post if you care to read more on the circumstances.

                    – jrichie911
                    Mar 25 at 13:24












                  • @jrichie911 I expanded on my answer. I hope that answers your question.

                    – Neil
                    Mar 25 at 13:41











                  • @Neil thank you very much.

                    – jrichie911
                    Mar 25 at 14:33






                  • 1





                    @jrichie911 the fact there is no manager above does not invalidate this answer at all. I would even say it's more on the spot than the accepted one. You may consider why your suggestions were discarded to do better in the future. Maybe there was a flaw in your assumptions? Maybe you weren't clear enough? Maybe the two colleagues have better bonds and you're treated as some sort of an outsider now?

                    – Ister
                    Mar 27 at 11:54







                  8




                  8





                  Good answer. I will just say, sometimes it's not even "politics", but just non-technical things. There can be time pressures, money pressures, patents, sensitive clients, etc. A whole stack of reasons that a manager may not mention to a programmer, but is important anyway.

                  – Gregory Currie
                  Mar 25 at 12:23





                  Good answer. I will just say, sometimes it's not even "politics", but just non-technical things. There can be time pressures, money pressures, patents, sensitive clients, etc. A whole stack of reasons that a manager may not mention to a programmer, but is important anyway.

                  – Gregory Currie
                  Mar 25 at 12:23













                  @Neil Appreciate your answer, thank you very much. Just to clarify, this is a project with myself and two other co-founders, so I'm not answering to management here. I've also added a bit of further clarification as a reply to a comment in my original post if you care to read more on the circumstances.

                  – jrichie911
                  Mar 25 at 13:24






                  @Neil Appreciate your answer, thank you very much. Just to clarify, this is a project with myself and two other co-founders, so I'm not answering to management here. I've also added a bit of further clarification as a reply to a comment in my original post if you care to read more on the circumstances.

                  – jrichie911
                  Mar 25 at 13:24














                  @jrichie911 I expanded on my answer. I hope that answers your question.

                  – Neil
                  Mar 25 at 13:41





                  @jrichie911 I expanded on my answer. I hope that answers your question.

                  – Neil
                  Mar 25 at 13:41













                  @Neil thank you very much.

                  – jrichie911
                  Mar 25 at 14:33





                  @Neil thank you very much.

                  – jrichie911
                  Mar 25 at 14:33




                  1




                  1





                  @jrichie911 the fact there is no manager above does not invalidate this answer at all. I would even say it's more on the spot than the accepted one. You may consider why your suggestions were discarded to do better in the future. Maybe there was a flaw in your assumptions? Maybe you weren't clear enough? Maybe the two colleagues have better bonds and you're treated as some sort of an outsider now?

                  – Ister
                  Mar 27 at 11:54





                  @jrichie911 the fact there is no manager above does not invalidate this answer at all. I would even say it's more on the spot than the accepted one. You may consider why your suggestions were discarded to do better in the future. Maybe there was a flaw in your assumptions? Maybe you weren't clear enough? Maybe the two colleagues have better bonds and you're treated as some sort of an outsider now?

                  – Ister
                  Mar 27 at 11:54











                  18














                  It's a completely understandable reaction and a human one.



                  You know you tried to influence the decision making process, you tried your hardest, and things didn't end up as you think they should.



                  What I find with a lot of things is if I understand everybody wants the best outcome, it makes it easier for me. If I can work with a bunch of people who are committed to everyone understanding the pros and cons of each solution, that gives me confidence that on average, the best solution is often decided.



                  Often what it comes down to is a slight disagreement in perceived importance. For instance, one person may think performance is more important than code clarity.



                  You have to remember, the best teams operate when there are disagreements. If you have a team of "yes men" as a team, you are not likely to do great work. So there will often be somebody that's a bit disappointed. But the team not deciding to go down a path doesn't mean everything you said is wasted. Quite often it will stay at the back of people's minds.



                  As you point out, once a course of action is decided, you do have to commit to it. If you have concerns, you should explore how they may be mitigated within the context of the decided solution. But you shouldn't compromise your team.



                  Also, something to keep in mind, often there are a lot of non-technical reasons why the best solution is not followed.



                  You will get used to this, just as I have.






                  share|improve this answer

























                  • Nicely expressed.

                    – Sourav Ghosh
                    Mar 25 at 12:45











                  • "I understand everybody wants the best outcome" - this is the critical part in my opinion.

                    – afaulconbridge
                    Mar 25 at 15:51















                  18














                  It's a completely understandable reaction and a human one.



                  You know you tried to influence the decision making process, you tried your hardest, and things didn't end up as you think they should.



                  What I find with a lot of things is if I understand everybody wants the best outcome, it makes it easier for me. If I can work with a bunch of people who are committed to everyone understanding the pros and cons of each solution, that gives me confidence that on average, the best solution is often decided.



                  Often what it comes down to is a slight disagreement in perceived importance. For instance, one person may think performance is more important than code clarity.



                  You have to remember, the best teams operate when there are disagreements. If you have a team of "yes men" as a team, you are not likely to do great work. So there will often be somebody that's a bit disappointed. But the team not deciding to go down a path doesn't mean everything you said is wasted. Quite often it will stay at the back of people's minds.



                  As you point out, once a course of action is decided, you do have to commit to it. If you have concerns, you should explore how they may be mitigated within the context of the decided solution. But you shouldn't compromise your team.



                  Also, something to keep in mind, often there are a lot of non-technical reasons why the best solution is not followed.



                  You will get used to this, just as I have.






                  share|improve this answer

























                  • Nicely expressed.

                    – Sourav Ghosh
                    Mar 25 at 12:45











                  • "I understand everybody wants the best outcome" - this is the critical part in my opinion.

                    – afaulconbridge
                    Mar 25 at 15:51













                  18












                  18








                  18







                  It's a completely understandable reaction and a human one.



                  You know you tried to influence the decision making process, you tried your hardest, and things didn't end up as you think they should.



                  What I find with a lot of things is if I understand everybody wants the best outcome, it makes it easier for me. If I can work with a bunch of people who are committed to everyone understanding the pros and cons of each solution, that gives me confidence that on average, the best solution is often decided.



                  Often what it comes down to is a slight disagreement in perceived importance. For instance, one person may think performance is more important than code clarity.



                  You have to remember, the best teams operate when there are disagreements. If you have a team of "yes men" as a team, you are not likely to do great work. So there will often be somebody that's a bit disappointed. But the team not deciding to go down a path doesn't mean everything you said is wasted. Quite often it will stay at the back of people's minds.



                  As you point out, once a course of action is decided, you do have to commit to it. If you have concerns, you should explore how they may be mitigated within the context of the decided solution. But you shouldn't compromise your team.



                  Also, something to keep in mind, often there are a lot of non-technical reasons why the best solution is not followed.



                  You will get used to this, just as I have.






                  share|improve this answer















                  It's a completely understandable reaction and a human one.



                  You know you tried to influence the decision making process, you tried your hardest, and things didn't end up as you think they should.



                  What I find with a lot of things is if I understand everybody wants the best outcome, it makes it easier for me. If I can work with a bunch of people who are committed to everyone understanding the pros and cons of each solution, that gives me confidence that on average, the best solution is often decided.



                  Often what it comes down to is a slight disagreement in perceived importance. For instance, one person may think performance is more important than code clarity.



                  You have to remember, the best teams operate when there are disagreements. If you have a team of "yes men" as a team, you are not likely to do great work. So there will often be somebody that's a bit disappointed. But the team not deciding to go down a path doesn't mean everything you said is wasted. Quite often it will stay at the back of people's minds.



                  As you point out, once a course of action is decided, you do have to commit to it. If you have concerns, you should explore how they may be mitigated within the context of the decided solution. But you shouldn't compromise your team.



                  Also, something to keep in mind, often there are a lot of non-technical reasons why the best solution is not followed.



                  You will get used to this, just as I have.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Mar 25 at 12:27

























                  answered Mar 25 at 12:20









                  Gregory CurrieGregory Currie

                  5,70182643




                  5,70182643












                  • Nicely expressed.

                    – Sourav Ghosh
                    Mar 25 at 12:45











                  • "I understand everybody wants the best outcome" - this is the critical part in my opinion.

                    – afaulconbridge
                    Mar 25 at 15:51

















                  • Nicely expressed.

                    – Sourav Ghosh
                    Mar 25 at 12:45











                  • "I understand everybody wants the best outcome" - this is the critical part in my opinion.

                    – afaulconbridge
                    Mar 25 at 15:51
















                  Nicely expressed.

                  – Sourav Ghosh
                  Mar 25 at 12:45





                  Nicely expressed.

                  – Sourav Ghosh
                  Mar 25 at 12:45













                  "I understand everybody wants the best outcome" - this is the critical part in my opinion.

                  – afaulconbridge
                  Mar 25 at 15:51





                  "I understand everybody wants the best outcome" - this is the critical part in my opinion.

                  – afaulconbridge
                  Mar 25 at 15:51











                  9














                  Addressing this solely from the psychological stance asked for, I find there are a few things that help me get over a "bad choice" (in my opinion).



                  The first is simply a little time - if I have to start coding the "wrong thing" immediately, my mind is replaying all of the arguments against this, not trying to see the best way to create it. Usually if I can put it off for a day or two, I've accepted the decision and am more relaxed about it, particularly after sleeping on it (so my brain stops the cycle of "but the reasons against it are x.... y.... etc")



                  Second, there can be a feeling that your opinion wasn't heeded or that you are powerless because you can't change this decision. Going back to the code and doing something else that I do want done (that has been agreed or I have the power to choose) can help me feel back in control and that I am contributing good changes to the code-base.



                  Third, when I do come to designing/coding the required change, I am looking into how to make it work as smoothly as possible ("even if it's wrong we're going to do it well"). Trying to maximize the benefits that were used to make this decision and reduce what I saw as the problems with it helps to get me invested in making this solution work and usually I find I get to the point of "not the best decision, but actually not as bad as I thought".






                  share|improve this answer


















                  • 2





                    +1 First answer I've seen that actually seems to understand the problem the OP is having and addresses it in a way that might be helpful (edit: as much as I don't want to insult the other answers or the genuine helpfulness of the people giving them, OP is dealing with a very acute and uncommon problem of executive function (psychology term) and motivation. Many people seem to not experience this problem the same way, thus lack the mind interferometry skills to pick up on it, and don't know how to help another mind find the consciously controllable cognition needed to overcome the problem.)

                    – mtraceur
                    Mar 25 at 22:28












                  • Fourth, Look forward to your glee when, once the feature is done, everybody else will see how it sucks. Not because you implemented it as badly as possible, but despite you put your best effort into it. Getting it done as quickly as possible will minimize your losses when they finally decide to say you're right and abandon the whole thing, and doing it as well as possible will minimize the "oh, let's change this and that to get it right" cycles. When people insist on shooting themselves in the foot, sometimes you'll have to allow them feel the pain. Petty? yes. But it might help motivate you.

                    – Guntram Blohm
                    Mar 26 at 7:04















                  9














                  Addressing this solely from the psychological stance asked for, I find there are a few things that help me get over a "bad choice" (in my opinion).



                  The first is simply a little time - if I have to start coding the "wrong thing" immediately, my mind is replaying all of the arguments against this, not trying to see the best way to create it. Usually if I can put it off for a day or two, I've accepted the decision and am more relaxed about it, particularly after sleeping on it (so my brain stops the cycle of "but the reasons against it are x.... y.... etc")



                  Second, there can be a feeling that your opinion wasn't heeded or that you are powerless because you can't change this decision. Going back to the code and doing something else that I do want done (that has been agreed or I have the power to choose) can help me feel back in control and that I am contributing good changes to the code-base.



                  Third, when I do come to designing/coding the required change, I am looking into how to make it work as smoothly as possible ("even if it's wrong we're going to do it well"). Trying to maximize the benefits that were used to make this decision and reduce what I saw as the problems with it helps to get me invested in making this solution work and usually I find I get to the point of "not the best decision, but actually not as bad as I thought".






                  share|improve this answer


















                  • 2





                    +1 First answer I've seen that actually seems to understand the problem the OP is having and addresses it in a way that might be helpful (edit: as much as I don't want to insult the other answers or the genuine helpfulness of the people giving them, OP is dealing with a very acute and uncommon problem of executive function (psychology term) and motivation. Many people seem to not experience this problem the same way, thus lack the mind interferometry skills to pick up on it, and don't know how to help another mind find the consciously controllable cognition needed to overcome the problem.)

                    – mtraceur
                    Mar 25 at 22:28












                  • Fourth, Look forward to your glee when, once the feature is done, everybody else will see how it sucks. Not because you implemented it as badly as possible, but despite you put your best effort into it. Getting it done as quickly as possible will minimize your losses when they finally decide to say you're right and abandon the whole thing, and doing it as well as possible will minimize the "oh, let's change this and that to get it right" cycles. When people insist on shooting themselves in the foot, sometimes you'll have to allow them feel the pain. Petty? yes. But it might help motivate you.

                    – Guntram Blohm
                    Mar 26 at 7:04













                  9












                  9








                  9







                  Addressing this solely from the psychological stance asked for, I find there are a few things that help me get over a "bad choice" (in my opinion).



                  The first is simply a little time - if I have to start coding the "wrong thing" immediately, my mind is replaying all of the arguments against this, not trying to see the best way to create it. Usually if I can put it off for a day or two, I've accepted the decision and am more relaxed about it, particularly after sleeping on it (so my brain stops the cycle of "but the reasons against it are x.... y.... etc")



                  Second, there can be a feeling that your opinion wasn't heeded or that you are powerless because you can't change this decision. Going back to the code and doing something else that I do want done (that has been agreed or I have the power to choose) can help me feel back in control and that I am contributing good changes to the code-base.



                  Third, when I do come to designing/coding the required change, I am looking into how to make it work as smoothly as possible ("even if it's wrong we're going to do it well"). Trying to maximize the benefits that were used to make this decision and reduce what I saw as the problems with it helps to get me invested in making this solution work and usually I find I get to the point of "not the best decision, but actually not as bad as I thought".






                  share|improve this answer













                  Addressing this solely from the psychological stance asked for, I find there are a few things that help me get over a "bad choice" (in my opinion).



                  The first is simply a little time - if I have to start coding the "wrong thing" immediately, my mind is replaying all of the arguments against this, not trying to see the best way to create it. Usually if I can put it off for a day or two, I've accepted the decision and am more relaxed about it, particularly after sleeping on it (so my brain stops the cycle of "but the reasons against it are x.... y.... etc")



                  Second, there can be a feeling that your opinion wasn't heeded or that you are powerless because you can't change this decision. Going back to the code and doing something else that I do want done (that has been agreed or I have the power to choose) can help me feel back in control and that I am contributing good changes to the code-base.



                  Third, when I do come to designing/coding the required change, I am looking into how to make it work as smoothly as possible ("even if it's wrong we're going to do it well"). Trying to maximize the benefits that were used to make this decision and reduce what I saw as the problems with it helps to get me invested in making this solution work and usually I find I get to the point of "not the best decision, but actually not as bad as I thought".







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Mar 25 at 17:44









                  DragonelDragonel

                  92159




                  92159







                  • 2





                    +1 First answer I've seen that actually seems to understand the problem the OP is having and addresses it in a way that might be helpful (edit: as much as I don't want to insult the other answers or the genuine helpfulness of the people giving them, OP is dealing with a very acute and uncommon problem of executive function (psychology term) and motivation. Many people seem to not experience this problem the same way, thus lack the mind interferometry skills to pick up on it, and don't know how to help another mind find the consciously controllable cognition needed to overcome the problem.)

                    – mtraceur
                    Mar 25 at 22:28












                  • Fourth, Look forward to your glee when, once the feature is done, everybody else will see how it sucks. Not because you implemented it as badly as possible, but despite you put your best effort into it. Getting it done as quickly as possible will minimize your losses when they finally decide to say you're right and abandon the whole thing, and doing it as well as possible will minimize the "oh, let's change this and that to get it right" cycles. When people insist on shooting themselves in the foot, sometimes you'll have to allow them feel the pain. Petty? yes. But it might help motivate you.

                    – Guntram Blohm
                    Mar 26 at 7:04












                  • 2





                    +1 First answer I've seen that actually seems to understand the problem the OP is having and addresses it in a way that might be helpful (edit: as much as I don't want to insult the other answers or the genuine helpfulness of the people giving them, OP is dealing with a very acute and uncommon problem of executive function (psychology term) and motivation. Many people seem to not experience this problem the same way, thus lack the mind interferometry skills to pick up on it, and don't know how to help another mind find the consciously controllable cognition needed to overcome the problem.)

                    – mtraceur
                    Mar 25 at 22:28












                  • Fourth, Look forward to your glee when, once the feature is done, everybody else will see how it sucks. Not because you implemented it as badly as possible, but despite you put your best effort into it. Getting it done as quickly as possible will minimize your losses when they finally decide to say you're right and abandon the whole thing, and doing it as well as possible will minimize the "oh, let's change this and that to get it right" cycles. When people insist on shooting themselves in the foot, sometimes you'll have to allow them feel the pain. Petty? yes. But it might help motivate you.

                    – Guntram Blohm
                    Mar 26 at 7:04







                  2




                  2





                  +1 First answer I've seen that actually seems to understand the problem the OP is having and addresses it in a way that might be helpful (edit: as much as I don't want to insult the other answers or the genuine helpfulness of the people giving them, OP is dealing with a very acute and uncommon problem of executive function (psychology term) and motivation. Many people seem to not experience this problem the same way, thus lack the mind interferometry skills to pick up on it, and don't know how to help another mind find the consciously controllable cognition needed to overcome the problem.)

                  – mtraceur
                  Mar 25 at 22:28






                  +1 First answer I've seen that actually seems to understand the problem the OP is having and addresses it in a way that might be helpful (edit: as much as I don't want to insult the other answers or the genuine helpfulness of the people giving them, OP is dealing with a very acute and uncommon problem of executive function (psychology term) and motivation. Many people seem to not experience this problem the same way, thus lack the mind interferometry skills to pick up on it, and don't know how to help another mind find the consciously controllable cognition needed to overcome the problem.)

                  – mtraceur
                  Mar 25 at 22:28














                  Fourth, Look forward to your glee when, once the feature is done, everybody else will see how it sucks. Not because you implemented it as badly as possible, but despite you put your best effort into it. Getting it done as quickly as possible will minimize your losses when they finally decide to say you're right and abandon the whole thing, and doing it as well as possible will minimize the "oh, let's change this and that to get it right" cycles. When people insist on shooting themselves in the foot, sometimes you'll have to allow them feel the pain. Petty? yes. But it might help motivate you.

                  – Guntram Blohm
                  Mar 26 at 7:04





                  Fourth, Look forward to your glee when, once the feature is done, everybody else will see how it sucks. Not because you implemented it as badly as possible, but despite you put your best effort into it. Getting it done as quickly as possible will minimize your losses when they finally decide to say you're right and abandon the whole thing, and doing it as well as possible will minimize the "oh, let's change this and that to get it right" cycles. When people insist on shooting themselves in the foot, sometimes you'll have to allow them feel the pain. Petty? yes. But it might help motivate you.

                  – Guntram Blohm
                  Mar 26 at 7:04











                  4














                  Simple concept: "feeling" is not a driver for a change (or lack thereof). It is a fact driven event. Given there are enough facts to support the change, it'll happen, despite you like it or not.



                  You need to learn how to work with a team, and also need to learn, how to adjust yourself with a rejection. Remember this: you don't "own" anything in a team discussion, you are a participant.



                  There are reasons, valid reasons, for any proposal being accepted or turned down. There are ways to showcase your disagreement and providing the proofs, like, having PoCs, SWOT analysis result etc, getting angry or frustrated or agitated is not one of them. At end of the day, not up to you to make the final decision, so let it go.



                  Direct your "anger" or "frustration" towards a positive side: For example,



                  • Do better homework on the topics being discussed next time.

                  • Invest more in finding the downsides of the other proposed solutions, and also present ideas which promise to solve the downsides you have identified. In other words, don't just point out the shortcomings, also find ways to mitigate them.


                  • Do not try to "compete", rather "collaborate". Don't expect everyone to accept what you propose, and at the same time, don't blindly reject everyone else's idea because you have one of your own.



                    Compare, collate and collaborate - that way you may find every idea has some contribution from your own.







                  share|improve this answer





























                    4














                    Simple concept: "feeling" is not a driver for a change (or lack thereof). It is a fact driven event. Given there are enough facts to support the change, it'll happen, despite you like it or not.



                    You need to learn how to work with a team, and also need to learn, how to adjust yourself with a rejection. Remember this: you don't "own" anything in a team discussion, you are a participant.



                    There are reasons, valid reasons, for any proposal being accepted or turned down. There are ways to showcase your disagreement and providing the proofs, like, having PoCs, SWOT analysis result etc, getting angry or frustrated or agitated is not one of them. At end of the day, not up to you to make the final decision, so let it go.



                    Direct your "anger" or "frustration" towards a positive side: For example,



                    • Do better homework on the topics being discussed next time.

                    • Invest more in finding the downsides of the other proposed solutions, and also present ideas which promise to solve the downsides you have identified. In other words, don't just point out the shortcomings, also find ways to mitigate them.


                    • Do not try to "compete", rather "collaborate". Don't expect everyone to accept what you propose, and at the same time, don't blindly reject everyone else's idea because you have one of your own.



                      Compare, collate and collaborate - that way you may find every idea has some contribution from your own.







                    share|improve this answer



























                      4












                      4








                      4







                      Simple concept: "feeling" is not a driver for a change (or lack thereof). It is a fact driven event. Given there are enough facts to support the change, it'll happen, despite you like it or not.



                      You need to learn how to work with a team, and also need to learn, how to adjust yourself with a rejection. Remember this: you don't "own" anything in a team discussion, you are a participant.



                      There are reasons, valid reasons, for any proposal being accepted or turned down. There are ways to showcase your disagreement and providing the proofs, like, having PoCs, SWOT analysis result etc, getting angry or frustrated or agitated is not one of them. At end of the day, not up to you to make the final decision, so let it go.



                      Direct your "anger" or "frustration" towards a positive side: For example,



                      • Do better homework on the topics being discussed next time.

                      • Invest more in finding the downsides of the other proposed solutions, and also present ideas which promise to solve the downsides you have identified. In other words, don't just point out the shortcomings, also find ways to mitigate them.


                      • Do not try to "compete", rather "collaborate". Don't expect everyone to accept what you propose, and at the same time, don't blindly reject everyone else's idea because you have one of your own.



                        Compare, collate and collaborate - that way you may find every idea has some contribution from your own.







                      share|improve this answer















                      Simple concept: "feeling" is not a driver for a change (or lack thereof). It is a fact driven event. Given there are enough facts to support the change, it'll happen, despite you like it or not.



                      You need to learn how to work with a team, and also need to learn, how to adjust yourself with a rejection. Remember this: you don't "own" anything in a team discussion, you are a participant.



                      There are reasons, valid reasons, for any proposal being accepted or turned down. There are ways to showcase your disagreement and providing the proofs, like, having PoCs, SWOT analysis result etc, getting angry or frustrated or agitated is not one of them. At end of the day, not up to you to make the final decision, so let it go.



                      Direct your "anger" or "frustration" towards a positive side: For example,



                      • Do better homework on the topics being discussed next time.

                      • Invest more in finding the downsides of the other proposed solutions, and also present ideas which promise to solve the downsides you have identified. In other words, don't just point out the shortcomings, also find ways to mitigate them.


                      • Do not try to "compete", rather "collaborate". Don't expect everyone to accept what you propose, and at the same time, don't blindly reject everyone else's idea because you have one of your own.



                        Compare, collate and collaborate - that way you may find every idea has some contribution from your own.








                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Mar 25 at 15:23

























                      answered Mar 25 at 12:07









                      Sourav GhoshSourav Ghosh

                      12.1k116276




                      12.1k116276





















                          1














                          Although the other answers provide fair points, let me explore a possibility that seems to me it was not properly considered in some of them.



                          I have 20+ years of experience as a developer and until last year I never had any issue with the outcome of design sessions. Usually, such sessions would end like this:



                          • My solution was accepted verbatim (10%)

                          • My solution had flaws and it was improved by the team or merged with other solution (50%)

                          • There was a better solution from someone else (40%)

                          The accepted design represented an overall view of the team and at least I never had a trouble going forward with it, because I always thought we got a good solution on the end.



                          However, last year I joined a team, composed of people from different backgrounds, that were working together for 6 months beforehand. They had a complete different set of priorities in their thinking, that clashed directly with mine most of the time.



                          For me, their designs were brittle, hardcoded and somewhat inflexible. For them, my proposals were fancy, over-engineered.



                          It was very hard for me to accept, for example, to create a parser engine whose outcome would depend on the name of the json file. I tried to explain to them that we would have more advantages having metadata inside the json instead of simply relying in its name, but the collective decision was that asking the users to create additional fields was unnecessary.



                          Then they decided to create the code without unit tests, instead having integration tests to check everything end-to-end (3 minutes of execution time). And then came several other decisions that I couldn't simply agree with.



                          For almost an year, I tried to reason with them. I applied several suggestions from the agile coaches of the company, asked fellow engineers to evaluate if I was wrong in my assessments, suggested to do spikes to compare solutions with facts not opinions, among other strategies, including taking 3 soft skills courses to see if it would help.



                          With time, some situations arose that showed them the problems in our solutions, and eventually they recognized that some of them would have been avoided with a "fancy" design. But most of the time, I was still the absolute minority in the design sessions.



                          In the end, I asked and changed to another team. that solved the issue for me, but it is not the case here for you.



                          In your case, I would suggest:



                          1. are the decisions so bad that you can't live with them? Can you try to tolerate them to see if time can show the chosen design was not the best one?


                          2. in your relationship with these other founders, can you openly tell them how you feel about this?


                          3. try some soft skills courses, to see if this can enable you to better communicate your ideas


                          4. can you bring somebody else to support you? being only founders, this may be impossible or awkward, but I don't know your environment. a professional coach, for example, may assist/mediate your discussions and help you see the social dynamics happening while you make decisions






                          share|improve this answer























                          • It seems like you clashed at the beginning and it is very hard to recover from that. It is almost always better to learn how and why things are done the way they are because there's usually a historical reason for it. Prior to pushing ideas you should also earn some respect for your skills and knowledge. Once you learn the lay of the land and people 'trust' you, which could take quite a few months then you pick the low hanging fruit with the most bang for the buck which further increases people's trust in you as your impact is noticeable.

                            – Dunk
                            Mar 25 at 21:50







                          • 1





                            Being the newbie telling everyone they are doing it wrong seldom gets you anywhere other than people to begin tuning you out even when you have good ideas to share.

                            – Dunk
                            Mar 25 at 21:52











                          • @Dunk You are right - criticism isn't easily accepted from "outsiders". But teams differ a lot in terms of embracing criticism in general. There aren't many (but they do exist) teams that openly admit that their "historical reasons" were as typical - sometimes in fact identical - as the more recent reasons, i.e. "we were too lazy to fix it" or "it was done by 2 people over a single Sunday evening" or "this decision was just one giant ego trip of our CTO" or "it's a workaround for a problem that doesn't exist anymore".

                            – kubanczyk
                            Mar 26 at 0:38











                          • Hi @Dunk, just to clarify, I was transferred to the team to develop with them a completely new feature, from scratch. I didn't offer criticism on existing implementations, we were talking about the design for a new project. We were reading the requirements, raising questions and proposing solutions. That was when we start diverging. I completely agree with what you said, it is pretty easy to come later and judge previous decisions made by a team, but that was not what I have done here, at least in my view.

                            – Quaestor Lucem
                            Mar 26 at 13:27















                          1














                          Although the other answers provide fair points, let me explore a possibility that seems to me it was not properly considered in some of them.



                          I have 20+ years of experience as a developer and until last year I never had any issue with the outcome of design sessions. Usually, such sessions would end like this:



                          • My solution was accepted verbatim (10%)

                          • My solution had flaws and it was improved by the team or merged with other solution (50%)

                          • There was a better solution from someone else (40%)

                          The accepted design represented an overall view of the team and at least I never had a trouble going forward with it, because I always thought we got a good solution on the end.



                          However, last year I joined a team, composed of people from different backgrounds, that were working together for 6 months beforehand. They had a complete different set of priorities in their thinking, that clashed directly with mine most of the time.



                          For me, their designs were brittle, hardcoded and somewhat inflexible. For them, my proposals were fancy, over-engineered.



                          It was very hard for me to accept, for example, to create a parser engine whose outcome would depend on the name of the json file. I tried to explain to them that we would have more advantages having metadata inside the json instead of simply relying in its name, but the collective decision was that asking the users to create additional fields was unnecessary.



                          Then they decided to create the code without unit tests, instead having integration tests to check everything end-to-end (3 minutes of execution time). And then came several other decisions that I couldn't simply agree with.



                          For almost an year, I tried to reason with them. I applied several suggestions from the agile coaches of the company, asked fellow engineers to evaluate if I was wrong in my assessments, suggested to do spikes to compare solutions with facts not opinions, among other strategies, including taking 3 soft skills courses to see if it would help.



                          With time, some situations arose that showed them the problems in our solutions, and eventually they recognized that some of them would have been avoided with a "fancy" design. But most of the time, I was still the absolute minority in the design sessions.



                          In the end, I asked and changed to another team. that solved the issue for me, but it is not the case here for you.



                          In your case, I would suggest:



                          1. are the decisions so bad that you can't live with them? Can you try to tolerate them to see if time can show the chosen design was not the best one?


                          2. in your relationship with these other founders, can you openly tell them how you feel about this?


                          3. try some soft skills courses, to see if this can enable you to better communicate your ideas


                          4. can you bring somebody else to support you? being only founders, this may be impossible or awkward, but I don't know your environment. a professional coach, for example, may assist/mediate your discussions and help you see the social dynamics happening while you make decisions






                          share|improve this answer























                          • It seems like you clashed at the beginning and it is very hard to recover from that. It is almost always better to learn how and why things are done the way they are because there's usually a historical reason for it. Prior to pushing ideas you should also earn some respect for your skills and knowledge. Once you learn the lay of the land and people 'trust' you, which could take quite a few months then you pick the low hanging fruit with the most bang for the buck which further increases people's trust in you as your impact is noticeable.

                            – Dunk
                            Mar 25 at 21:50







                          • 1





                            Being the newbie telling everyone they are doing it wrong seldom gets you anywhere other than people to begin tuning you out even when you have good ideas to share.

                            – Dunk
                            Mar 25 at 21:52











                          • @Dunk You are right - criticism isn't easily accepted from "outsiders". But teams differ a lot in terms of embracing criticism in general. There aren't many (but they do exist) teams that openly admit that their "historical reasons" were as typical - sometimes in fact identical - as the more recent reasons, i.e. "we were too lazy to fix it" or "it was done by 2 people over a single Sunday evening" or "this decision was just one giant ego trip of our CTO" or "it's a workaround for a problem that doesn't exist anymore".

                            – kubanczyk
                            Mar 26 at 0:38











                          • Hi @Dunk, just to clarify, I was transferred to the team to develop with them a completely new feature, from scratch. I didn't offer criticism on existing implementations, we were talking about the design for a new project. We were reading the requirements, raising questions and proposing solutions. That was when we start diverging. I completely agree with what you said, it is pretty easy to come later and judge previous decisions made by a team, but that was not what I have done here, at least in my view.

                            – Quaestor Lucem
                            Mar 26 at 13:27













                          1












                          1








                          1







                          Although the other answers provide fair points, let me explore a possibility that seems to me it was not properly considered in some of them.



                          I have 20+ years of experience as a developer and until last year I never had any issue with the outcome of design sessions. Usually, such sessions would end like this:



                          • My solution was accepted verbatim (10%)

                          • My solution had flaws and it was improved by the team or merged with other solution (50%)

                          • There was a better solution from someone else (40%)

                          The accepted design represented an overall view of the team and at least I never had a trouble going forward with it, because I always thought we got a good solution on the end.



                          However, last year I joined a team, composed of people from different backgrounds, that were working together for 6 months beforehand. They had a complete different set of priorities in their thinking, that clashed directly with mine most of the time.



                          For me, their designs were brittle, hardcoded and somewhat inflexible. For them, my proposals were fancy, over-engineered.



                          It was very hard for me to accept, for example, to create a parser engine whose outcome would depend on the name of the json file. I tried to explain to them that we would have more advantages having metadata inside the json instead of simply relying in its name, but the collective decision was that asking the users to create additional fields was unnecessary.



                          Then they decided to create the code without unit tests, instead having integration tests to check everything end-to-end (3 minutes of execution time). And then came several other decisions that I couldn't simply agree with.



                          For almost an year, I tried to reason with them. I applied several suggestions from the agile coaches of the company, asked fellow engineers to evaluate if I was wrong in my assessments, suggested to do spikes to compare solutions with facts not opinions, among other strategies, including taking 3 soft skills courses to see if it would help.



                          With time, some situations arose that showed them the problems in our solutions, and eventually they recognized that some of them would have been avoided with a "fancy" design. But most of the time, I was still the absolute minority in the design sessions.



                          In the end, I asked and changed to another team. that solved the issue for me, but it is not the case here for you.



                          In your case, I would suggest:



                          1. are the decisions so bad that you can't live with them? Can you try to tolerate them to see if time can show the chosen design was not the best one?


                          2. in your relationship with these other founders, can you openly tell them how you feel about this?


                          3. try some soft skills courses, to see if this can enable you to better communicate your ideas


                          4. can you bring somebody else to support you? being only founders, this may be impossible or awkward, but I don't know your environment. a professional coach, for example, may assist/mediate your discussions and help you see the social dynamics happening while you make decisions






                          share|improve this answer













                          Although the other answers provide fair points, let me explore a possibility that seems to me it was not properly considered in some of them.



                          I have 20+ years of experience as a developer and until last year I never had any issue with the outcome of design sessions. Usually, such sessions would end like this:



                          • My solution was accepted verbatim (10%)

                          • My solution had flaws and it was improved by the team or merged with other solution (50%)

                          • There was a better solution from someone else (40%)

                          The accepted design represented an overall view of the team and at least I never had a trouble going forward with it, because I always thought we got a good solution on the end.



                          However, last year I joined a team, composed of people from different backgrounds, that were working together for 6 months beforehand. They had a complete different set of priorities in their thinking, that clashed directly with mine most of the time.



                          For me, their designs were brittle, hardcoded and somewhat inflexible. For them, my proposals were fancy, over-engineered.



                          It was very hard for me to accept, for example, to create a parser engine whose outcome would depend on the name of the json file. I tried to explain to them that we would have more advantages having metadata inside the json instead of simply relying in its name, but the collective decision was that asking the users to create additional fields was unnecessary.



                          Then they decided to create the code without unit tests, instead having integration tests to check everything end-to-end (3 minutes of execution time). And then came several other decisions that I couldn't simply agree with.



                          For almost an year, I tried to reason with them. I applied several suggestions from the agile coaches of the company, asked fellow engineers to evaluate if I was wrong in my assessments, suggested to do spikes to compare solutions with facts not opinions, among other strategies, including taking 3 soft skills courses to see if it would help.



                          With time, some situations arose that showed them the problems in our solutions, and eventually they recognized that some of them would have been avoided with a "fancy" design. But most of the time, I was still the absolute minority in the design sessions.



                          In the end, I asked and changed to another team. that solved the issue for me, but it is not the case here for you.



                          In your case, I would suggest:



                          1. are the decisions so bad that you can't live with them? Can you try to tolerate them to see if time can show the chosen design was not the best one?


                          2. in your relationship with these other founders, can you openly tell them how you feel about this?


                          3. try some soft skills courses, to see if this can enable you to better communicate your ideas


                          4. can you bring somebody else to support you? being only founders, this may be impossible or awkward, but I don't know your environment. a professional coach, for example, may assist/mediate your discussions and help you see the social dynamics happening while you make decisions







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Mar 25 at 18:13









                          Quaestor LucemQuaestor Lucem

                          2384




                          2384












                          • It seems like you clashed at the beginning and it is very hard to recover from that. It is almost always better to learn how and why things are done the way they are because there's usually a historical reason for it. Prior to pushing ideas you should also earn some respect for your skills and knowledge. Once you learn the lay of the land and people 'trust' you, which could take quite a few months then you pick the low hanging fruit with the most bang for the buck which further increases people's trust in you as your impact is noticeable.

                            – Dunk
                            Mar 25 at 21:50







                          • 1





                            Being the newbie telling everyone they are doing it wrong seldom gets you anywhere other than people to begin tuning you out even when you have good ideas to share.

                            – Dunk
                            Mar 25 at 21:52











                          • @Dunk You are right - criticism isn't easily accepted from "outsiders". But teams differ a lot in terms of embracing criticism in general. There aren't many (but they do exist) teams that openly admit that their "historical reasons" were as typical - sometimes in fact identical - as the more recent reasons, i.e. "we were too lazy to fix it" or "it was done by 2 people over a single Sunday evening" or "this decision was just one giant ego trip of our CTO" or "it's a workaround for a problem that doesn't exist anymore".

                            – kubanczyk
                            Mar 26 at 0:38











                          • Hi @Dunk, just to clarify, I was transferred to the team to develop with them a completely new feature, from scratch. I didn't offer criticism on existing implementations, we were talking about the design for a new project. We were reading the requirements, raising questions and proposing solutions. That was when we start diverging. I completely agree with what you said, it is pretty easy to come later and judge previous decisions made by a team, but that was not what I have done here, at least in my view.

                            – Quaestor Lucem
                            Mar 26 at 13:27

















                          • It seems like you clashed at the beginning and it is very hard to recover from that. It is almost always better to learn how and why things are done the way they are because there's usually a historical reason for it. Prior to pushing ideas you should also earn some respect for your skills and knowledge. Once you learn the lay of the land and people 'trust' you, which could take quite a few months then you pick the low hanging fruit with the most bang for the buck which further increases people's trust in you as your impact is noticeable.

                            – Dunk
                            Mar 25 at 21:50







                          • 1





                            Being the newbie telling everyone they are doing it wrong seldom gets you anywhere other than people to begin tuning you out even when you have good ideas to share.

                            – Dunk
                            Mar 25 at 21:52











                          • @Dunk You are right - criticism isn't easily accepted from "outsiders". But teams differ a lot in terms of embracing criticism in general. There aren't many (but they do exist) teams that openly admit that their "historical reasons" were as typical - sometimes in fact identical - as the more recent reasons, i.e. "we were too lazy to fix it" or "it was done by 2 people over a single Sunday evening" or "this decision was just one giant ego trip of our CTO" or "it's a workaround for a problem that doesn't exist anymore".

                            – kubanczyk
                            Mar 26 at 0:38











                          • Hi @Dunk, just to clarify, I was transferred to the team to develop with them a completely new feature, from scratch. I didn't offer criticism on existing implementations, we were talking about the design for a new project. We were reading the requirements, raising questions and proposing solutions. That was when we start diverging. I completely agree with what you said, it is pretty easy to come later and judge previous decisions made by a team, but that was not what I have done here, at least in my view.

                            – Quaestor Lucem
                            Mar 26 at 13:27
















                          It seems like you clashed at the beginning and it is very hard to recover from that. It is almost always better to learn how and why things are done the way they are because there's usually a historical reason for it. Prior to pushing ideas you should also earn some respect for your skills and knowledge. Once you learn the lay of the land and people 'trust' you, which could take quite a few months then you pick the low hanging fruit with the most bang for the buck which further increases people's trust in you as your impact is noticeable.

                          – Dunk
                          Mar 25 at 21:50






                          It seems like you clashed at the beginning and it is very hard to recover from that. It is almost always better to learn how and why things are done the way they are because there's usually a historical reason for it. Prior to pushing ideas you should also earn some respect for your skills and knowledge. Once you learn the lay of the land and people 'trust' you, which could take quite a few months then you pick the low hanging fruit with the most bang for the buck which further increases people's trust in you as your impact is noticeable.

                          – Dunk
                          Mar 25 at 21:50





                          1




                          1





                          Being the newbie telling everyone they are doing it wrong seldom gets you anywhere other than people to begin tuning you out even when you have good ideas to share.

                          – Dunk
                          Mar 25 at 21:52





                          Being the newbie telling everyone they are doing it wrong seldom gets you anywhere other than people to begin tuning you out even when you have good ideas to share.

                          – Dunk
                          Mar 25 at 21:52













                          @Dunk You are right - criticism isn't easily accepted from "outsiders". But teams differ a lot in terms of embracing criticism in general. There aren't many (but they do exist) teams that openly admit that their "historical reasons" were as typical - sometimes in fact identical - as the more recent reasons, i.e. "we were too lazy to fix it" or "it was done by 2 people over a single Sunday evening" or "this decision was just one giant ego trip of our CTO" or "it's a workaround for a problem that doesn't exist anymore".

                          – kubanczyk
                          Mar 26 at 0:38





                          @Dunk You are right - criticism isn't easily accepted from "outsiders". But teams differ a lot in terms of embracing criticism in general. There aren't many (but they do exist) teams that openly admit that their "historical reasons" were as typical - sometimes in fact identical - as the more recent reasons, i.e. "we were too lazy to fix it" or "it was done by 2 people over a single Sunday evening" or "this decision was just one giant ego trip of our CTO" or "it's a workaround for a problem that doesn't exist anymore".

                          – kubanczyk
                          Mar 26 at 0:38













                          Hi @Dunk, just to clarify, I was transferred to the team to develop with them a completely new feature, from scratch. I didn't offer criticism on existing implementations, we were talking about the design for a new project. We were reading the requirements, raising questions and proposing solutions. That was when we start diverging. I completely agree with what you said, it is pretty easy to come later and judge previous decisions made by a team, but that was not what I have done here, at least in my view.

                          – Quaestor Lucem
                          Mar 26 at 13:27





                          Hi @Dunk, just to clarify, I was transferred to the team to develop with them a completely new feature, from scratch. I didn't offer criticism on existing implementations, we were talking about the design for a new project. We were reading the requirements, raising questions and proposing solutions. That was when we start diverging. I completely agree with what you said, it is pretty easy to come later and judge previous decisions made by a team, but that was not what I have done here, at least in my view.

                          – Quaestor Lucem
                          Mar 26 at 13:27











                          1














                          As others have said, what you're feeling is normal, and understandable.



                          First and foremost, I'd assume good faith from everyone else. Second, I'd ask for more information about people's reasoning. And third, use that information to help you in the future.



                          To elaborate, first and foremost, you have to assume that the other people involved in making the decision are rational, and have reasons for what they're doing. So either you don't understand their reasons, or you disagree with them. So I'd talk to them and get a better idea for why they went with a different option. Why are they prioritizing those concerns over the things you value? I know that as an engineer, it can be very hard to balance technical correctness/best practices versus actually shipping a product.



                          For example, they think that moving logic from the backend to the frontend will make certain things easier to manage, and they want to allow people to make certain changes you think an admin should make, which again seems like it will minimize the amount of management you/the admin needs to do. You probably prioritize other characteristics, or disagree that those changes will minimize the amount of management time.



                          So one thing you could do, going forward, is at least think about changing your metrics for decision to match those of your other cofounders, and/or focus your energy on the areas that you think will maximize whatever characteristics you care about. And be prepared to not "win" all the discussions. Worst case, if everything goes horribly wrong, you can always say "I told you so."






                          share|improve this answer



























                            1














                            As others have said, what you're feeling is normal, and understandable.



                            First and foremost, I'd assume good faith from everyone else. Second, I'd ask for more information about people's reasoning. And third, use that information to help you in the future.



                            To elaborate, first and foremost, you have to assume that the other people involved in making the decision are rational, and have reasons for what they're doing. So either you don't understand their reasons, or you disagree with them. So I'd talk to them and get a better idea for why they went with a different option. Why are they prioritizing those concerns over the things you value? I know that as an engineer, it can be very hard to balance technical correctness/best practices versus actually shipping a product.



                            For example, they think that moving logic from the backend to the frontend will make certain things easier to manage, and they want to allow people to make certain changes you think an admin should make, which again seems like it will minimize the amount of management you/the admin needs to do. You probably prioritize other characteristics, or disagree that those changes will minimize the amount of management time.



                            So one thing you could do, going forward, is at least think about changing your metrics for decision to match those of your other cofounders, and/or focus your energy on the areas that you think will maximize whatever characteristics you care about. And be prepared to not "win" all the discussions. Worst case, if everything goes horribly wrong, you can always say "I told you so."






                            share|improve this answer

























                              1












                              1








                              1







                              As others have said, what you're feeling is normal, and understandable.



                              First and foremost, I'd assume good faith from everyone else. Second, I'd ask for more information about people's reasoning. And third, use that information to help you in the future.



                              To elaborate, first and foremost, you have to assume that the other people involved in making the decision are rational, and have reasons for what they're doing. So either you don't understand their reasons, or you disagree with them. So I'd talk to them and get a better idea for why they went with a different option. Why are they prioritizing those concerns over the things you value? I know that as an engineer, it can be very hard to balance technical correctness/best practices versus actually shipping a product.



                              For example, they think that moving logic from the backend to the frontend will make certain things easier to manage, and they want to allow people to make certain changes you think an admin should make, which again seems like it will minimize the amount of management you/the admin needs to do. You probably prioritize other characteristics, or disagree that those changes will minimize the amount of management time.



                              So one thing you could do, going forward, is at least think about changing your metrics for decision to match those of your other cofounders, and/or focus your energy on the areas that you think will maximize whatever characteristics you care about. And be prepared to not "win" all the discussions. Worst case, if everything goes horribly wrong, you can always say "I told you so."






                              share|improve this answer













                              As others have said, what you're feeling is normal, and understandable.



                              First and foremost, I'd assume good faith from everyone else. Second, I'd ask for more information about people's reasoning. And third, use that information to help you in the future.



                              To elaborate, first and foremost, you have to assume that the other people involved in making the decision are rational, and have reasons for what they're doing. So either you don't understand their reasons, or you disagree with them. So I'd talk to them and get a better idea for why they went with a different option. Why are they prioritizing those concerns over the things you value? I know that as an engineer, it can be very hard to balance technical correctness/best practices versus actually shipping a product.



                              For example, they think that moving logic from the backend to the frontend will make certain things easier to manage, and they want to allow people to make certain changes you think an admin should make, which again seems like it will minimize the amount of management you/the admin needs to do. You probably prioritize other characteristics, or disagree that those changes will minimize the amount of management time.



                              So one thing you could do, going forward, is at least think about changing your metrics for decision to match those of your other cofounders, and/or focus your energy on the areas that you think will maximize whatever characteristics you care about. And be prepared to not "win" all the discussions. Worst case, if everything goes horribly wrong, you can always say "I told you so."







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Mar 25 at 20:43









                              Kevin McKenzieKevin McKenzie

                              1257




                              1257





















                                  1














                                  Much of it is about the mindset you enter the meeting with. If you want them to pick your solution and they don't, that's a defeat. And it sucks extra hard because as a co-equal co-founder you now need to slave away for those who defeated you.



                                  Try these to avoid the feeling of defeat:



                                  1. Chose your battles, early.


                                  2. Learn how to convince people.


                                  3. Invest in partial victories.


                                  Chose your battles



                                  Emotional investment, as the word says, is an investment. Invest wisely. You see their approach, it's good enough, and arguing about it costs more than the benefits of your approach? Spend the time improving their approach instead. Oftentimes keeping momentum and focus is far more important than getting things perfect, especially in a startup. But sometimes it isn't. Try to tell the 2 apart, and learn to see benefits where you haven't seen them before.



                                  Learn how to convince people



                                  This is way too long for this format, so to keep it brief: there are management courses for exactly that. It includes not just how to talk, but also how you dress, your body language, and how you listen to people.



                                  Invest in partial victories



                                  You mustn't want people to pick your solution. When you go into strategy meetings, the ideal outcome is that together you come up with a solution that has the potential to be better than the one you had. The minimal outcome must be that they hear and acknowledge your concerns. Your solution isn't what's important. Your concerns about the chosen solution are what's important.






                                  share|improve this answer



























                                    1














                                    Much of it is about the mindset you enter the meeting with. If you want them to pick your solution and they don't, that's a defeat. And it sucks extra hard because as a co-equal co-founder you now need to slave away for those who defeated you.



                                    Try these to avoid the feeling of defeat:



                                    1. Chose your battles, early.


                                    2. Learn how to convince people.


                                    3. Invest in partial victories.


                                    Chose your battles



                                    Emotional investment, as the word says, is an investment. Invest wisely. You see their approach, it's good enough, and arguing about it costs more than the benefits of your approach? Spend the time improving their approach instead. Oftentimes keeping momentum and focus is far more important than getting things perfect, especially in a startup. But sometimes it isn't. Try to tell the 2 apart, and learn to see benefits where you haven't seen them before.



                                    Learn how to convince people



                                    This is way too long for this format, so to keep it brief: there are management courses for exactly that. It includes not just how to talk, but also how you dress, your body language, and how you listen to people.



                                    Invest in partial victories



                                    You mustn't want people to pick your solution. When you go into strategy meetings, the ideal outcome is that together you come up with a solution that has the potential to be better than the one you had. The minimal outcome must be that they hear and acknowledge your concerns. Your solution isn't what's important. Your concerns about the chosen solution are what's important.






                                    share|improve this answer

























                                      1












                                      1








                                      1







                                      Much of it is about the mindset you enter the meeting with. If you want them to pick your solution and they don't, that's a defeat. And it sucks extra hard because as a co-equal co-founder you now need to slave away for those who defeated you.



                                      Try these to avoid the feeling of defeat:



                                      1. Chose your battles, early.


                                      2. Learn how to convince people.


                                      3. Invest in partial victories.


                                      Chose your battles



                                      Emotional investment, as the word says, is an investment. Invest wisely. You see their approach, it's good enough, and arguing about it costs more than the benefits of your approach? Spend the time improving their approach instead. Oftentimes keeping momentum and focus is far more important than getting things perfect, especially in a startup. But sometimes it isn't. Try to tell the 2 apart, and learn to see benefits where you haven't seen them before.



                                      Learn how to convince people



                                      This is way too long for this format, so to keep it brief: there are management courses for exactly that. It includes not just how to talk, but also how you dress, your body language, and how you listen to people.



                                      Invest in partial victories



                                      You mustn't want people to pick your solution. When you go into strategy meetings, the ideal outcome is that together you come up with a solution that has the potential to be better than the one you had. The minimal outcome must be that they hear and acknowledge your concerns. Your solution isn't what's important. Your concerns about the chosen solution are what's important.






                                      share|improve this answer













                                      Much of it is about the mindset you enter the meeting with. If you want them to pick your solution and they don't, that's a defeat. And it sucks extra hard because as a co-equal co-founder you now need to slave away for those who defeated you.



                                      Try these to avoid the feeling of defeat:



                                      1. Chose your battles, early.


                                      2. Learn how to convince people.


                                      3. Invest in partial victories.


                                      Chose your battles



                                      Emotional investment, as the word says, is an investment. Invest wisely. You see their approach, it's good enough, and arguing about it costs more than the benefits of your approach? Spend the time improving their approach instead. Oftentimes keeping momentum and focus is far more important than getting things perfect, especially in a startup. But sometimes it isn't. Try to tell the 2 apart, and learn to see benefits where you haven't seen them before.



                                      Learn how to convince people



                                      This is way too long for this format, so to keep it brief: there are management courses for exactly that. It includes not just how to talk, but also how you dress, your body language, and how you listen to people.



                                      Invest in partial victories



                                      You mustn't want people to pick your solution. When you go into strategy meetings, the ideal outcome is that together you come up with a solution that has the potential to be better than the one you had. The minimal outcome must be that they hear and acknowledge your concerns. Your solution isn't what's important. Your concerns about the chosen solution are what's important.







                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered Mar 26 at 18:06









                                      PeterPeter

                                      12.1k22244




                                      12.1k22244





















                                          0














                                          Just talking generally, I think there's two basic things to consider here:



                                          1. The responsibility of the leader/manager/boss/person with authority. It is, at least partially, the job of a leader to make sure their employees are in a good mental condition and stay motivated; if you repeatedly feel slighted, I suggest you try to communicate. This shouldn't affect the end decisions, but it may affect your ability to accept them; it might also cause change in the behavior of your colleagues, maybe change the way they present their ideas, or the way they respond to yours.

                                          2. The responsibility of you as a professional. You should realize (not just consciously, but on an emotional level) that sometimes you might not be right, or you may not have all the information; it is entirely possible your idea was wrong, maybe not for you personally, but for the project/team/company as a whole. Of course, it's also possible you were right; in that case, keep in mind that you presented your idea and got it rejected; at that point, the responsibility doesn't lie with you. If your colleagues keep making decisions that turn out to be wrong, that might be a sign you might want someone else (potentially you) calling the shots, at least in certain fields; but if that's not the case, then maybe you're just wrong sometimes.





                                          share|improve this answer



























                                            0














                                            Just talking generally, I think there's two basic things to consider here:



                                            1. The responsibility of the leader/manager/boss/person with authority. It is, at least partially, the job of a leader to make sure their employees are in a good mental condition and stay motivated; if you repeatedly feel slighted, I suggest you try to communicate. This shouldn't affect the end decisions, but it may affect your ability to accept them; it might also cause change in the behavior of your colleagues, maybe change the way they present their ideas, or the way they respond to yours.

                                            2. The responsibility of you as a professional. You should realize (not just consciously, but on an emotional level) that sometimes you might not be right, or you may not have all the information; it is entirely possible your idea was wrong, maybe not for you personally, but for the project/team/company as a whole. Of course, it's also possible you were right; in that case, keep in mind that you presented your idea and got it rejected; at that point, the responsibility doesn't lie with you. If your colleagues keep making decisions that turn out to be wrong, that might be a sign you might want someone else (potentially you) calling the shots, at least in certain fields; but if that's not the case, then maybe you're just wrong sometimes.





                                            share|improve this answer

























                                              0












                                              0








                                              0







                                              Just talking generally, I think there's two basic things to consider here:



                                              1. The responsibility of the leader/manager/boss/person with authority. It is, at least partially, the job of a leader to make sure their employees are in a good mental condition and stay motivated; if you repeatedly feel slighted, I suggest you try to communicate. This shouldn't affect the end decisions, but it may affect your ability to accept them; it might also cause change in the behavior of your colleagues, maybe change the way they present their ideas, or the way they respond to yours.

                                              2. The responsibility of you as a professional. You should realize (not just consciously, but on an emotional level) that sometimes you might not be right, or you may not have all the information; it is entirely possible your idea was wrong, maybe not for you personally, but for the project/team/company as a whole. Of course, it's also possible you were right; in that case, keep in mind that you presented your idea and got it rejected; at that point, the responsibility doesn't lie with you. If your colleagues keep making decisions that turn out to be wrong, that might be a sign you might want someone else (potentially you) calling the shots, at least in certain fields; but if that's not the case, then maybe you're just wrong sometimes.





                                              share|improve this answer













                                              Just talking generally, I think there's two basic things to consider here:



                                              1. The responsibility of the leader/manager/boss/person with authority. It is, at least partially, the job of a leader to make sure their employees are in a good mental condition and stay motivated; if you repeatedly feel slighted, I suggest you try to communicate. This shouldn't affect the end decisions, but it may affect your ability to accept them; it might also cause change in the behavior of your colleagues, maybe change the way they present their ideas, or the way they respond to yours.

                                              2. The responsibility of you as a professional. You should realize (not just consciously, but on an emotional level) that sometimes you might not be right, or you may not have all the information; it is entirely possible your idea was wrong, maybe not for you personally, but for the project/team/company as a whole. Of course, it's also possible you were right; in that case, keep in mind that you presented your idea and got it rejected; at that point, the responsibility doesn't lie with you. If your colleagues keep making decisions that turn out to be wrong, that might be a sign you might want someone else (potentially you) calling the shots, at least in certain fields; but if that's not the case, then maybe you're just wrong sometimes.






                                              share|improve this answer












                                              share|improve this answer



                                              share|improve this answer










                                              answered Mar 26 at 5:31









                                              MarconiusMarconius

                                              101




                                              101





















                                                  0














                                                  Having recently encountered this myself, I would highlight you're a team of 3 co-founders, you've been outvoted; and you'd be equally annoyed if it was the other way around where someone was demanding something but had been outvoted.



                                                  Ultimately, you've made your case, and presented the pro's and con's; but if they don't want to listen to your experience then you must walk away with the knowledge that people need to learn from their mistakes. The first is on whatever you were discussing, and the second is to ignore the experience which is why I assume you were brought onto the team... just don't say "I told you so".



                                                  Lastly, your mistake is to get overly stressed by this. The decision has been made, and unless you can bring new evidence or reasoning; then you're unlikely to convince the others to change.






                                                  share|improve this answer



























                                                    0














                                                    Having recently encountered this myself, I would highlight you're a team of 3 co-founders, you've been outvoted; and you'd be equally annoyed if it was the other way around where someone was demanding something but had been outvoted.



                                                    Ultimately, you've made your case, and presented the pro's and con's; but if they don't want to listen to your experience then you must walk away with the knowledge that people need to learn from their mistakes. The first is on whatever you were discussing, and the second is to ignore the experience which is why I assume you were brought onto the team... just don't say "I told you so".



                                                    Lastly, your mistake is to get overly stressed by this. The decision has been made, and unless you can bring new evidence or reasoning; then you're unlikely to convince the others to change.






                                                    share|improve this answer

























                                                      0












                                                      0








                                                      0







                                                      Having recently encountered this myself, I would highlight you're a team of 3 co-founders, you've been outvoted; and you'd be equally annoyed if it was the other way around where someone was demanding something but had been outvoted.



                                                      Ultimately, you've made your case, and presented the pro's and con's; but if they don't want to listen to your experience then you must walk away with the knowledge that people need to learn from their mistakes. The first is on whatever you were discussing, and the second is to ignore the experience which is why I assume you were brought onto the team... just don't say "I told you so".



                                                      Lastly, your mistake is to get overly stressed by this. The decision has been made, and unless you can bring new evidence or reasoning; then you're unlikely to convince the others to change.






                                                      share|improve this answer













                                                      Having recently encountered this myself, I would highlight you're a team of 3 co-founders, you've been outvoted; and you'd be equally annoyed if it was the other way around where someone was demanding something but had been outvoted.



                                                      Ultimately, you've made your case, and presented the pro's and con's; but if they don't want to listen to your experience then you must walk away with the knowledge that people need to learn from their mistakes. The first is on whatever you were discussing, and the second is to ignore the experience which is why I assume you were brought onto the team... just don't say "I told you so".



                                                      Lastly, your mistake is to get overly stressed by this. The decision has been made, and unless you can bring new evidence or reasoning; then you're unlikely to convince the others to change.







                                                      share|improve this answer












                                                      share|improve this answer



                                                      share|improve this answer










                                                      answered Mar 26 at 8:56









                                                      UKMonkeyUKMonkey

                                                      2,820717




                                                      2,820717





















                                                          0














                                                          I would like to add to the existing answers, that the very excellent book "The Five Dysfunctions of a Team" by Patrick Lencioni has a whole chapter about this, and is a very relaxed read.



                                                          In summary, what the book says is that team dysfunction often happens as a pyramid, which starts as lack of trust between team members (in the sense that they can be trusted that they all share a common goal first and are able to put personal benefits second). Without trust, you can't get creative and constructive 'conflict', and instead you avoid trouble by going quiet, which leads to 'artificial harmony'.



                                                          The next step up in the dysfunctional pyramid is where you're at. If it becomes impossible for you to create constructive 'conflict' and have your ideas discussed on their merit, whatever decision is chosen will leave you feel 'wronged', and like you didn't have a stake in it. In other words, there will be no 'buy-in'. This in turn leads to the next dysfunction, which is, you will not care to keep either yourself or others accountable when things don't go according to plan; you will simply shrug and say "well it was never my idea in the first place".



                                                          So, it appears, you are in a somewhat dysfunctional team, despite presumably best intentions. And, the 'blame' lies with both you and your team (as led by your manager). You, because you failed to conflict creatively to make your points, and instead accepted the resolution without having your concerns adequately addressed, and your manager because they didn't pick up on this.



                                                          In an ideal team, there doesn't have to be a consensus of decision, there only has to be buy-in. In other words, I feel that what you feel is wrong here isn't that people chose the wrong decision per se, but the fact they chose it without listening to your concerns and discussing why they felt they were an appropriate risk etc.



                                                          Going past this point, however, if your views have been discussed adequately and your points addressed and dismissed in a professionally appropriate context of a functional team, then you should accept the outcome, and hold yourself accountable to it as if it was your idea. If you feel the context was not appropriate, raise it with your manager, and state your concerns. Who knows, maybe they'll discuss your concerns with you and either have another meeting with the 'good' points you raised, or manage to convince you that your ideas were heard, and that there were valid reasons to take a different route (which may have been less technical and more business in nature, etc).






                                                          share|improve this answer



























                                                            0














                                                            I would like to add to the existing answers, that the very excellent book "The Five Dysfunctions of a Team" by Patrick Lencioni has a whole chapter about this, and is a very relaxed read.



                                                            In summary, what the book says is that team dysfunction often happens as a pyramid, which starts as lack of trust between team members (in the sense that they can be trusted that they all share a common goal first and are able to put personal benefits second). Without trust, you can't get creative and constructive 'conflict', and instead you avoid trouble by going quiet, which leads to 'artificial harmony'.



                                                            The next step up in the dysfunctional pyramid is where you're at. If it becomes impossible for you to create constructive 'conflict' and have your ideas discussed on their merit, whatever decision is chosen will leave you feel 'wronged', and like you didn't have a stake in it. In other words, there will be no 'buy-in'. This in turn leads to the next dysfunction, which is, you will not care to keep either yourself or others accountable when things don't go according to plan; you will simply shrug and say "well it was never my idea in the first place".



                                                            So, it appears, you are in a somewhat dysfunctional team, despite presumably best intentions. And, the 'blame' lies with both you and your team (as led by your manager). You, because you failed to conflict creatively to make your points, and instead accepted the resolution without having your concerns adequately addressed, and your manager because they didn't pick up on this.



                                                            In an ideal team, there doesn't have to be a consensus of decision, there only has to be buy-in. In other words, I feel that what you feel is wrong here isn't that people chose the wrong decision per se, but the fact they chose it without listening to your concerns and discussing why they felt they were an appropriate risk etc.



                                                            Going past this point, however, if your views have been discussed adequately and your points addressed and dismissed in a professionally appropriate context of a functional team, then you should accept the outcome, and hold yourself accountable to it as if it was your idea. If you feel the context was not appropriate, raise it with your manager, and state your concerns. Who knows, maybe they'll discuss your concerns with you and either have another meeting with the 'good' points you raised, or manage to convince you that your ideas were heard, and that there were valid reasons to take a different route (which may have been less technical and more business in nature, etc).






                                                            share|improve this answer

























                                                              0












                                                              0








                                                              0







                                                              I would like to add to the existing answers, that the very excellent book "The Five Dysfunctions of a Team" by Patrick Lencioni has a whole chapter about this, and is a very relaxed read.



                                                              In summary, what the book says is that team dysfunction often happens as a pyramid, which starts as lack of trust between team members (in the sense that they can be trusted that they all share a common goal first and are able to put personal benefits second). Without trust, you can't get creative and constructive 'conflict', and instead you avoid trouble by going quiet, which leads to 'artificial harmony'.



                                                              The next step up in the dysfunctional pyramid is where you're at. If it becomes impossible for you to create constructive 'conflict' and have your ideas discussed on their merit, whatever decision is chosen will leave you feel 'wronged', and like you didn't have a stake in it. In other words, there will be no 'buy-in'. This in turn leads to the next dysfunction, which is, you will not care to keep either yourself or others accountable when things don't go according to plan; you will simply shrug and say "well it was never my idea in the first place".



                                                              So, it appears, you are in a somewhat dysfunctional team, despite presumably best intentions. And, the 'blame' lies with both you and your team (as led by your manager). You, because you failed to conflict creatively to make your points, and instead accepted the resolution without having your concerns adequately addressed, and your manager because they didn't pick up on this.



                                                              In an ideal team, there doesn't have to be a consensus of decision, there only has to be buy-in. In other words, I feel that what you feel is wrong here isn't that people chose the wrong decision per se, but the fact they chose it without listening to your concerns and discussing why they felt they were an appropriate risk etc.



                                                              Going past this point, however, if your views have been discussed adequately and your points addressed and dismissed in a professionally appropriate context of a functional team, then you should accept the outcome, and hold yourself accountable to it as if it was your idea. If you feel the context was not appropriate, raise it with your manager, and state your concerns. Who knows, maybe they'll discuss your concerns with you and either have another meeting with the 'good' points you raised, or manage to convince you that your ideas were heard, and that there were valid reasons to take a different route (which may have been less technical and more business in nature, etc).






                                                              share|improve this answer













                                                              I would like to add to the existing answers, that the very excellent book "The Five Dysfunctions of a Team" by Patrick Lencioni has a whole chapter about this, and is a very relaxed read.



                                                              In summary, what the book says is that team dysfunction often happens as a pyramid, which starts as lack of trust between team members (in the sense that they can be trusted that they all share a common goal first and are able to put personal benefits second). Without trust, you can't get creative and constructive 'conflict', and instead you avoid trouble by going quiet, which leads to 'artificial harmony'.



                                                              The next step up in the dysfunctional pyramid is where you're at. If it becomes impossible for you to create constructive 'conflict' and have your ideas discussed on their merit, whatever decision is chosen will leave you feel 'wronged', and like you didn't have a stake in it. In other words, there will be no 'buy-in'. This in turn leads to the next dysfunction, which is, you will not care to keep either yourself or others accountable when things don't go according to plan; you will simply shrug and say "well it was never my idea in the first place".



                                                              So, it appears, you are in a somewhat dysfunctional team, despite presumably best intentions. And, the 'blame' lies with both you and your team (as led by your manager). You, because you failed to conflict creatively to make your points, and instead accepted the resolution without having your concerns adequately addressed, and your manager because they didn't pick up on this.



                                                              In an ideal team, there doesn't have to be a consensus of decision, there only has to be buy-in. In other words, I feel that what you feel is wrong here isn't that people chose the wrong decision per se, but the fact they chose it without listening to your concerns and discussing why they felt they were an appropriate risk etc.



                                                              Going past this point, however, if your views have been discussed adequately and your points addressed and dismissed in a professionally appropriate context of a functional team, then you should accept the outcome, and hold yourself accountable to it as if it was your idea. If you feel the context was not appropriate, raise it with your manager, and state your concerns. Who knows, maybe they'll discuss your concerns with you and either have another meeting with the 'good' points you raised, or manage to convince you that your ideas were heard, and that there were valid reasons to take a different route (which may have been less technical and more business in nature, etc).







                                                              share|improve this answer












                                                              share|improve this answer



                                                              share|improve this answer










                                                              answered Mar 26 at 9:00









                                                              Tasos PapastylianouTasos Papastylianou

                                                              23915




                                                              23915





















                                                                  0














                                                                  I would not care about psychological aspects. Use the competence you have to figure out which of the following four happened:



                                                                  • Your proposal is not good and the alternative was better. Nothing horrible.

                                                                  • Unable to find good enough arguments, they finally took the opinion of someone maybe slightly senior to you. This difference in seniority may be tiny and not worth to worry about.

                                                                  • It was something primarily opinion based, like Python vs C#. It may be completely different view in another workplace.

                                                                  • Not less probable than others - they have made the wrong decision. They will pay the price and probably will listen more carefully for you next time.





                                                                  share|improve this answer



























                                                                    0














                                                                    I would not care about psychological aspects. Use the competence you have to figure out which of the following four happened:



                                                                    • Your proposal is not good and the alternative was better. Nothing horrible.

                                                                    • Unable to find good enough arguments, they finally took the opinion of someone maybe slightly senior to you. This difference in seniority may be tiny and not worth to worry about.

                                                                    • It was something primarily opinion based, like Python vs C#. It may be completely different view in another workplace.

                                                                    • Not less probable than others - they have made the wrong decision. They will pay the price and probably will listen more carefully for you next time.





                                                                    share|improve this answer

























                                                                      0












                                                                      0








                                                                      0







                                                                      I would not care about psychological aspects. Use the competence you have to figure out which of the following four happened:



                                                                      • Your proposal is not good and the alternative was better. Nothing horrible.

                                                                      • Unable to find good enough arguments, they finally took the opinion of someone maybe slightly senior to you. This difference in seniority may be tiny and not worth to worry about.

                                                                      • It was something primarily opinion based, like Python vs C#. It may be completely different view in another workplace.

                                                                      • Not less probable than others - they have made the wrong decision. They will pay the price and probably will listen more carefully for you next time.





                                                                      share|improve this answer













                                                                      I would not care about psychological aspects. Use the competence you have to figure out which of the following four happened:



                                                                      • Your proposal is not good and the alternative was better. Nothing horrible.

                                                                      • Unable to find good enough arguments, they finally took the opinion of someone maybe slightly senior to you. This difference in seniority may be tiny and not worth to worry about.

                                                                      • It was something primarily opinion based, like Python vs C#. It may be completely different view in another workplace.

                                                                      • Not less probable than others - they have made the wrong decision. They will pay the price and probably will listen more carefully for you next time.






                                                                      share|improve this answer












                                                                      share|improve this answer



                                                                      share|improve this answer










                                                                      answered Mar 26 at 11:29









                                                                      eeeeee

                                                                      2,05221333




                                                                      2,05221333





















                                                                          0














                                                                          This question has already generated some excellent answers, but i feel one aspect has not been covered yet.



                                                                          When choosing between two possible directions, it is not the pros- and cons but the weights you have assigned them, you are comparing. You colleagues feel the pros of their approach outweight the cons, when compared to your approach. Maybe they are not entirely wrong?



                                                                          Years ago we needed to get a daily data-dump from one db to another. My manager wanted me to implement this by transferring an excel file and reading it into the db.
                                                                          I was livid! This would unnecessarily complicate things, i would be writing code just to deal with excel.



                                                                          His stance was that we needed to be able to check what was transferred in case the numbers didnt look right, or 'if we just needed to check'. I tried to explain there were other other ways, and anyway, running software is like a car: you test it before you take in on the road, you don't open the hood while driving on the highway 'just to check'.
                                                                          He won and i was very very angry.



                                                                          Years later I am much milder. I've seen cases where users found the numbers didn't add up, and being able to have them check intermediate steps is helpful. (still, csv would have been easier)






                                                                          share|improve this answer



























                                                                            0














                                                                            This question has already generated some excellent answers, but i feel one aspect has not been covered yet.



                                                                            When choosing between two possible directions, it is not the pros- and cons but the weights you have assigned them, you are comparing. You colleagues feel the pros of their approach outweight the cons, when compared to your approach. Maybe they are not entirely wrong?



                                                                            Years ago we needed to get a daily data-dump from one db to another. My manager wanted me to implement this by transferring an excel file and reading it into the db.
                                                                            I was livid! This would unnecessarily complicate things, i would be writing code just to deal with excel.



                                                                            His stance was that we needed to be able to check what was transferred in case the numbers didnt look right, or 'if we just needed to check'. I tried to explain there were other other ways, and anyway, running software is like a car: you test it before you take in on the road, you don't open the hood while driving on the highway 'just to check'.
                                                                            He won and i was very very angry.



                                                                            Years later I am much milder. I've seen cases where users found the numbers didn't add up, and being able to have them check intermediate steps is helpful. (still, csv would have been easier)






                                                                            share|improve this answer

























                                                                              0












                                                                              0








                                                                              0







                                                                              This question has already generated some excellent answers, but i feel one aspect has not been covered yet.



                                                                              When choosing between two possible directions, it is not the pros- and cons but the weights you have assigned them, you are comparing. You colleagues feel the pros of their approach outweight the cons, when compared to your approach. Maybe they are not entirely wrong?



                                                                              Years ago we needed to get a daily data-dump from one db to another. My manager wanted me to implement this by transferring an excel file and reading it into the db.
                                                                              I was livid! This would unnecessarily complicate things, i would be writing code just to deal with excel.



                                                                              His stance was that we needed to be able to check what was transferred in case the numbers didnt look right, or 'if we just needed to check'. I tried to explain there were other other ways, and anyway, running software is like a car: you test it before you take in on the road, you don't open the hood while driving on the highway 'just to check'.
                                                                              He won and i was very very angry.



                                                                              Years later I am much milder. I've seen cases where users found the numbers didn't add up, and being able to have them check intermediate steps is helpful. (still, csv would have been easier)






                                                                              share|improve this answer













                                                                              This question has already generated some excellent answers, but i feel one aspect has not been covered yet.



                                                                              When choosing between two possible directions, it is not the pros- and cons but the weights you have assigned them, you are comparing. You colleagues feel the pros of their approach outweight the cons, when compared to your approach. Maybe they are not entirely wrong?



                                                                              Years ago we needed to get a daily data-dump from one db to another. My manager wanted me to implement this by transferring an excel file and reading it into the db.
                                                                              I was livid! This would unnecessarily complicate things, i would be writing code just to deal with excel.



                                                                              His stance was that we needed to be able to check what was transferred in case the numbers didnt look right, or 'if we just needed to check'. I tried to explain there were other other ways, and anyway, running software is like a car: you test it before you take in on the road, you don't open the hood while driving on the highway 'just to check'.
                                                                              He won and i was very very angry.



                                                                              Years later I am much milder. I've seen cases where users found the numbers didn't add up, and being able to have them check intermediate steps is helpful. (still, csv would have been easier)







                                                                              share|improve this answer












                                                                              share|improve this answer



                                                                              share|improve this answer










                                                                              answered Mar 31 at 19:34









                                                                              IvanaIvana

                                                                              316139




                                                                              316139















                                                                                  protected by mcknz Mar 26 at 16:33



                                                                                  Thank you for your interest in this question.
                                                                                  Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                                                                                  Would you like to answer one of these unanswered questions instead?



                                                                                  Popular posts from this blog

                                                                                  Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum

                                                                                  He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

                                                                                  Slayer Innehåll Historia | Stil, komposition och lyrik | Bandets betydelse och framgångar | Sidoprojekt och samarbeten | Kontroverser | Medlemmar | Utmärkelser och nomineringar | Turnéer och festivaler | Diskografi | Referenser | Externa länkar | Navigeringsmenywww.slayer.net”Metal Massacre vol. 1””Metal Massacre vol. 3””Metal Massacre Volume III””Show No Mercy””Haunting the Chapel””Live Undead””Hell Awaits””Reign in Blood””Reign in Blood””Gold & Platinum – Reign in Blood””Golden Gods Awards Winners”originalet”Kerrang! Hall Of Fame””Slayer Looks Back On 37-Year Career In New Video Series: Part Two””South of Heaven””Gold & Platinum – South of Heaven””Seasons in the Abyss””Gold & Platinum - Seasons in the Abyss””Divine Intervention””Divine Intervention - Release group by Slayer””Gold & Platinum - Divine Intervention””Live Intrusion””Undisputed Attitude””Abolish Government/Superficial Love””Release “Slatanic Slaughter: A Tribute to Slayer” by Various Artists””Diabolus in Musica””Soundtrack to the Apocalypse””God Hates Us All””Systematic - Relationships””War at the Warfield””Gold & Platinum - War at the Warfield””Soundtrack to the Apocalypse””Gold & Platinum - Still Reigning””Metallica, Slayer, Iron Mauden Among Winners At Metal Hammer Awards””Eternal Pyre””Eternal Pyre - Slayer release group””Eternal Pyre””Metal Storm Awards 2006””Kerrang! Hall Of Fame””Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Bullet-For My Valentine booed at Metal Hammer Golden Gods Awards””Unholy Aliance””The End Of Slayer?””Slayer: We Could Thrash Out Two More Albums If We're Fast Enough...””'The Unholy Alliance: Chapter III' UK Dates Added”originalet”Megadeth And Slayer To Co-Headline 'Canadian Carnage' Trek”originalet”World Painted Blood””Release “World Painted Blood” by Slayer””Metallica Heading To Cinemas””Slayer, Megadeth To Join Forces For 'European Carnage' Tour - Dec. 18, 2010”originalet”Slayer's Hanneman Contracts Acute Infection; Band To Bring In Guest Guitarist””Cannibal Corpse's Pat O'Brien Will Step In As Slayer's Guest Guitarist”originalet”Slayer’s Jeff Hanneman Dead at 49””Dave Lombardo Says He Made Only $67,000 In 2011 While Touring With Slayer””Slayer: We Do Not Agree With Dave Lombardo's Substance Or Timeline Of Events””Slayer Welcomes Drummer Paul Bostaph Back To The Fold””Slayer Hope to Unveil Never-Before-Heard Jeff Hanneman Material on Next Album””Slayer Debut New Song 'Implode' During Surprise Golden Gods Appearance””Release group Repentless by Slayer””Repentless - Slayer - Credits””Slayer””Metal Storm Awards 2015””Slayer - to release comic book "Repentless #1"””Slayer To Release 'Repentless' 6.66" Vinyl Box Set””BREAKING NEWS: Slayer Announce Farewell Tour””Slayer Recruit Lamb of God, Anthrax, Behemoth + Testament for Final Tour””Slayer lägger ner efter 37 år””Slayer Announces Second North American Leg Of 'Final' Tour””Final World Tour””Slayer Announces Final European Tour With Lamb of God, Anthrax And Obituary””Slayer To Tour Europe With Lamb of God, Anthrax And Obituary””Slayer To Play 'Last French Show Ever' At Next Year's Hellfst””Slayer's Final World Tour Will Extend Into 2019””Death Angel's Rob Cavestany On Slayer's 'Farewell' Tour: 'Some Of Us Could See This Coming'””Testament Has No Plans To Retire Anytime Soon, Says Chuck Billy””Anthrax's Scott Ian On Slayer's 'Farewell' Tour Plans: 'I Was Surprised And I Wasn't Surprised'””Slayer””Slayer's Morbid Schlock””Review/Rock; For Slayer, the Mania Is the Message””Slayer - Biography””Slayer - Reign In Blood”originalet”Dave Lombardo””An exclusive oral history of Slayer”originalet”Exclusive! Interview With Slayer Guitarist Jeff Hanneman”originalet”Thinking Out Loud: Slayer's Kerry King on hair metal, Satan and being polite””Slayer Lyrics””Slayer - Biography””Most influential artists for extreme metal music””Slayer - Reign in Blood””Slayer guitarist Jeff Hanneman dies aged 49””Slatanic Slaughter: A Tribute to Slayer””Gateway to Hell: A Tribute to Slayer””Covered In Blood””Slayer: The Origins of Thrash in San Francisco, CA.””Why They Rule - #6 Slayer”originalet”Guitar World's 100 Greatest Heavy Metal Guitarists Of All Time”originalet”The fans have spoken: Slayer comes out on top in readers' polls”originalet”Tribute to Jeff Hanneman (1964-2013)””Lamb Of God Frontman: We Sound Like A Slayer Rip-Off””BEHEMOTH Frontman Pays Tribute To SLAYER's JEFF HANNEMAN””Slayer, Hatebreed Doing Double Duty On This Year's Ozzfest””System of a Down””Lacuna Coil’s Andrea Ferro Talks Influences, Skateboarding, Band Origins + More””Slayer - Reign in Blood””Into The Lungs of Hell””Slayer rules - en utställning om fans””Slayer and Their Fans Slashed Through a No-Holds-Barred Night at Gas Monkey””Home””Slayer””Gold & Platinum - The Big 4 Live from Sofia, Bulgaria””Exclusive! Interview With Slayer Guitarist Kerry King””2008-02-23: Wiltern, Los Angeles, CA, USA””Slayer's Kerry King To Perform With Megadeth Tonight! - Oct. 21, 2010”originalet”Dave Lombardo - Biography”Slayer Case DismissedArkiveradUltimate Classic Rock: Slayer guitarist Jeff Hanneman dead at 49.”Slayer: "We could never do any thing like Some Kind Of Monster..."””Cannibal Corpse'S Pat O'Brien Will Step In As Slayer'S Guest Guitarist | The Official Slayer Site”originalet”Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Kerrang! Awards 2006 Blog: Kerrang! Hall Of Fame””Kerrang! Awards 2013: Kerrang! Legend”originalet”Metallica, Slayer, Iron Maien Among Winners At Metal Hammer Awards””Metal Hammer Golden Gods Awards””Bullet For My Valentine Booed At Metal Hammer Golden Gods Awards””Metal Storm Awards 2006””Metal Storm Awards 2015””Slayer's Concert History””Slayer - Relationships””Slayer - Releases”Slayers officiella webbplatsSlayer på MusicBrainzOfficiell webbplatsSlayerSlayerr1373445760000 0001 1540 47353068615-5086262726cb13906545x(data)6033143kn20030215029