How do I make an intern understand the importance of reporting issues?

Question

So, I have an intern/junior at work (the positions are rather fluid) who hardly reports back when issues come up.

For example, they had a bunch of task where a script essentially halves the workload per task. One day I randomly chat with them to see that they aren't using the script but instead doing things by hand, introducing technical issues and significally slowing down their output. I asked "Why aren't you using the script?" and they said "Because it isn't working. I didn't want to report it to you because I thought you were busy and I didn't want to bother you." I said that it was just a quick fix for me and that it's always worth asking me when running into issues because they are usually quickly resolved and that they should never be afraid to ask - especially because not asking can cause even more problems.

They still continued to just "work around" issues they ran into. I'm not the person responsible to quality check their work, in fact we currently have no one in place for that, so the only way I find out is when subsequent departments come to me to ask me why the task is done unusually or incorrectly. (I'm the unofficial go-to person for all problems my collegues run into, whether it's related to my tasks or not).

Now my supervisor has tasked me with introducing them to what is essentially a quality-checking task. The whole point of the task is to report when you run into issues. On the one hand I hope that this could be the right practice to condition them to report things back correctly, on the other hand I fear that we will run into a lot of trouble if they again silently decide to just "fix" a problem themselves.

I will point to the importance of reporting everything back when I brief them, but I'm not sure if it will be enough. Do you have any suggestions how to best convey the importance of this communication and how quality can be ensured if it's not my job to check their work but I have to fix their issues when their tasks are sent back from subsequent departments?

Update: They approached me telling me that they are nervous of having a QA task, aware of their shortcomings. Which to me shows that they are willing to work on it and communication will improve. I ensured them I'm there for all questions and make sure that they'll learn it. So the solution in this case came by the intern taking the initiative - but thank you for your quick and helpful answers!

Answer 1

When people I mentor start to hide problems and come up with creative workarounds rather than asking for help, I know that I haven't done enough to make them feel safe to make mistakes and ask for help.

To bring them around, I check in more often, ask about their accomplishments, and work alongside them on a portion of the task. If necessary, I will spend the day at their desk working on their project. Yes, it does mean evening work for me, sometimes.

If they mess up, I explain that it's my fault for not being clear and rehash the task (even if it's the 5th time) - it's not their job to know what I don't tell them. It is my job to make sure they understand the task, how to do it right, and how it fits into the project.

I also reinforce why I want things done this way. If they continue to deviate from process, I try to uncover why they think their way is better. I also ask them to suggest process improvements and ideas for new processes. A fresh perspective is invaluable!

I stress that their task, while small, is important and that it is their responsibility to do it right, even if they have to ask me for help every step of the way.

Basically, I try to make them feel that their job is as important as mine and that when they do it well, they help me immensely.

Answer 2

There's a distinct possibility here that the intern/junior is trying to avoid being seen as the person that can't handle any issues on their own and needs babysitting through everything and that they have simply gone too far. It's a difficult line to walk when you are new and inexperienced and them not quite getting that right needn't reflect on their overall quality.

What I would suggest you need to do is ensure that they feel safe to bring any issues to you and that if they can't resolve an issue themselves within a reasonable timeframe (obviously this isn't a fixed number and will vary depending on the task) that it's absolutely the right thing to do to come to you and ask for assistance. Explain that yes you are busy and that sometimes you won't have a lot of time to spend helping them but that shouldn't prevent them asking and that even if you have to say you can't help right now you'd prefer them to raise the issue and ask so you are aware of it.

Answer 3

Someone will probably write a better and more complete answer but here is a start.

I will go for something along setting who is responsible of what. You can't know if you have to report something or fix it yourself if you don't know what you're responsible for.

You are the one responsible to deliver that script that is supposed to do the job it was written for. If that script doesn't work it is your responsability to fix it, and unless they got approval from someone, that is probably not them, that have the authority to say "work around it", they're not permitted to do so.

In an organisation, with QA, it is important that everyone keep to their role and don't start to walk on others without even telling them.

Answer 4

I suggest a daily e-mail status report. You can give them a skeleton that has headings for things like problems encountered, and when you were notified of the problem.

When appropriate, thank them for bringing an issue to your attention. That will reassure them that reporting issues is the right thing to do.

If they have to e-mail you anyway, they may not feel inhibited by not wanting to bother you.