Where I work, we are choosing a new software package to implement. In our line of business, the software we use pretty much determines how our business is going to operate in the future.

I was tasked with choosing the best software package for our use cases and as such selected a cloud-based real-time package, one of the very best on the market. I met with the developers at re:invent and they are extremely dedicated in building their product well.

However, after choosing this product and presenting it to the CEO, she immediately overruled my decision and decided to go with a software package haphazardly written in a hodge-podge of Delphi and .NET simply because our biggest competitor uses it.

How do I tell her that she is making a huge mistake and that my decision is the correct one?

  • 4
    Who else was involved in the research and recommendation? Is there solidarity among everyone involved? Are there any managers involve do who work more closely with the CEO? Or is it just your opinion vs. hers?
    – Kent A.
    May 12, 2016 at 2:24
  • 10
    You might rethink your line of though when you say that my decision is the correct one. The world isn't black and white, it is mostly grey. It might even be possible you are wrong here, don't be so sure that your decision is always the correct one.
    – dirkk
    May 12, 2016 at 9:02
  • 1
    Maybe you can try explaining that mimicking what the competitor is doing will never lead you to having business advantage over them? I think you could formulate it like this: I think using this package will make us more productive than competitor (possible include estimated figures). May 12, 2016 at 10:59
  • you dont tell your ceo thats shes makeing a mistake. Just Argument that this can do better and if she still overrules you. Thats that you cant expect People to act the way you want to even if you are absolutly right. May 12, 2016 at 12:27
  • 4
    How did you present your findings? If I was researching tools I would expect to present a summary of the top options with arguments for and against each along with a final recommendation. Did you evaluate the other application? Did you check to see what it does well? That it's written in delphi and .NET doesn't make it automatically bad.
    – Daenyth
    May 12, 2016 at 12:34

8 Answers 8


Follow it up if you feel strongly enough about it, but be prepared to fail. And always remember you don't get the final word.

Software is just a tool, although you might think one is better than the other for technical reasons, there are plenty of other factors your CEO might be looking at.

Eg,. your CEO might be headhunting there and wants software that people are already familiar with. We have an issue here which is similar, only one accounting package is taught in the University, so while it's not the best, buying a different one creates all sorts of issues from support to end user.

Or it may be something as arbitrary as the words 'cloud based'. I'm old school, I don't even bother looking at anything cloud based in terms of paying money for it. Never mind basing my business on it.

  • 7
    @Kevin This post is pretty much about why the best technical tool is not always the right decision from a business POV. Say you're a company which analysed that the best language to write your program in would be Smalltalk-80. That's great until you start looking for hires and find that it's nigh impossible to hire enough people to handle the workload. This could be pretty analogous to the given situation here. Or what about "cloud based"? This opens up a large can of worms with regards to availability and - more important - legal.
    – Voo
    May 12, 2016 at 8:56
  • 4
    cont. What if your awesome powered drill makes it impossible to sell your software in the european union (this is a real, practical problem that companies face when trying to use the cloud)?
    – Voo
    May 12, 2016 at 8:57
  • 3
    @Kevin The OP nowhere said that the other tool is unworkable, just that it's inferior in his opinion. That's a big and important difference. Hell, clearly it can't be unworkable since the competitor is using it and still in business! Then it becomes a larger business question: Is the loss in productivity worth the possible gains in other areas? The OP can give his assessment of productivity loss, but it's not his job to judge the complete impact of the choice (as I said, the "cloud" part alone could make this a no-go for legal reasons).
    – Voo
    May 12, 2016 at 9:38
  • 3
    @Kevin You really want to inform yourself better if you think that using the cloud doesn't matter. If you handle private data, you are required by EU privacy laws to not transfer this data outside very specific regions. Most available cloud providers cannot give you strong enough guarantees to not violate these laws (there's progress in that area). That's exactly the point: You can be a great engineer, but that doesn't mean you're qualified to judge the legal consequences of your choice - and you shouldn't have to be, that's why companies have lawyers. Same goes for other business aspects.
    – Voo
    May 12, 2016 at 10:05
  • 4
    @kevin nope, that's nitpicking, no way is the OP meaning the same thing
    – Kilisi
    May 12, 2016 at 11:32

It depends a lot on what your relationship with the CEO is like. Do you stop in the corridor for a chat once or twice a week, or is this the first and only time you've spoken directly?

Anyway, I disagree with the answers that say present the facts and make your case. You have already done that. That's what your presentation was. Armed with the results of your investigation, the CEO reached a different conclusion. Since the decision was immediate, I'd guess it's quite likely that the CEO went into that presentation already with an idea of what package she'd prefer to use, thinking, "as long as this investigation doesn't reveal any absolutely fatal problems then I'll go with that". So, there's probably some reason she would prefer to go with "good enough" than with "technically best".

I was tasked with choosing the best software package

Sounds like you were tasked with recommending the best software package. You evidently weren't tasked with choosing which product to use, even if that's what you thought the task was, because that wasn't what you were allowed to do!

The CEO has other priorities than you. For example, she doesn't care whether the app is written in a hodgepodge of Delphi and .NET, or in pure, crystalline, beautiful Haskell. She doesn't care whether she's met the developers or not. She doesn't necessarily want to choose the "best" product technically. Whereas you don't care what your competitor uses.

So if you want to pursue the issue, you should seek to find out what her criteria are for choosing a product. If they are different from the criteria that you used to make your recommendation, then you've learned something about the company's approach to doing business. If they're different from what you were asked to use as your criteria, then you've learned something about what kinds of expertise you're asked to contribute vs. what kind of expertise the CEO prefers to provide for herself. If the CEO's decision still seems wrong even once you know her criteria, then you can ask to present again, addressing the specific deficiencies that you feel she's overlooked.

It's possible that the CEO's criteria are completely misguided. For example, someone might have as a criterion "purchase price must be less than X", overlooking that if the cheap product is hard to use then they'll pay more for it anyway in training and operator errors. Then you'd counter that by quantifying the hidden costs. Or someone might think, "I'm not using anything written in Delphi" and end up overlooking the best product because they rejected it first thing and never assessed it properly. You'd counter that by going through the assessment and showing that Delphi is a red herring (heck, surely part of the point of a cloud service is that they could rewrite it in Delphi any time they like, but this wouldn't affect you). Someone might think, "if it works for our competitor it'll work for us", not knowing that the competitor is preparing to finally dump the rubbish product they've been tied into for years, in favour of a better one.

Arguing that the criteria were wrong is different from arguing which product best meets the criteria, so you need to know the real requirements if you're to do anything other than repeat the opinion that your CEO has already seen you present. The real requirements include more than just use cases.

But the CEO might not want to share the full picture with you -- if that was the plan all along then she'd have delegated the decision, not asked you to present to her for her to decide. If she's left you frustrated that your effort and expertise weren't appreciated then that's a pity, because that probably didn't need to happen, but just because it should have been explicit that you were only assessing one aspect of the decision doesn't mean she's going to change the decision.

Finally accept that the definition of CEO is "person who, if you can't reach agreement in a reasonable amount of time, makes the decision". It's not your job to tell the CEO what to do, it's your job to give the CEO all the relevant information and your expert opinion. And in anything other than a very small company, the CEO can't personally attend to every case of someone disagreeing with them.


You say:

I think that you are making a huge mistake and that my recommendation is the correct one.

You do this politely and you offer to explain why. She may hear your explanation or she may not, she may change her mind or she may not; whatever she does she is answerable to the board and you are answerable to her. When you draw the CEO's paycheque you get to make the CEO's decisions.

  • 4
    The CEO is the one paying the OP - I do what I want when I'm unpaid, when somebody gives me money, I do what they want instead even if its stupid. Its their money.
    – gbjbaanb
    May 12, 2016 at 9:19
  • 1
    @gbjbaanb and when they realize that all they are paying you for is to be an echo chamber they will stop paying you
    – Dale M
    May 12, 2016 at 22:29
  • sure, I'll just go tell my boss I no longer want to work on that boring DB stuff, and that I'll be writing a game at work from now on. He'll keep paying me right?
    – gbjbaanb
    May 13, 2016 at 13:45

If she immediately overruled your decision then it is pretty clear she does not value your input. Why were you tasked with selecting software if she had already decided? Overrule without discussion is really bad.

If it is your objective to convince her that she is making a huge mistake then that is not the correct attitude.

You need to think about managing this decision and your career. You input was just dismissed. Not a good time to convince her she made a huge mistake.

I actually would be more concerned with the process than the outcome. If she wanted software Y she should have told you. If cloud was not an option then she should you told you. She did not just dismiss your recommendation she dismissed you.

I was tasked with selecting a product. Product Y was included in my evaluation and here are features that I found it lacking compared to X (don't call X your decision - the objective is to make X her decision). On the technical side difference are ...

This would be pushing it but

I am frustrated with the process. You tasked me with selecting a software package and then dismissed the recommendation with no discussion. What was the purpose of the task?

If you get push back then you need to shut it down. If she does not value your input on this matter then pressing the issue is not good for you career.


First, are you sure they are making a mistake?

Perhaps you were tasked with evaluating the technical merits of the two solutions - but who was looking at the other aspects?

There could well be compelling business decisions and factors that you are not aware of. Those factors have outweighed your technical recommendation in this case.

Check the cost of the two packages, training, support. Even just the advantage of something more established in the marketplace.

If after evaluating all of those things you still think it is the wrong decision then put together a reasonably short document describing why and then ask for a meeting to discuss it.

Make sure you are non-confrontational. Do not ever say it's a "wrong" decision. Say you have these things that concern you about the choice and you want to discuss them. Go through the reasons and for each one either see if it is a good reason to switch, or if not see what can be done to mitigate it.

Then you come out of the meeting with either a mitigation plan to work with the new software as well as you can - or you come out of it realizing that actually your reasons aren't that compelling - or you have a compelling reason that the CEO has to accept is compelling.

Honestly you're taking a risk doing this though so you had better make very sure that your reasons are compelling. And no, from a business perspective "haphazardly written" is not compelling so long as it works and your developers don't need to support it.

  • Would you buy a "haphazardly built" house if the builder offered support which would fix any defects (in a future release)? Or would you prefer a solidly built house in the first place? If something is "haphazardly written," it has a high chance of bugs, even showstopping ones. How is that not a compelling argument from business perspective? May 12, 2016 at 10:34
  • 1
    @Angew Because if the software is in established use for existing clients then those defects can't be that bad and so its lower risk than newer and potentially more shiny but less proven software that is less likely to have had existing bugs found and fixed.
    – Tim B
    May 12, 2016 at 10:36
  • People buy houses that need work all the time. Plenty of houses here in england have been built, rewired, extended, rewired again. Had a new kitchen, had the bathroom moved, had a loft conversion. People still buy them and there you usually don't even have a builder guarantee ;)
    – Tim B
    May 12, 2016 at 10:37

The best thing you can do is present facts, preferably quantifiable, to support your position. And do it in a way that she can understand your basic argument in one minute or less. Remember that the CEO probably doesn't know or care about technical details, only the business value they bring. For example, in terms of $/£/€, how much will the company gain or lose if they choose one package over the other? Use spreadsheets and PowerPoint slides, and avoid passionate pleas that are based on personal preference or anecdotal evidence.

But in the end, sometimes things will just not be done the way you want. In that case, be content with having provided the best available information so the CEO can make an informed decision, and don't whine when you have to start using the software. Having a good attitude and showing that you can follow instructions even when you disagree with them will build your credibility for the next time you feel you should take a stand on a similar issue.


Understand that you may not now all facts that are important for the decision.

By "Understand", I mean to get the mindset of

Ok, maybe I'm missing something and she's right.

You feel that is improbable.
And that she could tell you what you are missing.

There are possible reasons she can not tell you.
(Like: Owing someone a favour, getting a kickback payment, various reasons based on personal relationships, being extorted.)

Or maybe she has just some implicit assumption that is wrong, but she never mentioned it.

Oh, and - looking at the list above:
There are possible reasons she can not tell you that she can not tell you.

So, accept not to know the whole picture. That is hard. Still try.
If you did that, remind youself that it is not your job to know the whole picture, and relax.


I agree with Steve Jessop, but expanding on it a bit will allow you an opportunity to revisit the decision. Approach it from a professional development perspective. Go to your CEO, apologetically, and tell her that you would like her to explain her decision so that you do not make such a "mistake" in the future. Say that you clearly did not understand the requirements since you chose the best technical solution, but that there were obviously other factors that you had not considered.

Not the answer you're looking for? Browse other questions tagged .