Long meetings (6-7 hours a day): Being "babysat" by supervisor

Question

I hold a PhD in mechanical engineering with a 7 year background in self-guided, self-paced research including 2 years as a graduate level course instructor and a subject matter expert for various engineering projects in a university setting in the United States.

For the last 10-11 months, I am working in a research industry in France where my task is to debug C++ spaghetti code written over a period of several years by my current supervisor. It is a team of 2: just I and my supervisor.

Diurnally, I am posed with a "bug of the day" to get out of this C++ code. My supervisor generally gives me about 15-30 minutes to solve it and then accosts me about whether or not the task is completed and then rinses and repeats this until the end of the day.

Off-late, my supervisor has been holding 6-7 hour long "meetings" where instead of giving me the usual 15-30 minutes on my own, we both face a computer screen and he furiously debugs code while I sit besides him and look on. During this time, he quizzes me now-and-again on whether or not I understand what he is doing. To be completely honest, I understand what is going on only about 20-25% of the time since I haven't written the code myself and am not given time to get familiar with it. I make this clear to him but is met with exasperation on his part and his pointing out that my programming skills are lacking. The other 70-75% of times, I know that if I spend enough time with the "bug", I'd be able to figure it out. Alas, I am not granted such time.

There are no deadlines on paper, except that my supervisor tells me that "it is urgent". I have approached this subject of "urgency" with him and he has usually given me deadline dates that he seems to pull out of the air (I have missed several dates and have been met with no consequence).

In fact, I was hired for a certain job description which I am not doing at all (I was hired for non-programming equation development and have been thrust into programming). This I have approached him about too and was met with a brusque "change in plans" reply. I have also noticed that there is significant scope creep in this programming project. As having had that on a regular basis during my PhD (scope expands when you don't know what you are solving, such is the nature of some types of fundamental research), I suppose that is OK in industry setting for research.

HR has been lukewarm in their response to this issue of non-conformation to job description and lack of milestones. They say they understand the problem but they haven't done too much to enforce a better professional attitude on his part. He is a "permanent" employee whilst I am "temporary" (on-contract) and as I understand, "permanent" employees in France get a significant leeway in their approach to work and in turn their employees.

I understand that sometimes one is faced with difficult positions such as this and I would like to make the best of it for my own personal and professional development. How do I tell him in tactful fashion that being babysat for 6-7 hours a day is not really a good use of anyone's time and that just letting me do the job during that period of time may be a better solution? Is this something I should have just expected in industry settings since this is my first sojourn into industry?

Answer 1

The supervisor's attitude seems pretty bad, but as a manager the following points stood out to me:

1. For the last 10-11 months, I am working in a research industry in France
2. We both face a computer screen and he furiously debugs code while I sit besides him and look on
3. He quizzes me now-and-again on whether or not I understand what he is doing. To be completely honest, I understand what is going on only about 20-25% of the time since I haven't written the code myself
4. The other 70-75% of times, I know that if I spend enough time with the "bug", I'd be able to figure it out. Alas, I am not granted such time.
5. I have missed several dates and have been met with no consequence

It looks to me that you haven't picked up the work and are still struggling. My worry would be that even though you are getting knowledge transfer (even far from ideal kt), you are still not getting to grips. The progression of your supervisor from dealing tasks to pair working indicates his concern. I would want to ask you some questions:

1. Are YOU asking questions during the sessions to help you understand?
2. What do you think is an acceptable time to diagnose a bug, how different is that to your supervisor's? Do you suggest a better timebox for your bug investigations if 30 minutes isn't getting anywhere ("I'll spend an hour/2 hours/half day looking at this and get back to you")
3. Do you ask for timescales (ideally in writing if there are issues with missing them), do you feedback to the supervisor when they are being set to something you can't deliver, or do you wait until they are about to hit?

As bad as the way your supervisor is managing you, you sound as if you're happy to just sit back and complain. People who get on aren't managed, they manage upwards.

Having worked with PhDs before I've seen similar issues, usually due to the person being used to taking "as long as it needs" to complete a task. Given the nature of a PhD this is normal, but in business (even research) there can be more of an urgency to get things done. The deadlines may sound arbitrary to you, but you might not know the full story (or it may be based on what the supervisor is telling his boss).

As regards asking your supervisor not to babysit you, I don't think you can. It sounds like you aren't in any position of trust. You need to work on this and on getting to a decent level with the C++ code, things should then get easier, but make sure you are driving the timescales AND make sure YOU deliver.

Work is about managing expectations, either what you will deliver or when you will deliver. It sounds like you aren't doing either.

Answer 2

It seems quite likely to me that these are not meetings, but pairing. He is trying to teach you some of what he knows. You were presumably hired for a reason, perhaps to reduce his workload, perhaps to improve the software beyond its current level. I suspect he believes that if he continues to "show" you how to do it, and to "pair" with you, that you will magically be able to take over soon.

I am not sure this is salvageable, but assume you want to try, I would suggest attempting to achieve the following:

• a list of bugs, enhancements, and stuff that was left for later. Not to be handed them one at a time, but to work together to create this list. Keep it in a work tracking system, or a spreadsheet, or on a piece of paper, but have a list
• an agreement that you will spend so many hours a day trying certain ones yourself (that you choose) and so many hours a day pairing on the ones where you think you need his help
• an agreement that you will type during pairing. He can read and think and remember and such, but you will type. When you wonder "where is that defined?" you will have to ask him out loud and he will have to answer you out loud. This will be slower at getting the bugs fixed than him typing, but faster at getting your knowledge of the code base up

I also recommended you purge your vocabulary of words like "baby sitting". If you think you're being treated like someone more junior, you need to start producing like someone senior. That's the big benefit of the list - it lets you pick off a few things you can actually take care of yourself. The more you do alone the less he will subject you to what I am quite sure is an improvement program.

Answer 3

sleske's answer touches this a bit, but I just wanted to address this question:

Is this something I should have just expected in industry settings since this is my first sojourn into industry?

How your supervisor is handling it isn't normal, but others have covered that so I won't go there.

As far as work in the industry goes, this is definitely not normal. When you sign up for a certain job description, you're perfectly reasonable for expecting to work on the kinds of tasks outlined inside it.

Your post doesn't scream enthusiasm for software development, and you even state that the job description was non-programming. And given that you still feel out-of-the-loop on the software after almost a year, software doesn't seem to be your calling(or this employer is absolutely horrendous - could be both). I'm sure you're well aware that you're not a software developer at heart.

I think you need to fight for your original job description and tasks related to it, or find another job. Just because C++ doesn't look like alien scripture doesn't mean you're qualified for the tasks you're being given.

More importantly, if you want a career related to mechanical engineering, you're actually hurting yourself by not doing tasks related to it. You're missing out on learning the tools of the trade, and by the time you reach the "5 years of experience" mark, you won't have 5 years of experience with your tools...at best you'll have 4 if you change things up right now.

Answer 4

The supervisor has written the code over the last six or seven years. It is obvious that he has a lot of affection for it and doesn't want you to touch it.

I can actually not imagine anything more useless to learn about this codebase than sitting besides someone who is happily typing away on the keyboard. Even at the level where your eyes try to identify things on a screen, having someone else controlling scrolling, paging up and down, makes it impossible to follow anything.

In that kind of environment, you are just wasting your life. From the company's point of view, you are also wasting their money. From the supervisor's point of view, you are wasting his time as well (however, he is the only one to blame for this situation, so he's the only one that I don't feel sorry for). I'd recommend searching for another job while you still have your sanity, and then quitting when you found something new. You might check with HR if there are any other positions at the company, but I would probably prefer to start somewhere fresh.

We can all speculate about the exact motivations of your supervisor (and there have been several reasonable speculations), but I'd say that this job is a dead end for you.

Answer 5

To answer the last part of your question first:

This is a horrible way of working, and is not something to be expected in a (healthy) company - even though it is not as uncommon as one might wish.

As to how to cope:

This is difficult. It seems that your boss' management style has multiple issues (most importantly, lack of planning and micromanagement). One way to tackle this might be to point out more or less what you have described in your post. As usual, do not accuse him (or any one else). Just explain how you would like to work, and why you feel you'd be more productive that way.

This may help to allow you to work in a way that makes you more productive (and hopefully happier).

However, seeing the multiple problems you describe, personally I'm doubtful whether you'll be able to change your situation significantly - changing people's work habits is hard. In that case, you'll probably have to change boss, which might mean changing your job. But that's a decision only you can make.

Answer 6

Your supervisor is hiding a few things from you and is deliberately keeping you in the dark. It should be obvious to you, if you re-read your own post, that he has embarked on a major humanitarian project, that is, keeping his butt out of the fire.

I see you're being compelled to sit with him as some kind of parody of pair programming, because you are doing zero coding - you should be doing 50% of the coding. In pair programming, both halves of the pair know exactly what they want the code to do. In your case, you are at least 80% in the dark, and I am not sure that your supervisor is in full control of his own code, given that he seems locked in some kind of life-and-death struggle with it.

You need to take a much more active part on the coding process. It doesn't look like you will fully understand what's going on when your supervisor finishes fixing his own code, but you should at least aim to achieve a much higher level of understanding of what he is doing, what he is doing and how he is doing than what you have right now.

If you say to him that you understand what he is doing and you actually don't, that little white lie will blow up in your face if you are ever tasked to do anything with his code on your own at some point in the future. Ask him questions, try to get at least a general picture of what he is trying to do, because if you have to meet deadlines and milestones with the understanding of his code that you have know, working on his code could well be a Resume Generating Event (RGE) for you.

Answer 7

Almost all these answers provide you with solid advice that you should listen to as you come out of academia and into industry. @TheWanderingDevManager provides especially clear advice for software.

Yet I think they muddy the issue a bit for you because they miss two important points:

(1) Your "supervisor" is not a supervisor but in a highly skilled Direct Output (DO) role. He is not a manager; he is a DO, so he is not managing you in any way. Comments that imply that he is will not be useful in this situation.

(2) You are a contractor. To employees, you are simply a service person who should do whatever he is told. This is why HR will not do anything. You are not an employee and therefore have no employee rights.

These mean that you are not his employee and he is not your "supervisor". What you are doing is called an "Assisted Direct Output" (ADO) role. Your job is to help him achieve his outputs (getting this software working). This makes you his Assistant, not subordinate.

He sounds like he has an advanced degree but is not considered good enough at the field to do the work, so he's stuck writing programs to support those doing the work.

This does not make him evil. He thinks that you should be working at a higher output, as has been said. He is "pair programming" with you because he is trying to get you to work out. You are resisting this mostly because this work does not stretch you in any way. You are both bored and overwhelmed.

This is not going to get any better for you because in the end you don't want to do this type of work, even if the DO suddenly became different. Follow everyone's advice and get a job in your field, then do what @TheWanderingDevManager says because he's right. And leave on the best terms possible with the DO and his managers: really work at this.

(I say this as someone who has hired and managed PhDs and ABDs, worked as an ADO to PhDs both as employee and contractor, led dev teams, managed DOs and managed managers of software developers.)