How to handle mentoring without giving orders?

Question

I work as a system administrator in North America. My team is relatively small, and of our team members, I am the most tenured.

The environment we work in is very complex, and there is no formal training for new recruits. Due to this, team members are expected to directly mentor new employees. We are in a flat org structure: I am not in a supervisory role, nor are there any line managers present for training.

One thing I struggle with is, being seen as the new employee's ersatz supervisor, when I am not.

I do not feel comfortable giving newer employees specific orders related to their tasks ("You need to do this X way, because of...", "Y needs to be done by Z date", "You need to look at this ticket now, because the client is upset with us"). As such, I make a conscious effort to be gentle in my statements, and purposely avoid asserting my (non-existent) authority.

While this works well enough for technical questions, or minor items, it is completely ineffective at communicating the critical of actual, business critical items (e.g, a high priority ticket, an outage situation that needs to be addressed immediately). The new employee (understandably so) wants me to say do it now, while I'm uncomfortable going beyond, you might want to look at this. Doing the work myself is an option, but defeats the purpose of training someone.

Edit: Deadlines are given by senior management, I would just be regurgitating them. Priorities are given in a general sense (outages trump normal day-to-day tasks). Actual task assignment and outage resolution is self-governed. We decide what we work on, and when, but are expected to understand how to make that decision properly.

In a team with a flat org-structure with no available management, how can one balance a false projection of authority, with the need to be an effective mentor, and provide clear guidance on the realities of the job?

Answer 1

The purpose of the kind of mentoring you describe is to guide the mentee in learning the things that the mentee's job calls for. Whether that's pair programming to learn the code base, instruction in how we manage tickets here, guidance on whom to ask for specialized knowledge for that obscure part of the product, or clues about political land mines to be wary of when meeting with that manager, your function is to empower the new employee.

If decisions about which ticket to work on next are part of this person's job, which sounds like the case here, then you should be providing guidance there. The way you avoid it sounding like you're giving managerial instructions that aren't yours to give is to use the language of mentoring.

For example, don't say "you need to work on that high-priority ticket now". Instead, teach the skills that enable the new employee to come to that conclusion directly. You could say something like this (context assumes you're sitting at a computer together looking at tickets):

We have this list of tickets here. Our policy is to prioritize the ones that are blocking customers. In those cases you'll see a "severity" value of "critical" or "blocker". Also, the "customer" field lists which customers have reported the problem, if any. You can sort the list by severity by clicking here, and this red dot next to the ticket ID means there's something in the customer field. From this list, what do you think you should work on next?

You'd then help the person navigate your ticketing system, looking at individual tickets for more details. This might give you a chance to point out particular customers -- "these three are all severe and affect customers; Customer X is actually one of our most important accounts and they're up for renewal soon, so I'd do that one first" or "yeah, that one does have a customer, but the severity is "trivial" and by the way, that customer calls us at least three times a week to complain about trivial stuff -- here they're complaining about an Oxford comma in an error message, for heaven's sake! You can let that one sit for a while...".

Framed this way, it should be clear that you are teaching, not managing. I've mentored lots of peers, meaning people I didn't manage but was senior to, and this approach works well for us.

Answer 2

You feel uncomfortable giving orders, but your role as mentor is to give instructions and information. Your feeling that tutoring someone and ordering someone around are two different things is exactly right.

• If you simply tell a new member "you might want to look at this", you fail to teach them how to recognize and categorize the severity of cases by themselves.
• If you avoid instructing new members on critical cases because you feel uncomfortable ordering them around, you fail to make them aware of a system they have to watch. They might learn the hard way when they are not aware that certain tickets have to be attended to immediately.

Instead, you should actually teach them how you do your daily work. In my experience, a learning-by-doing approach works well with most people. You should organize your lessons (no matter how small or big they are) in three simple steps:

1. Explain the situation. "See this ticket? The customer is completely blocked and complains that noone seemed to work on a solution for the last hour."
2. Explain what you want your colleague to learn, teach them the rules. "Whenever you see a ticket that implies that a customer is blocked or very angry with us, it's very important to fix it ASAP." If possible, explain why the rule stands as it is. "Angry customers might spread word that we are unreliable and influence new customers not to buy our product."
3. Make sure that your colleague understood the lesson. "So how would you prioritize situation X? What about this ticket, how would you prioritize that?"

That way you avoid assuming a dominant role by saying "do it this way".
You can apply the same principle to any lesson like technical issues, questions of the general work in your company or interactions with customers.

In the future, if you notice a new ticket with high priority, you can ask the new employee "Did you look at the new tickets? Did you notice the severe one?". From their reaction you can read whether or not they understood their lesson.

Answer 3

I think until the new employees are up to speed, you have to be the mentor by action and words. If everything is documented, you can give them the manual and say "follow these instructions. As a rule, if you finish a ticket, take ownership of a new ticket and do A, B, C. If you encounter something not in the manual, come over to my desk and we'll work through the ticket together."
You can then look at the weekly metrics to see who needs an extra hand.

None of what I've written is anything like "giving orders". It's explaining how to do the job.

However, if nothing is documented, then you are the manual. You are responsible for showing new employees what to do. Demonstrate firstly, then hand over control of the computer to them. Instruct them where to click if they are unsure. Follow up with them the next day, ask them to show you how they pick new jobs off the queue and how they complete the task. Offer suggestions from then onwards and ask questions to verify their knowledge.

Until a new employee is up to speed in the day-to-day tasks, don't ask their thoughts or opinions or anything. Leave that for when they know the job, and might be able to offer constructive criticism on procedural improvements. Otherwise you come across as too nice and not the 'Senior'.

All this leads up to the point of you saying "Team, we have a priority ticket in the queue. Who is able to switch to starting it right now? Chris? Samantha?" You should already know who is working on what before you ask - because when they give you a "ummm... not me." You can ask them why not as you've just reviewed their queue.
I used that approach with great success when I was doing 2nd and 3rd level support. Everyone knew that when I mentioned their names, that I had already picked out the two most likely people who were going to take the ticket. Pretty soon the team would yell out "I've got that one!" as soon as a critical task came into the queue.

Also, you need to talk to management about providing some funds towards a round of drinks at the end of the month, when you congratulate your team for a fantastic job, and give the top of the leader board a round of applause to show they're appreciated. Team building makes everything fun in a support role.