In network engineering, a great opportunity is to be able to mentor someone else. Mentoring is that art of teaching someone else what you know. In that knowledge sharing, you help that person become a better network engineer. Or you teach someone who isn’t a network engineer something about networking. At least, that’s the general idea. Depending on who you’re working with, the mentoring experience can be wonderful or frustrating. Sometimes, it’s both.
Mentoring isn’t always altruistic. Oftentimes mentors are trying to clone themselves. They want someone else on the team that they can rely on to think and respond like they do, because having a clone takes some of the pressure off. Networking can create an enormous amount of stress on technical leads who are expected to proactively manage networks, plan hitless upgrades, propose complex design changes, work within a budget, and meet business deadlines. Further, tech leads often serve as top-tier troubleshooting for escalated issues, usually complicated, stress-inducing brain-busters no one else could figure out. Any amount of work that can be delegated to someone else in the organization that shows potential helps put off the tech lead’s burn out. Mentoring is a tricky business, though.
(1) Not everyone wants to be mentored. In the many IT teams I’ve been a part of, I’ve found that there just aren’t that many folks interested in getting better at what they do. As long as they are doing what’s expected, they are content. Learning something new is a frightening process for these folks, as it introduces a potential for failure. Or for more work in their workday than they would like to have. Mentoring these folks is a near impossibility. You can show them what you think they should know, explain the answer to their oft-repeated questions (so that they won’t have to ask again), but it’s mostly a waste of your time. They just aren’t interested.
(2) You can come off as a pompous ass. If you are a self-impressed egomaniac, that will almost certainly come through when mentoring. That will reduce your effectiveness as a teacher, because no one wants to learn from the engineer who thinks they are the best thing to ever happen to the data center. “Let me tell you about the time the whole company was down, and I rode in on my white Aeron chair to save the day with nothing but a console cable and an old DEC VT100 terminal…” Even if you have a realistic view of yourself, uninvited mentoring can come off as showy or disrespectful to the person you’re working with. Attitude is everything. Make sure you are using words that identify yourself as the equal of the person you’re trying to mentor. Wording that makes you seem like a superior know-it-all will sour the teaching opportunity.
(3) You can’t expect people to “get it” the first time. One thing I’ve learned as a parent is that my children don’t learn something just because I taught it to them once. They learn more effectively through their own personal experience. In the same sense, a mentor must have plenty of patience. For example, I can’t tell you how many times tickets have been routed to me to deal with things I am not responsible for (and usually couldn’t take care of if I wanted to). Instructing the person on where the ticket should have been routed doesn’t necessarily mean that the next time the issue won’t get misrouted to me again. By the same person. That’s just the reality of dealing with people. The best way to keep your patience about you is to realize that you didn’t get it the first time, either. So relax. Anticipate that mentoring is a process, not a one-time intervention. Expect that you’ll have to go over the same information multiple times as a natural part of helping someone learn.
(4) Documentation will help. If you are a networking technical lead, there’s a good chance that the entire network is in your head. If you’ve been working on the network for some period of years, you are doubtless familiar with all of the key components by heart: VLANs, subnets, WAN circuits, bottlenecks, security devices, remote offices, core switches, etc. There’s an equally good chance that no one else is, and almost certainly not someone you are mentoring. Therefore, documentation is going to help the mentoring process. Network diagrams are an invaluable real-time learning aid, and are subsequently useful to reinforce what you’ve taught. Clear, simple standards documents & templates help reinforce the way devices should be configured. If the best you’ve got for documentation is what you’ve got in your head and a whiteboard diagram that has said “do not erase” for the last six months, then build documentation to support what you expect someone else to master. Otherwise, they’ll struggle to reach the level of expertise you need them to have.
(5) The payoff is a stronger team, not a weaker you. Some folks don’t like to mentor, because they feel threatened when someone else knows some of what they do. They feel that their unique knowledgebase is a secret to be preserved because, in their mind, that makes them invaluable to the organization. If they share their knowledge, that somehow reduces their value and puts them at risk. Nothing could be further from the truth. Reality is that if you’re the oracle of all network knowledge, you’re not invaluable as much as you are a bottleneck. You’re probably working too many hours. You’re probably stressed. You’re probably burnt out, or headed that way. You’re probably moody and unpredictable to work with. Make yourself more valuable by sharing with others in the IT team what you know. Explain how networking works to your virtualization peers (believe me, they’re struggling to understand it). Support and participate in cross-functional groups. Spend time with that up-and-comer. Teach others how to perform routine networking tasks. As you mentor others in the group, the team benefits by becoming more knowledgeable and stronger. You didn’t outsource your job; you raised awareness of your expertise. This helps the rest of the team understand just what you’re bringing to the mix. That makes you more valuable – not less.
About Ethan Banks
