How to handle a senior colleague who is overstepping their authority? [closed]

Question

Background

I work in a software development team within a large corporation whose primary business is not software. We are trying to develop in an "agile" manner but this is often at odds with the more bureaucratic and heavyweight management structure that we work within. There is a general air of dissatisfaction both from ourselves and management about our ability to meet deadlines, but not so bad that we are expected to work unpaid overtime.

I am a developer with 6 years' experience, 4 of which are with this company, am enthusiastic about my work and want to improve our situation. In my spare time I sometimes look into development practices and new programming languages. I believe I am keen and knowledgeable enough to help improve the productivity of the team, but am aware of the limitations of my knowledge owing to my relative inexperience and lack of management responsibility. I don't handle conflict well and tend to either shrink back or respond too aggressively.

Situation

In a recent scrum meeting our head of QA (let's call him "John") came in and complained that we weren't adding comments on our issue tracker when moving them from one status to the next, demanded we do so and stated that this was "non-negotiable", citing this as being necessary for external audit and accreditation purposes. Weary from similar behavior from John in the past (he is the admin for the issue tracker server and often makes changes in an attempt to get us to work in a particular way), and fairly sure that external accreditations are not this prescriptive with regards to workflow, I laughed and half-jokingly asked "can we make it negotiable?". (Admittedly not the wisest move I now acknowledge.) John flatly said no. I asked if he could point to anything in our internal wiki that would tell us what kind of comments should be made and when/where, but he said that it was simply "common sense". I replied that he "clearly has specific requirements in mind regarding the audit. It is completely unreasonable to make demands of us if [he is] not going to make these explicit". Some heated but relatively inconsequential back-and-forth followed.

On the way out of the scrum meeting John and I were tailing at the back. Out of earshot from the rest of the team, he said to me that he would "have a little chat with me" since I was "being antagonistic". He didn't follow through on this but I was on edge all afternoon waiting for him to do so.

The main reason for my objections was/is that as far as I understand, as head of QA John does not have the authority to lay down diktats to the development team like that. Regarding the issue tracker usage, I am all for putting down useful information but in the interests of conserving a good signal-to-noise ratio I am dead against "rubber stamp" comments that serve only as a box-ticking exercise. I am aware that external audits place certain requirements on us that need to be met, but I think that John was (intentionally or not) conflating these requirements with his own opinions about how we should work. I don't care so much about the issue at hand as much as I do the principle that as a team we should be treated as professionals that can take responsibility for our own workflow. I think that a big problem in our company is that we (developers) are dictated to so much that this stifles any drive or feeling of responsibility to improve our productivity.

The following morning I explained the situation to my line manager for some advice in how to resolve the situation, during which he agreed with my assessment that John is overstepping his bounds. Afterwards I sent an email to John to better express my objections but did not make any accusations to him about his authority or otherwise in this situation. This resulted in a meeting between just the two of us, in which he explained that there are often occasions where we have implemented features in a way that differs from the stated acceptance criteria, leading to confusion amongst the test team. I was unaware this and agreed with him that it would be good to solve such communication problems within the department.

However, the day after John distributed a wiki post that was sadly much closer to the verbal complaint he raised in our scrum meeting. It seems like he took some of what I said on board by promising to be "open to suggestions", but he still left so much emphasis on requirements about external audits while again not being explicit about what they are that my overall impression is that he is spreading enough FUD in order that we work in his prescribed manner. Sadly he only tangentially touched upon the genuinely good points about communication issues that he related to me in our private meeting.

My Analysis

I think that John behaves in this way because he really believes his ideas will improve our productivity (as opposed to some cynical power grab for its own sake), just as I believe my ideas would. The best solution for such issues is a pragmatic compromise between his views and those of us a dev team, but I am unsure as to how to get him to engage with us in this manner. I get the impression that other team members have similar frustrations with him, but he gets his way because it is often easier to submit to his whims than it is to convince him otherwise.

I have been reading other questions on this site in preparation for asking this one and have seen a lot of sensible advice from "How to Win Friends and Influence People" that would suggest that I try to present my concerns in a more collaborative manner that allows both parties to concede ground without losing face. However all of my experience of him leads me to believe that this can never be productive while he has the mistaken belief that he has the last say in how we do our jobs.

The Question

How can I help correct the power balance between our team and this colleague, such that we can reach agreements that best suit all parties, without creating unnecessary conflict or behaving in an unprofessional manner?

Answer 1

It's clichéd, but the answer is to be the bigger man.

You believe that John's intentions are good, this is key. Humour him, be his advocate. Do not give him any chance to paint you as antagonistic. If he honestly believes that adding comments will improve productivity, then play along.

The next time you're about to move an issue, think hard about if there is any meaningful context you can add as a comment. Really, actually, honestly -- think hard. Just because something is obvious to you, and feels like it should be obvious to everybody, often it isn't. And even if it is, information is often ephemeral, floating around verbally and buried in email threads. Does the next person to work this issue, even if they just landed from a two-week holiday, have all the information they need to proceed right there on the issue? If not, update and comment until they do. Boy scout principles apply: Leave it in better shape than you found it, it doesn't matter who's fault it was. Always err on the side of under-assuming and over-communicating.

Now, if your version of events are correct, and John is wrong, very quickly you'll come across an issue where literally nothing could be improved. Now you strike: "John, do you have a second? This is what I was talking about. I'm totally at a loss here, what should I comment here?" Do NOT be aggressive or gloating, this is an honest question: Remember, John only wants what's best for the team.

Once you've done that a few times, and John has come up short, you casually add a section to John's wiki page titled "Exceptions" and line out the exceptions. As this section grows with John-approved exceptions, it becomes embarrassing to him, and he will revise his position, make it less rigid. John will realise that you're a reasonable guy, and be more likely to consider your concerns in the future.

And if you don't end up with such a list of exceptions, perhaps John was right after all, and his suggestions, however awkwardly and ungracefully shared, actually improved your work -- and you didn't stand in the way of it.

Answer 2

This is not going to be a popular answer, or something that you want to hear. I think that the real problem is encapsulated in this sentence right here:

I think that a big problem in our company is that we (developers) are dictated to so much that this stifles any drive or feeling of responsibility to improve our productivity.

It sounds like your workplace has a lot of rules, and bureaucracy, and a general culture that stifles some of the joy of coding, and that is (understandably) very frustrating. And so, it sounds like you are lashing out at John's request -- not because his request is really a big deal, but because you are frustrated, and he in not in your direct chain of command so he is easy to lash out against.

John's request is reasonable, and motivated by an actual need. External audits and accreditations are a valid concern for a QA department head and his superiors in upper management (even if your company is not rigorous about performing them). If an audit is ever performed, and they find a problem with flawed software slipping through your bug tracker or (worse) a security flaw that sailed through your bug tracker, and there are no comments to provide any context for the programmers thought-process, then the optics are very bad for John and his QA department. The first thing they will want to know is, "why don't your programmers comment on bug fixes?" And his best answer will be, "because I let them get away with not doing it." That is not an acceptable answer.

It's not like John is asking you to do something arduous. If the bug was "button is disabled when checkbox was clicked; should not be disabled", then just add a one-liner (just like you (hopefully) do in Subversion / Git: "fixed button - no longer disabled when checkbox is clicked"). If you are moving it from the In-Progress swim lane to the Complete / Acceptance Review (or whatever your company's process is), then just give John a one-line comment. Even a stupid / boilerplate comment. The main thing Johns needs is an insight into the programmers headspace. It takes like 10 seconds, and helps satisfy a valid need.

It sounds like your company wants to (at least try to) write good software, which is why they pay the salaries of your QA department. Fighting against your QA department's ability to protect your company from flawed software (even if they aren't doing it right (in your opinion)) makes it look to management like you are being difficult, and working at cross-purposes to a valid business need. Your boss is not going to fight this battle, because he knows it's a hopeless campaign. Your company is not going to stop your QA department from (trying) to do their job. And John's argument ("we need this small thing to be more audit proof") is stronger than yours ("he's not the boss of me").

Answer 3

Surely as a developer you are already familiar with the concept of someone who knows what they want and what's not right, but cannot articulate a set of clear and obvious rules that describe it. The irony of your QA lead not being able to write requirements for these comments on a status change is rich, but it doesn't help you do your job.

I suggest you approach the coworker and offer to (ask if it's ok to, suggest that the two of you) add a number of good and bad examples of comments to the wiki that was started. Suggest working on them together aloud before the wiki is updated. Since you dislike content-free rubber stamp comments, you can include some of those ("ready to test", "coding complete", "as discussed in scrum today") to the bad side, and with any luck your QA lead will suggest some for the good side that address issues the new rule is trying to prevent ("moving to test even though categories are not alphabetical - customer has agreed we don't need that", "back to code because customer now wants all columns centred") or has liked in the past.

You should come out of the meeting with

• a real understanding of what the QA lead wants
• solid proof that you're a team player, who will roll up your sleeves and help lead the quality level forward rather than just complaining in meetings or going around discussing third parties behind their backs
• a better wiki for the rest of the team
• possibly a better relationship with the QA lead

What can it hurt?

Answer 4

This is your managers job, if the team is having an issue with one member, it should have been noticed by the manager already. If not, bring it to his/her attention.

Anything that impacts on workflow and team morale should be given to the manager to sort out. That's the professional way, not beating around the bush or making up your own protocols. It's one of the managers main roles.