How to diplomatically tell coworker to back off?

Question

I am working for a project in a team of 5 people. The team comprises of 3 people from my company and 2 freelancers.

I have the role of the tech lead / architect of the team, though I have less experience both in general and in this project than one of the freelancers. He is the type of person that has an opinion about everything, and spends a lot of his time in meetings since he wants to know and have an opinion on all topics.

I, together with 2 people outside this immediate team, are currently running some performance tests on our system.

This freelancer asked me yesterday if he can see the "report". I replied, that the report isn't available yet, and will be provided once we are done with the tests. His reply to this was

"No, I need the report now, this is where the conditions are documented and the scenarios are listed. The results are only useful when the starting conditions are known".

A couple of things:

1. I interpreted "report", as the documentation of the results, not the starting conditions and scenarios. It feels paternalistic to be told that it makes sense to have the starting conditions documented.

2. I dislike "No, I need the report now" for multiple reasons. First of all I dislike the tone, since I don't think that it's his role to request that. Second, 3 people are currently involved in these tests, and we don't need him poking his nose and checking the results / telling us what to do.

I have a bit of an ego / emotional reaction to that that I want to keep in check ("who is he to request things of me?").

But beyond that I think that that's not helpful for the team. His role isn't to try and get involved into everything and check up whether we are doing a good job or not.

Situations like this keep happening, so I want to find a good way to communicate this, without being whiny or complain about it.

How do I handle this? Is this an issue in your eyes or should I just let him do whatever he wants?

Edit to answer a question: He doesn't need this information, since he isn't working on the performance tests. He just tends to want to criticise and have an opinion about everything. Regarding my role: we work in a more modern environment, so I don't do division and assignment of tasks, I am responsible for the end result and have the final say in some matters.

Answer 1

How to diplomatically tell coworker to back off?

To directly answer the question in the title: A polite way to tell him to back off would be to pretend that he made an offer to help. That

• allows him to save face and
• allows you to assert your position.

"Thanks for your offer, but we currently don't need your help for this project. If we need your input, I will let you know."

Now the onus is on him to explain why he needs that report right now.

Answer 2

I have the role of the tech lead / architect of the team,

Then act as one. I assume as a lead it's your job to divide up the work, define the tasks, assign them to team members and make sure they have everything they need to get the work done.

If the coworker needs the data or report you should make it available and communicate when and it what format this will happen. If they don't need it, tell them (politely but firmly) to go and pound sand

First of all I dislike the tone,

Irrelevant. It's better if your keep your emptions out of it.

since I don't think that it's his role to request that.

Does he he need that data to do his assigned work or not? If yes, of course he needs to request it. How else should he get it?

("who is he to request things of me?").

Irrelevant. If he is requesting stuff that he needs, he should do so.

Summary: Ignore tone of voice, your dislikes or who has the "right" to request something or not. Focus on making sure everyone has clear task with clear deliverables and the all the input and resources they need to do their job. If someone asks for something they don't need you can push back: "Why do you need that?" "Is this blocking you in any way?" "How will this help you with your deliverable?", etc.

Answer 3

It's clear from your question that there is a problem, but it's not clear what that is. No matter what it is, however, my advice is:

1. Be a professional. That means doing the right thing for your customer and your team, and not defending your ego or your fiefdom. That enables...
2. Be honest. If you're confident that all your actions are above board, then you can tell the truth as you see it, and that includes making your position of authority clear so that you can continue to exercise that authority.

For instance when the freelancer says "No, I need the report now...", you can respond:

1. "You're welcome to what we currently have, ...", because of course he is. You're on the same team and you're a professional...
2. "but, I don't have time to write preliminary docs just for you. The report will be done when it's due." You don't work for this person, and you don't have to meet his expectations when it interferes with keeping your own promises.

As a team member, especially a lead, you should normally go out of your way to help out other team members, but that is you doing what you think is best for the team. If you are currently angry with this freelancer, then it's probably because you have let yourself become subservient in some way and you resent it. Just stop that. If you are making your own decisions for the benefit of the team, then it will be clear to everyone who sees it that you aren't easy to push around.

Answer 4

As a lead giving negative feedback is part of your job. One way to make giving negative feedback easier would be to flag that it's on the way. E.g. "I have some feedback, it's critical, is now a good time to go through it?"

Once you have the meeting to provide feedback you should talk through his behaviour. Emphasize you value his expertise but suggest that there are better ways to communicate it. As it is, the positives of the experience this person brings is outweighed by negativity he brings to the team. Give suggestions about how the same criticism can be reframed in a positive way. E.g. I've found a way to improve system X. Rather than current setup for system X is terrible.

I feel you need to do this first assuming it's just a soft skills issue. After this, if it's an authority issue you need to make clear that your opinion is that his impact on the team is net negative and to remind this person that has lead your opinion matters.

Its not nice to pull rank on people but equally you shouldn't act like you don't have rank. Even a place that likes to work from first principles, the interpretation of the manager is the interpretation that matters.

Answer 5

So the freelancer has more experience in general, more experience in this particular kind of project, he knows everything, and he listens to everything?

First thing, have you tried tapping him for advice? What's your general opinion on the quality of his opinions?

Second, you use phrases like "poking his nose in" and "who is he to request things of me?". The most obvious riposte is that, according to you, he's a man with considerably more experience with this kind of project.

It is not entirely clear that your employer hasn't hired him precisely because he is going to exercise some oversight and contribute more expertise than they can find internally. They might also be hoping that some of his expertise rubs off on the internal staff. Is it possible that you are making this freelancer nervous?

You tempt us to believe that he is simply a busybody or that he is mithering over groundless concerns, and if he was then an opening gambit might be to simply put it to him that you think he has concerns, and ask him what those concerns are. If they were obviously groundless (such as raising points that you had explicitly considered, and with which he did not disagree with your judgment), then urging him to let you have a chance to do your job might be enough. A next step might be to ask for your own manager's advice and mediation.

But I have a suspicion that what may actually be going on is that you resent the presence of someone whose capability and credentials you could well be harnessing, and the resulting vibes create concerns on his part which lead to more, rather than fewer, intrusive questions about your activities.

Answer 6

The best way to say no is "yes, when." So it's simple:

I'll be happy to share the report when it's ready.

Repeat this, like you're brain dead and can't think of anything else to say, and do not give in.

If you feel that won't land well, add some nice. But don't give in.

I would definitely appreciate any feedback you provide that helps make things better. If once the report is available, you notice any issues or find some actionable insight, please do let me know.

Answer 7

For the particular example you gave, solving the issue seems simple: tell him where in your repo you've put the code you use to run the tests. (There should also be documentation there about how to run the tests, if that's not obvious from the code itself.)

If you've not got this code (and documentation, if applicable) in the repo you should treat as query as, "why are not keeping this code with our other code?" I can't think of a good reason to have this kind of thing separated, and it would seem even worse to have it somewhere not accessible to the rest of the team.

---

For the larger issue, it depends on what sort of team in which you're working. The teams in which I work tend to devolve authority down as far as possible, meaning that the final decisions about the design of a particular piece of code are left to whoever is actually writing the code unless the rest of the team (not just one or two members) feels reasonably strongly that the way that one team member is going about it is terrible.

What that means is that if just one person is proffering advice to others on something that one person isn't directly working on, that's all it is, advice. For such situations I'd suggest that the advice-giver writes up his advice in an e-mail, making the best argument he can for it, and sends it to whoever's working on that particular bit of code, cc'd to the rest of the team. The recipients can then take or leave it, or invite further discussion, or simply say "thanks" and carry on. This a) documents the advice-giver's disagreement with the current situation, and b) ensures that a lot of unproductive arguing is avoided when the advice-giver is clearly not going to change others' minds.

The alternative is that the advice-giver takes over whatever currently needs to be done on that bit of code. This may require him to give some of his current bits of work to someone else if he doesn't have time to do them both. (In my highly devolved management situations, members of the group get to decide amongst themselves what they're going to work on, who they're going to pair with, and so on, consistent again with the team overall not finding that some particular choice is terribly harmful.) This also has a limiting effect in that someone may be a know-it-all, but unless they can find the time to write all the code, they're not going to have time to make all of the programming decisions.

Answer 8

I am adding a new answer because I don't believe any of the other answers have fully addressed a key component of the your particularly situation: that you may be suffering from Imposter Syndrome.

This is evidenced by the statement:

I have the role of the tech lead / architect of the team, though I have less experience both in general and in this project than one of the freelancers

If true, the Imposter Syndrome is likely the reason why you had an emotional reaction to your coworker's demands to get involved with the perf testing, and likely holds the clue for how you can easily deal with this kind of behavior.

The key to this is the recognition that the sufferer of imposter syndrome almost always oversimplifies a complex situation to their own detriment.

In your case it may be an assumption at some level that you are unequipped to take technical leadership of the team because you are less experienced or skilled than other team members.

If this is the case then you should recognise that to provide good leadership, soft skills like communication, political awareness, empathy, and organisational capability far outweigh hard skills, and that you would not be in the position you are in if you did not posess these to some degree.

It is therefore perfectly normal and reasonable (although it may not feel like it) for you to be

1. responsible for the team's technical direction, and
2. taking such decisions that you believe are correct for the team

Answer 9

If it's a performance test, then ideally there should be a test plan, even if it's informal.

The test plan will have, at least, the outline of the conditions, elements to be exercised, measurements to be made, and other analysis that will be conducted.

The final report will include the rest.