A while back one of our guys (Let's call him Andy) stroked up a deal with Company A for getting x y data from them, for a set amount of money. (This was before I started working here)

Another previous company (Company B) had offered us a price that was a lot more than Company A they set the deal up with (to get x y data).

The few months down the line now of working on the project, I find out that the deal with Company A only gives us a set amount of data (not all the data we need). Now I should explain to you that I'm a Junior Dev. and I don't understand the whole scope of the business. (so I do feel partly responsible for this).

The problem I have here is that I was under the belief that Company A's data was limited for testing purposes (we have been given a login just for testing), which would make sense as you're not paying for anything when you're testing. (hence the limit).

Thinking about it, I am wondering as to why no-one questioned the massive price differences between Company A vs Company B. (I'm also sure there was a loss in 'translation' when the deal was set up).

I've been working on this for a few months now, and I know my boss will not be happy when I tell him about this on Monday. I also don't want to get Andy in trouble.

How do I go about explaining this to him on Monday?

  • Have you talked to Andy? Does he have any salient information?
    – tomjedrz
    Commented Jan 10, 2015 at 12:41
  • @tomjedrz he has logs of messages with Company A. Commented Jan 10, 2015 at 14:09
  • More abstract: You have a (somehow justified) fear that there is major trouble for your company. Your fear may or may not be justified. If justified, it needs urgent action by your boss. So you tell your boss about your fear, give him any evidence you have, and let her or him handle it. At that point you've done your job.
    – gnasher729
    Commented Sep 29, 2015 at 8:49

4 Answers 4


You are going to have to tell your boss on Monday regardless. Because you have taken the project to a decision fork. Either the projects gets killed, or the project moves forward by getting fuller access to the data from A or B. Either way, the decision is not yours but your boss and your boss's management.

The corrective action is simple:pay up.

  • If the pricing is similar, they might want to go with A because you already wrote the code.
  • If the data formats are identical, then pricing and service are or should be the prime decision factors

Whether they decide to go with A or B, they'll just have to pay more. Unless they'd rather kill the project.

What you can do is tell Andy in advance the news that you are telling the boss, so that you can give Andy the time to prepare. If Andy made a mistake, let him say so in his own way. It's not up to you to make a judgement whether Andy made a mistake anyway. Andy is a big boy: let Andy deal with his own stuff and sort it out with the management on his own. If there are recriminations, you don't want to get involved in them.

As far as your boss's happiness is concerned, happiness like unhappiness is temporary and they come and go - Your boss will get over over the news and over his unhappiness - eventually. Because your boss still has a business to run no matter what your boss and the management decide.

  • The only thing I'd add to this is not to even mention, never mind emphasize, that Andy made a mistake. Present the facts (ie we don't have sufficient data) and let management do their own investigation into why: as a junior dev that's not your concern, but also (and more importantly) not your remit.
    – Jon Story
    Commented Jan 12, 2015 at 14:07

The way to avoid trouble is by not saying that something wrong has been done, but rather by asking your boss about the business reasons behind the deal with Company A that you have some doubts about it (in particular, the limited amount of data and the development-only login).

Then the boss can either alleviate your fears by giving you more insight in the business case underlying the deal (perhaps production accounts with full access are currently being negotiated).
Or the boss can thank you for your information and take whatever action he deems necessary. At this point, it is completely out of your hands, whatever happens.

The key point is that you frame your enquiry as a request to learn more about the business and not as an accusation against anyone.

As noted by @tomjedrz in the comments, it must be explicitly discussed that the dearth of data jeopardizes the success of the project. Don't expect that fact to be obvious to the boss or anyone else.

  • 6
    Could be a reasonable approach, depending on the boss. It must be explicitly discussed that the dearth of data jeopardizes the success of the project. Don't expect that fact to be obvious to the boss or anyone else.
    – tomjedrz
    Commented Jan 10, 2015 at 12:45
  • Tom makes a crucial point that should be added to this answer. Commented Jan 10, 2015 at 15:30

In this case you want a paper trail to protect yourself. The worst that can happen is that you raise the concerns, your concerns are dismissed (and maybe not understood correctly), and a few months down the road when more money has been wasted and the project is killed you are unfairly blamed for not raising the issue.

The second thing you want to do is to help resolve the issue. Your supervisor will need to separate facts from suspicions. Make a few bullet points listing facts, e.g. "Test data is limited", and a list of suspicions "Production data limit seems to be too low for our needs" (this may be fact rather than suspicion). If you feel you have sufficient insight, you can also list solutions (e.g. "Buy data from vendor B", "Buy premium package from vendor A", "Accept such and such limitations and fudge the data this way", but don't list them if you lack sufficient information to make reasonable suggestions.

Then you can address both of the above points by sending a short email to your boss saying that you urgently need to discuss the project because you think the supplied data is inadequate. Append the bullet points of facts and suspicions*, hit send, and go talk to the boss as soon as possible (don't wait for an email response).

*The one thing that certainly does not belong on the list of facts and suspicions is "Andy made a mistake". It doesn't belong there because it's irrelevant to the resolution of the issue.


Have you talked to Andy? You never mentioned his response/thoughts/comments. If you haven't, you should. You may get good information, and you also avoid the appearance of throwing him under the bus.

First ... don't wait. If there is significant risk to the success of the project, it needs to be made known immediately. Seriously .. this should be the first thing you do the next time you are at work. Do not delay. Sitting on bad news is a career-limiting behavior.

Second ... follow the chain of command. Tell your supervisor or the project manager, or both. Be explicit and direct.

Third ... Just state the fact and your conclusions. In this case, the fact is that the data provided is limited, and your conclusion is that this lessens the likelihood of project success. Be prepared to explain why you have reached that conclusion as others may disagree.

Fourth ... don't assign blame, name names, or analyze the previous process. The likelihood that you know everything is small. Don't ask questions in any kind of pejorative or judgmental way. Keep your opinions and characterizations of the deal and those who made the deal to yourself. Watch your tone of voice and demeanor .. you want calm and rational.

Fifth ... if you know solution options, bring them up. If you don't, note as much and indicate that you will find solutions but thought this necessary to bring up ASAP.

Finally ... create a record that you brought this up in case things go sideways. Summarize the discussion in an email to yourself. If you were given any direction, you can send an email confirmation including the background. Or put a note in your calendar about the meeting and outcomes.

Good luck.

  • IME, it's usually safer for your career to pretend you don't see problems than to bring them up. In the real places where I've worked, it seems to me that people would far rather things blew up and have no clue why than experience the unpleasantness in the short term of having someone mention a problem. I have never once experienced a situation where having a record that I did x, y, and z was helpful in this type of situation. Instead, going back to the record is seen as "I told you so." Commented Jan 11, 2015 at 15:06

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