48

I am PI (Principal Investigator at University) of some projects (funded my H2020 grants). Some technicians have been hired to support the projects. I gave them the project proposal document so that they can see what the "big picture" is and the main objectives. The project is to run for 4 years. In day to day operations, new tasks are defined depending on previous results.

When I tell one of the technicians to do these tasks, she complains approximately 50% of the time because she thinks the task is not necessary or asks me if there is no other option to avoid this. Then I need to argue and explain all pros and cons. In the end she does the tasks. From one side I find it OK to argue about this, because I might be wrong and this can help me to better think and later explain my ideas - not to technicians but to students - but from the other side this requires extra time that I do not always have.

On days when I have low energy, I do not tell her what needs to be done; I prefer instead to wait until the next day, because I start to see that we will spend an hour arguing unnecessarily about the tasks. In addition she has a contract with my academic institution and she is paid by the project to do the tasks. So in the end I think not so much arguing would be needed and that she should not be irritated by all this.

Sometimes I feel I am trying to be nice to everybody and this is the main cause of the problem. But I do not want to be a dictator as well.

How can I better handle this situation?

  • 4
    Yes, but I want to avoid that. The technician has been working with us for 7 years and has gained a lot of experience and she is now the only one that knows how to fix some of the lab equipment – Open the way Sep 10 at 12:37
  • 2
    Is the arguing behaviour a new thing, or has it been going on for all of those 7 years? – Philip Kendall Sep 10 at 12:41
  • 2
    it has not been always like that. Only the last 12 months (approx.) – Open the way Sep 10 at 12:41
  • 5
    Is she your subordinate? – Smock Sep 10 at 16:25
  • 37
    "she is now the only one that knows how to fix some of the lab equipment" consider adding a responsibility for "improve documentation on repair methods" for that equipment. Red-Bus syndrome is a thing. – Criggie Sep 10 at 21:34

12 Answers 12

71

Ahh, the old, "I'm the boss, but I want to be your friend" situation.

I will tell you to answer your question directly without context, and then try with context.

Namely, be the boss and not their friendly coworker. Tell them this is the job you have for them, and that's it. They are paid to do what you say and be done with it.

But own up to your foreseeable failures.

Now with some discussion.

It is certainly difficult to work on projects at the university when dealing with all the hubub, students, and coworkers sometimes.

I feel this is because of a general "us against them" attitude. Namely, the Phd's against the students, and the technicians against the Phd's, etc., etc.

What also isn't helpful is the general relaxed work life at the university...there isn't the same kind of time schedule pressure like there is in the industry...until there is.

I have been in this exact situation, however on the side being the technician. Constantly arguing over things to do, mostly because my boss had no idea what or how to achieve any given task, except for the theory they learned along their educational path. While I have spent close to a decade working with a trade before entering academics...

Both of us knew what we were doing. One of us had experience making them in real life, while the other had experience doing the maths (to generalize the situation) of it....so as frustrating as it is to be on your side. It's equally as frustrating being on their side listening to someone go on about something they themselves couldn't bring to reality.

There is something I want to point out that is important that isn't clear among academics. There is an entire science to making, and it often doesn't jive with theory.

A well trained technician or tradesperson should have learned along their studies how to predict failure. I find this is often lacking in academics..."if we do this, the math says it'll work"

To quote Adam Savage:

The only difference between a master tradesperson and a novice, is the novice has yet to learn when something is going to fail, how to avoid it, and if need be, how to cheat to cover it up.

Your technician when given a task, should be trying to see what happens after said task is done. This is going to naturally cause a discussion. One you seem to not want to have...but you honest to god just have to suck it up and deal with it.

I am a professional in what I do. If I'm tasked with something, it's going to be clearly defined, and it will be completed to that exact specification given. But if your specifications are just garbage, or don't make sense to me for related tasks down the road related to the project, I will want to know why you reason it must be done that way, and I'm going to not want to do it, because it's going to cause problems for me later.

I will argue that it's stupid if that doesn't make sense in the long term. A tradesperson who doesn't care, or bother finding out the whole picture isn't in my opinion worth their salt.

A professional who knows their stuff I trust to tell me when I'm requesting nonsense, and this is something you simply have to learn to work with.

There are boundaries to this. Depending on your assignment, if it's simply making something quick, or something is unimportant, well you can simply tell your coworker, you're the boss and you want this done, no discussion.

If your coworker does this with all tasks, it may not be a sign of professional wisdom, but laziness...and laziness shouldn't be tolerated and this requires being a firm, foot down kind of boss.

But if these discussions are legitimate from their side. Well, there is nothing to do but learn to discuss, or back up with clear, thought-out reasonings why this task needs to be done and be prepared to defend it.

Regardless of what happens, if you do make a decision and your technician said it was going to fail, and it does. You have to own up to it.

  • In my opinion this is an interesting discussion that may not have a best solution. E.g. you mentioned the industry and their deadlines, however coming from the industry and having left companies for ridiculous amounts of pressure build up - this is not a goal to strive for either. Neither is getting things done "at some point". Just striking the golden middle requires perfect management and perfect employees, neither of which exist. – Mär Sep 11 at 9:14
  • 7
    In general, having thought about this, this seems to be a situation that may be dependent heavily on context. If an employee is dealing with inefficient orders, orders that may lead to faulty results or take a lot longer than choosing a different process, then employee frustration is understandable, especially with academic employees, who think and don't just act and say "yes". Even more so, this is usually expected by management. However this may also be a situation where an employee questions everything, because they do not fully understand the implications of the order. Difficult. – Mär Sep 11 at 9:30
  • 5
    In theory, there is no difference between theory and practice. In practice, there is... – cbeleites supports Monica Sep 11 at 15:25
35

You don't want to stop her from asking questions, because that's how accidents happen. You said that it helps you in one way and makes you think and that's a good thing and the only problem you have is with energy. If she's getting the job done and you don't always have energy then you can just tell her that you don't have the energy. When you do have the energy you can listen. That's how my one boss always did it.

  • Yes, that is a good point and I am happy to see that I am not the only one that has the same "problem" – Open the way Sep 10 at 12:42
  • 2
    @Opentheway sometimes people don't like to make mistakes so they ask alot of questions but then they don't make mistakes and the time you spend now you wont need to spend later with her fixing mistakes so you can look at it that way too. – Tina_Sea Sep 10 at 14:46
  • 11
    But this isn't asking questions, this is questioning the necessity of an order. Asking questions leads to growth. Complaining about tasks and questioning their necessity leads to toxicity and hindrance. Considering alternatives may lead to improvements, but it doesn't sound like that is the case – Mars Sep 11 at 4:06
  • 2
    When working with educated employees, questioning orders is sometimes expected and even required. If an employee recognizes a process the way it is requested by management to be inefficient, faulty, or for whatever other reason invalid, then management even expects pushback. Otherwise you will get statements, such as, "if you knew this was bad, why didn't you open your mouth"? This entire issue may be context dependent. Possibly the PI issues inefficient orders. Possible the technician argues every order unnecessarily, because they do not fully understand all implications. Hard to judge. – Mär Sep 11 at 9:23
  • @Mär The in the end, she does the task after having the pros and cons explained suggests that the technician has started (in the last year or so) to just argue every order – Mars Sep 12 at 0:17
25

If there's one thing I've learned, it's that technicians are ignored at my peril. I would go the other way from the other answers and embrace this technician's feedback by formalizing the review process. Add a step to your process called "technician readiness review" where you solicit feedback from all your technicians (not just this one) about whether a task has been adequately specified, what alternatives have been considered, etc. Send out the task in written form for the review, then schedule a short meeting to finalize the task (or tasks) based on submitted written feedback.

This has a few benefits. It forces you to consider whether a task is truly ready for review. It provides a defined time and place where feedback is considered, which allows you to mentally prepare. It comes with the expectation that the technician is also prepared for the review meeting. Finally, it provides your workers with context for their tasks. It is surprising how often it is important to know why plan B was rejected when implementing plan A.

11

Would it require less energy from you if the extended discussion were conducted through email? I find that FTF conversations tend to drain my energy, whereas (perhaps because I'm more comfortable as a writer than a conversationalist) I can pour a lot of time into email arguments without feeling exhausted or discouraged.

Part of that may be because I am not "on the spot". I can answer at my leisure, giving me time to think carefully about what I mean to say. If the email arrives at an inconvenient time, I can simply put it off until it is convenient to answer.

It is also a lot harder for people who tend to use sheer volume to "win" arguments, or who want to argue just to be arguing, to waste my time or take advantage of the fact that I don't like to be too assertive.

Another benefit might be to reduce the amount of arguing that she does. If she comes into the discussion looking for an argument, perhaps because she is upset due to stresses outside the workplace, an email discussion would make a less satisfying outlet than FTF, and it might cause her to direct those impulses elsewhere.

If you think she would take it well, you might be frank with her and tell her that although you value her feedback and insights, the discussions which you have are taking up too much of your day. You might ask for her suggestions as to how to deal with that problem. Or you might simply move on to explaining that you will be sending out task assignments via email.

If you don't want to seem to be targeting her, you could just change policy and maybe send out a list of proposed tasks prior to the meeting and ask for any feedback before the meeting, so as to save time (you didn't mention whether she argues during the meetings or in private). If she insists on arguing in person, tell her "those are all valid arguments, please write them up and send to me so I can look at them when I have time)

  • 6
    The email method allows you to skim read and just reply "Thanks, I'd already considered this, can you start testing tomorrow please" to cut the argument dead. I like the idea of the task list too. – Smock Sep 10 at 16:26
9

In the past, I realized that I was also doing something similar. Tasks would arise that I saw little value in and didn't particularly want to do, so I would question them. I realized this and began to ask myself "What do I hope to gain by asking questioning this task?" It's not like you can just tell the client, "That's not worth doing."

The client decides that, not the technician.

The next time she begins to question the necessity of your request, ask her what her desired outcome (from the conversation) is. You've decided XXX needs to be done, and the current task needs to be completed to achieve that. Ask her if she is proposing an alternative and if that alternative saves the 2-3 man-hours that she would otherwise take up questioning the task.

The trick here is to get her to realize on her own that there is nothing to be gained by questioning every little task.

  • What do you mean by "It's not like the you can just tell" (seems incomprehensible)? – Peter Mortensen Sep 12 at 7:15
  • @PeterMortensen "It's not as if you can just tell" might be more comprehensible in different parts of the world? – Mars Sep 12 at 7:18
  • Either way, it means "You cannot tell the client that it's 'not worth doing'", because the one who decides if it is worth doing or not is the client. – Mars Sep 12 at 7:19
  • 1
    @Mars Pretty sure Peter was just confused by the extra "the" that looks like a typo to me. I've submitted an edit for it that also improves some other minor grammatical/mechanical problems. – jpmc26 Sep 12 at 18:14
  • @jpmc26 Thanks, didn't catch that. Thanks for the edits too – Mars Sep 12 at 23:52
5

The interesting part to this question is that you've not mentioned the actual topics. This helps in highlighting a key component here: we could pick either side depending on the topic.

  1. Maybe the technician is right and you are blindly asking her to perform menial and easily avoidable tasks. I've definitely worked in jobs like these, it's pretty much how I turned my IT support career into a development career.

  2. Maybe you are right and the technician is blind to the notion that you may have already done the leg work that she's trying to do herself now by questioning everything. Maybe it's a matter of fishing for procrastination options. I'll admit that I have been this person back when I started working.

Even if you are right, you're never going to be able to convince her that it's the second situation and not the first. From her (possibly flawed) point of view, the first situation is just as possible. Dunning-Kruger very much applies here, and both you and her are potentially succumbing to it.

I would suggest you shortcircuit the discussion and leave it up to the technician. You give her the task, and explain your expectation (e.g. the result she should have by the end of the day). How she gets to that result is up to her, if she sees room for improvement she's free to look at it but the responsibility of failing to deliver is hers.

You're dealing with someone who is rejecting guidance (and assuming she knows better than you) and is trying to assume independence and freedom of work approach. You're not going to resolve it by doubling down on the guidance. The best way is to give them what they ask for, because you win either way:

  • If she fails to deliver the needed results, you now have proof that can be used to shut down her future arguments.
  • If she delivers the results in a better way, that's in your benefit too.

At the risk of not getting the results on time once or twice, you ensure that the future tasks will be done better (if she delivers) or at least without endless discussion (if she fails).

The only way to avoid risking not getting the results on time once or twice (while also avoiding the endless discussions) would be to outright replace the technician, which I surmise is impossible and it's also not really a friendly way to approach the issue.

4

There is a dividing line between "what has to be achieved" and "how to achieve it".

The first one is your responsibility, and assuming you are professional enough to own up to your mistakes when they happen, is not negotiable.

The second one is certainly negotiable, if the technician has many years of practical experience and a good track record.

The best solution for both parties is to find the right division between "what" and "how" in the instructions you are giving. Too much "how" is probably causing your current problems.

Too little "how" may lead to the wrong things being done. For example the technician can't be expected to automatically know why you need to measure something by method A and not method B when both would apparently give good results. If using method A is essential for the project as a whole, you need to make that clear, and not waste time arguing about whether it is the "best" choice from the technician's point of view.

The optimum solution to your problem will recognize that you both have expertise that the other does not, and you both take professional responsibility for you own actions and decisions.

4

Some things I would try:

  • Give her the task in writing, so she can't immediately complain
  • Explain your thought process how you came to this solution, so she can see which parts you considered and what you missed
  • Ask her for clear feedback what you maybe missed and how she would solve it
  • Read those answers carefully and then start the next iteration with an improved task

This way you will both learn a lot about the other domain, and it will long term reduce the discussions, because you know the other person well enough to understand their thinking.

Also, as you say, it helps in understanding the problems better and explaining them later on to other people.

I would also recommend using some tool that is lighter than email, maybe Trello or Jira.

3

All this is translated in that the days I have low energy, I do not tell her what needs to be done, I prefer instead to wait until the next day, because I start to see that we will spend one hour arguing unnecessarily about the tasks.

Quite simply, she is taking advantage (don't have a better wording) of your availability to have an argument with you. There can be good and bad reasons for this, and because you cannot be too sure, and you want to be nice to her, you usually engage in discussing.

But if this preoccupy you to the point you are exhausted and avoid her, that means this situation is problematic. There surely can be a middle ground where you are able to dispose of your time the way you want without being a dictator. One way or another, she probably need a gentle reminder that your time isn't granted.

An initial tactic could be postponing these discussions to a later date where you feel more prepared. She might also have more structured, simpler questions once given time to think about it. You can also be a bit harsher and decline discussion by pretexting you are exhausted or have other matters at hand, without proposing to postpone. If both of these weak messages don't reach target, you can have a discussion with her about her behavior, trying to listen to her reasons, and explaining to her the situation, that you need tasks to be done and don't have the time to discuss it every time.

1

Here’s a possibility: The technician acts this way because she wants to look interested in the work (instead of just doing as she’s told), and it looks to her as if you appreciate this attitude because you explain things carefully to her. Your views and your actions are contradictory.

So the next time when she complains, you just say: “Can you just do it the way I asked you do do it?” See what happens. If you are lucky, she just walks away happily and does her job.

1

I think this depends a lot on context. The specific context I would like to know is, you say these discussions are often valuable and force you to critically think about your ideas and question your assumptions. Now, when you finish these discussions, more often than not, do you find yourself asserting your approach as correct, or do you find yourself realizing there were some important things you did not consider and have to revise your tasks on a regular basis? This is an important distinction and something to think about.

In the former case, it sounds like this technician is wasting your time. She wants to "be right" and "do things her way", project be damned, and she wants an excuse to do it. She wants to be right so she can complain about how stupid you are as "just the math guy" or so she can take her task and delay it by a week or more until you're adequately frustrated and force her to do it (which delays the project). This is not acceptable, and if this is the case then you should put your foot down, something like:

Jane, we've had these discussions on a regular basis; whenever you're given a task you argue about it, but it seems like your arguments tend to hold little weight. If you have a true concern about your task, you can raise it, but please stop arguing over every little thing. I know what I'm doing and I've planned this out, so please trust my judgment and do your work.

The latter case is a bit different. If the tech comes to you and regularly raises real concerns that make you go back and redesign your approach, there's probably a disconnect in what you believe as "the math guy" and what the real world looks like. In this case, the problem is quite bad indeed:

1) You do not understand the specifications of your own project that you are leading. Nobody else understands it better than you, so if you don't understand it, that's a big problem.

2) The other technicians who aren't questioning you as much are blindly following bad orders. Prepare to run into a disaster situation in the future with their pieces of the project, because they didn't have the foresight or forethought to question you on your bad decisions.

3) You may not know enough about this field of research as you think you did. You need to brush up on exactly what the technicians are doing to implement your project to make sure you're not giving them something to do which will blow up in your face. You don't want to get to year 3 of your 4-year project only to realize you've been going in completely the wrong direction and now you have 1 year to do 4 years work.

If you find yourself being regularly corrected (in that you are in the wrong), take a step back, talk to your technicians, and make sure everyone is on the same page. In this discussion, the goal is not to bring them to your page, but rather to bring you to theirs. You need to ask for feedback from them as to why your vision of the project sucks and how they would make it better. You're the theory and math guy, but theory and math only goes so far, and the technicians are the experts in the reality of the project, not you. The earlier you realize that you may be the one in the wrong, the smoother the project will go and the more on-track it will finish.

  • If OP is regularly wrong about technical details, instead of just using the technician to fix his plans, he should involve her in the planning earlier, so she has the bigger picture. – Robin Bennett Sep 12 at 7:59
0

Can you stagger things? Have a meeting where she discusses the previous task, then you bring up the new task. Tell her she needs to do it, then tomorrow you can discuss over anything she might find with it before bringing up the new task.

protected by Mister Positive Sep 11 at 11:46

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.