“You are not paid to think, but to do X” is always wrong in the workplace?

Question

Background

I work in an IT consultancy company of about 200 people. As in many other companies, we work on multiple projects, with short deadlines, with a lot of pressure, both from internal managers and from clients, etc.

Last week a coworker (B) of another team got angry during a call over a person from test/QA department and said in an angry tone “You are not paid to think, but to carry out tests”. The heart of the matter was that the main tester on the project was flooding Jira tasks with hundreds of comments with suggestions, “I think that”, “I was thinking about”, “I suggest this development”, etc. These unsolicited comments are many times only loosely related to the bug. Because of internal policy, only when all comments are addressed, the bugs can be closed, so this tester was tasking in hostage and delaying an already delayed project.

In the call there were: B, other members of the development team, the project manager (and B direct manager), a higher manager, the tester and some of his team and the tester direct manager: nobody said anything about that sentence.

Questions

We discussed about the sentence between us and the widely accepted thought is that it is a passable sentence under these or similar circumstances, but it is preferable to limit its use. I also spoke with some friends from different industries/fields that instead said are all convinced that the sentence is not acceptable in the workplace. Whereas friends from IT generally agree with our conclusion.

Is this an acceptable sentence under some circumstances? It is always wrong in the workplace? Could it expose who says it to any consequences?

PS: there are no consequences on B for this sentence and also unsolicited comments by the tester stopped and all bugs are closed (usually directly by the tester manager)

update - 05/12

Many thanks to everybody answering my question, I had the opportunity to read a lot of suggestions and interesting points of view.

I also had a quick chat with B yesterday and he explained that the direct manager of the tester sent an e-mail apologizing for tester's behavior. This manager also took the place of the tester in the project and all bugs are now closed and the product released. Finally this manager moved (demoted?) the tester from a position on test/QA team leader to a position of simple integration tester on another project.

Answer 1

According to you and your experience, is this an acceptable sentence under some circumstances? It is always wrong in the workplace?

When someone says "You are not paid to think, but to do X", you should not take that literally. In every case you are paid to think at least a little, otherwise a robot would be doing your job.

Normally that phrase is used to cut off repeated, unproductive arguments and as a directive to get working.

In my experience, it's a foolish statement for someone to use. That doesn't mean that the implied reason ("too much arguing, not enough working") is wrong, just that there are usually better ways to say it.

In this specific case, the tester was clearly inappropriately injecting opinions into Jira tasks, rather than testing and reporting bugs as expected. The coworker on the other team who made the statement was inappropriate as well.

Management should be helping everyone understand their roles, and how much personal opinion should be involved. If I were the QA Director, I'd be having a long talk with both the tester and the coworker. They should be working toward the same goal, not passive-aggressively sniping at each other.

Answer 2

If you're in IT, you are paid to think.

The sentence you describe might just be the most incorrect thing I've ever heard in my IT career. No IT personnel is ever not paid to think, else their job would be automated.

It sounds like the real issue is that your co-worker is simply not using the right channels to communicate possible improvements, opting to put them in bug-tracking-related topics instead of suggestions/improvements topics.

Some possible alternative sentences you could use.

• Let's take this discussion to [more appropriate board/topic]
• Please keep discussions here strictly bug-related
• Good idea/point, but I feel this conversation might be more suitable for [more appropriate board/topic]

There are many more sentences one can use that get their point across without making their colleague feel unvalued.

Answer 3

This is not a productive response for several reasons:

1. It is extremely rude.
2. It devalues the QA person on a personal and professional level.
3. It does not appropriately convey why the QA person's behavior was inappropriate, which leads to...
4. It could make the QA person scared to do their job and perform due diligence.

Because of this outburst, it's possible that the QA person will notice something severely wrong that is outside of the scope of their job duties, and they won't report it, and the whole company could suffer.

Coworker B is right that the QA person is not performing their job duties correctly, and it's impacting other workers and the company itself. Coworker B was not right to say this phrase. They need to apologize, and then there needs to be some sort of meeting to clarify how suggestions and comments should be made, in order to make sure the project goes forward.

Answer 4

“You are not paid to think, but to do X” is always wrong in the workplace?

Maybe not, but it is always a red flag. Something might be wrong somewhere, and that wrong should be addressed.

If this phrase "escapes" occasionally, it might not be the end of the world, but if it becomes a mantra, the "ship" is probably sinking. Find a healthier, stronger ship.

---

Of course, there is another side to the issue - the abundance of comments, their quality, and what to do with them professionally.

The first thing to do is to objectively analyze the comments: are they really useful to improve the process / testing / product?

• If yes, then they must keep coming, maybe on a different channel - to avoid sinking the project.
• If no, the test engineer must be explained what is expected from the comments system, and how to write better comments - as well as that it is OK to write no comments at all if they are not needed.

The next thing, is to analyze the impact and the urgency of the comments. Based on this, a prioritization will be done. After that, the action derived from the comments have to be planned to be implemented in the project.

---

Bottom line: IT without thinking is a recipe for disaster. Sooner or later. One way or another. The examples are abundant in countless printed books and on the internet.

Answer 5

“You are not paid to think, but to carry out tests”

Making a comment like this is always unacceptable. Problem solving, critical thinking, and synthesis are the reasons organizations hire people - suggesting these are not important contributions from a colleague is disenfranchising and disrespectful.

Your colleague may have been attempting to express frustration or provide coaching, but this particular comment was not a productive way to do either. I'm sorry you experienced this.

Answer 6

Putting it this way is rude, quite obviously. A better way would have been "You are not doing your job. What you are doing is wasting everyone's time and costs the company money". (It was also factually wrong. QA is paid to think. Proper thinking would have avoided these JIRAs that wasted time and money).

But QA's job is to ensure that the product is of sufficient quality for selling / shipping. They will produce JIRAs if there are problems that a developer needs to fix.

If this QA employee is flooding the developers with purely opinion based suggestions, that is counter productive. The developer won't and absolutely shouldn't make a change due to such a suggestion. That should go to a product manager who should decide what needs to be done, and create tasks to make such a change or create no such tasks.

So it looks like this QA employee was wasting the developer's time. I expect from QA to get a JIRA is something doesn't work as it's supposed to work. And sometimes to get a JIRA when something works as designed, but the way it is designed is not good. I don't expect to be swamped with hundreds of JIRAs that I will all reject.

So there may be a point where wasting someone's time will result in rudeness. As you further said, it seems to have worked. The QA employee didn't understand their job, didn't do their job, with bad consequences (delays) for the company, and the rudeness caused a result - the reason for the rudeness was fixed. Someone I suppose explained his job to him.

PS. If the QA person not just wasted time but delayed the whole project by adding a comment “I think this button should be green instead of blue” after being told repeatedly not to do that kind of nonsense then being told “You are not paid to think” is understandable.

Answer 7

The heart of the matter was that the main tester on the project was flooding Jira tasks with hundreds of comments with suggestions

Personally I can see how this would be annoying if you have to read each line to figure out if there is a bug. Also, this would be extremely unproductive comments if the idea is already sold to the business and the comments would have to be evaluated again by the business.

I would simply make note that the comments are not productive as the idea is already sold and this is how the business wants it done. I would also make note that writing hundreds of comments would be counterproductive because it is hard to decipher between actual bugs and if they are merely comments.

I think screaming out he's not paid to think would be unproductive but an understandable outburst. I would use this opportunity to bring out the heart of the matter.

Answer 8

"You are not paid to think" is extremely rude and a great way to burn an employee

Keep the channels of communication open

A good QA tester is going to dive deep into the system you're developing and spot things they weren't specifically told to look for. They're experienced at scrutinizing software and may have valuable input. You really don't want to close down this channel of information.

... But keep them organized

However, your company has a process for tracking bugs (good), with rules that a bug can't be closed until all the comments have been addressed (good), and the tester is putting in off-topic comments (bad). You need to steer the tester to putting their input in the right place, and not in the wrong place. As a shorthand, you can start using a text like:

"Comment closed, off-topic. Please raise a separate issue in (appropriate place) for this."

You have to make sure that the appropriate place actually exists, and works. If your tester has no appropriate place to report "I also noticed that" things, that people respond to, then you brought this problem on yourself.

I wonder if your current communication process only consists of you asking specific questions (test cases)? Where is the tester supposed to go if they have something to report that wasn't asked? Is that channel being taken seriously? Putting comments into "must address all comments before closing" bug reports can be a cry for help.

Explain "won't do"

It isn't the role of QA to decide what features go into the product. To make a successful product, you also have to decide which features you won't do. Because they're not needed, or not valuable enough to add at the last moment and risk a deadline over. You need to explain to your tester that while you value suggestions, that doesn't mean you'll actually adopt all of them.

Make a difference between paying attention to suggestions, and adopting them. If the tester proposes a feature or improvement and you decide not to do it, acknowledge it instead of making it seem like you didn't even see the suggestion.

Answer 9

This phrase is acceptable only if you are a trying to play a role of tyrant and is usually used by a bad manager. Usually it just indicates that the person using it either cannot handle the argument or cannot listen to other people. The other form of this phrase is "because I said so". In your case it sounds like a simple way to cut off other person. Not picking any side in the fight but I can see it from both angles (as QA or as developer since I have experience in both). Personally in the situation you described I found out that it is way more productive to open separate ticket for every different item: for a QA opening a separate ticket allows to make sure that the issue that was raised is going to be looked at. As a developer I prefer that so the ticket I currently work on would not grow into scope creep area. So when somebody starts to enter a lot of unrelated comments into the ticket I would either ask them to create a new one or create it myself.

However, there are few rare cases where the feature has been implemented, working as expected and on paper looks fantastic in real life does not make any sense. Majority of those usually caught by a good QA and the toughest ones since everyone did their best but the result is either zero or negative. I always watch out for any hint on such feedback from QA and try to take it back to a drawing board. Usually such feedback comes out as unrelated comment in the ticket. In such case I would prefer to have a discussion with the person providing such information to find out if this is the case or not. If conversations with the person making such comment really end up such case then you should react like that otherwise either ask person to create ticket or create it for them. I prefer to have a ticket in a backlog that might be rejected down the line rather than miss valid feedback.

Basically when you are getting to a point where a conversation might get a bit heated it is more productive to breathe in breath out say something like "I need to think about it and I am going to respond in the ticket", recover your calm, write and if you are sure you are right write your arguments over in the ticket on why it is irrelevant/invalid/doesn't matter now. However this is two edged sword since if the other person was right and you aren't you have documented that now.

And keep in mind that all such things should not be looked as devs (dba vs backend vs ui) vs QA vs client vs whoever. The relationship should be like devs + QA + client + whoever = great product. I have been in the environments with a strong "free for all" environments where I was acting in a collaborative way and was treated like that in return.

Answer 10

Tests are a somewhat special case when it comes to IT work. Especially formal, especially regression tests.

If a test is predocumented (what is done to test), and the results are in the end reduced to a PASS or FAIL, the end result still says "X, Y, Z ... was done, to the result of ...".

X, Y, Z being tested can be defined by a contract specification with a customer, modifying the tests can redistribute liability in very unfortunate way if a defect surfaces (or in the worst case, causes real damage) that WOULD have been caught if the testing procedure was exactly followed. The flip side of this coin is that if a defect would provably not been detected by prescribed and agreed upon testing, depending on the contract, the product can still be sold and invoiced as meeting specification, middle finger included as a bonus.

From a wider perspective, work (to specification) might already have been described, offered, calculated and SOLD. While a post-facto modification might raise efficiency (already calculated!), it also raises risk (already calculated!).