I currently work in IT Compliance / Audit department at my company that operates in the software engineering industry. The company is large and multi - national, with many thousands of employees.

My duties and departmental duties include the enforcement of internal control over IT, internal audits of IT processes, and minor security functions.

I am a junior member of the team. Given the nature of the work, our department is not always welcome/ politically palatable. During my short time here, I have already experience political push - back for a recently completed internal review with findings - inadequate documentation, deviations from change policy...etc). I am sensing tension / un willingness from management in remediating the deficiencies noted.

I would like to maintain a good relationship with peers and management alike without compromising our department's function, acting as an overseer that policies are followed / enforced. I try to be reasonable and rely on evidence when presenting findings, and avoid conflict. A set of norms seem to govern the culture rather than rigid policies.

How can I maintain a good working relationship when the work may be politically unpalatable?

  • Do you set policies or just enforce them? There's a big difference in how you approach it depending on your answer.
    – NotMe
    Commented Oct 22, 2015 at 20:50
  • Establishing policy is the responsibility of management. Our role is to enforce the standards set.
    – Anthony
    Commented Oct 22, 2015 at 23:06

7 Answers 7


First, you have to accept that if you are doing your job well, then your work makes others look bad. That is nature of what you do and you cannot compromise that in order to maintain friendly relationships.

So first accept that you are not ever going to be popular.

However, that doesn't mean you can't be respected.

To do that, first be absolutely sure that you are right when you criticize the practices of others. Every time you are right, you gain credibility. When I worked for an audit agency, we almost lost a political battle on a major multi-million dollar finding due to a rounding error of a couple of cents.

Next, you need to listen to their responses and see if you can find something you can agree with. If you were wrong and they pointed out a valid mitigating factor, then you will be better off to agree and go from there. This doesn't mean change everything due to what they say in response, that is a bad thing. But when they are right and you are wrong, you have to admit it and change the finding. You will get respect because you listened and you admitted to a mistake rather than fighting tooth and nail to avoid admitting a mistake.

If you balance reports by mentioning things that you found that they did correctly, that helps too. Also, you may need to talk to your own boss about whether something is minor enough not to be brought up or when it needs to be brought up. People have more trouble with auditors who find only picky ridiculous things than with auditors who find genuinely major problems. Your organization will have its own standards on what needs to be in the report and what might be communicated informally. Your boss should give you guidance on this. If possible concentrate the most time and effort on major issues.

Now of course, you will always remain cordial and professional when talking to others. But truly you do not want to make friends with people outside your department who you may audit, that is a conflict of interest. If you are friends with Joe and you audit his group and he is the only person who doesn't have many issues, are they going to assume that his friendships is why you were easier on him? Best not to go there or you may end up either destroying your professional credibility or losing a friend.

You also have to develop a thick skin. Yes they are going to disagree and they may even say not so nice things about you. You have to rise above and not respond in kind. You have to understand, they are not mad at you as a person but at your job function. I had to learn this early on when I was a manpower specialist (people don't like being told they need fewer people either!) and it has served me well through the years. If you are in a not popular job, then negative reactions are part of that job and you have to learn to not let them get to you. It becomes almost a badge of pride that you found something major enough that it made them mad.

  • "...you admitted to a mistake rather than fighting tooth and nail...", this ability is so much needed all over the world.
    – r41n
    Commented Jan 4, 2018 at 15:48

Kind of minor but when reporting or discussing call it the findings of the report not your findings. Then they can disagree with the report rather than you directly. You can defend the report - not your opinion.


One of the most important things to remember in the QA/Compliance fields is to remember that you are evaluating someone's work but that you are not trying to evaluate if it is good or could be better but rather if the product meets the requirements. When you report deficiencies report them neutrally, with out judgement or any personal attachment.

When Case A: when I do X, Y should happen: Actual Z happens


Feature X is required to have Y documentation but review was unable to find this documentation

Being a junior it is probably not your responsibility to harangue the developers or management about the status of the bug/audit report rework. When they are complete review the work and mark it corrected or return the report with it noted that the issue still exists. If they decide to go forward with out correcting them that is on the Dev or product manager.

As for how to make friends with the devs, when you are at lunch or just chatting, try to avoid work topics. If the devs want to talk about the requirements being bad just agree with them. Even if you understand why the requirement is there, agree the requirement is bad and let them know if they can get them changed it will make both of your lives easier. Never argue with developers about the requirements. Management sets them and the dev team should sign off on them(though I know that rarely happens in some places) but you are not the one setting policy, and neither are they, so debating the merits of the requirements is not going to produce any positive results. Better to deflect and stay on the same side of the issue as far as they are concerned.

  • I might be mistaken but the OP is not QAing the product but rather ensuring that procedures and security mandates are followed. Ex. When using SQL, do not use user input directly. It's not on him to verify the product is working as intended.
    – Dan
    Commented Jan 2, 2018 at 15:24
  • @Dan - It is a the same concept. When reporting bugs or reporting a process deficiency/failure you talk about the facts of what happened when you report it. Not who, what, or why it happened. You report what happened to management, and unless you are assigned to research that failure you move on. It is far to easy to try to do more than that and report include speculation as to the cause. That is for the analysis afterwards if warranted. Commented Jan 3, 2018 at 4:46

For what it's worth, speaking as a developer, I am grateful when someone finds my errors before they reach the customer. I may complain about the bugs, but if they're legit I really have nobody to blame but myself, our internal testing, or -- rarely -- the spec. None of that is QA's fault. Stop stressing about it and help us help the customer!


How can I maintain a good working relationship when the work may be politically unpalatable?

Don't limit your interactions with people to just this aspect of your job. Let them get to know you personally and professionally and not just this "void" that only shows up with bad news. I'm sure there's more to you than that.

Also, see if you can do your reviews and presentations in smaller chunks. No one wants to hear the 50 things they did wrong, when you could point out a few and they could correct many others, especially if they're similar problems. This may not fit in with the company's development process, but could be worked in.


When you interact with devs, make sure your approach and wording is a collaborative one. Framing it as a cyclical and continually-evolving process of improving systems (which it is) lets people know you are not interested in blaming. Go out of your way to be friendly, and focus on the work that needs to be done.

Some extra reading on psychology might help with avoiding situations and phrases that people might interpret as blame. Once you've worked there longer and they know you better, most people should become more engaging and collaborative.

Management usually has different motivations than staff. You need to spell out the financial and reputational risks as clearly and quantitatively as possible. They will be assessing what you recommend as a tradeoff - so make sure to offer them workable alternatives for issues you know will be politically-charged. You need to make it easy to do the right things, and still meet business needs.


You're not in a position where you'll make many friends who don't have a motive for befriending you. At least you have to look at things that way. So you need to stay polite and professional to everyone outside your department. In those sorts of jobs it's best to do the same with your peers as well. One day you might be tasked to check on them.

That is a good working relationship.

  • This doesn't offer any actionable advice. Everyone should be polite and professional to their colleagues regardless of their position. That doesn't reduce the strain on the working relationship when one person is obligated to document flaws in another's work.
    – ColleenV
    Commented Oct 22, 2015 at 17:30
  • what people should do and what people actually do don't always coincide, it reduces the strain a lot more than someone being snide or confrontational, both of which I have seen in real life.
    – Kilisi
    Commented Oct 22, 2015 at 17:51
  • My point is that your answer doesn't offer any help particular to this situation. Everyone could be polite and the problem will still exist that it's emotionally difficult for folks to separate objective audit findings from the person that documented them.
    – ColleenV
    Commented Oct 22, 2015 at 18:17
  • It makes sense to me, feel free to downvote it though (Y)
    – Kilisi
    Commented Oct 22, 2015 at 18:35

You must log in to answer this question.

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