Knowledge Sharing and Training

From cross-training in the military to wanting to share with others some of the exciting things about network engineering or IT as a whole, I've always seen knowledge sharing as a win-win. I would say it tends to strengthen your understanding of something when you can teach it to others. Simultaneously, the person learning what you're teaching gains valuable knowledge about a subject from someone who has enough knowledge or experience to teach about it.

I remember on one of my first military exercises, being a radio guy setting up large radio antenna masts and tuning radios so that command and control operations could be achieved by commanders over a fairly large distance, usually double-digit mile distances depending on the conditions, which was an awesome thought! Or setting up these same radio stations as a relay where the max distance was achieved and someone needed to pick up and relay the radio traffic from that max distance and shoot it even further to its distant end. And aside from flying a helicopter or shooting rounds out of a tank, you couldn't convince me there wasn't a cooler job than this at the time. That is, until, we started using satellites. Now we were shooting to a dish in the sky much further away than the radios could reach and then back down to some place on earth. How cool is that?! We would have competitions to see who could get their satellite set up faster. These satellite terminals would also connect to the internet and you could get Google in the middle of nowhere. But the setting up of the satellite is where my job ended. And then someone who could set up a network and connect it to the satellite were the ones who really got the internet to work and made it possible to actually use the connection we had established. I REALLY wanted to know how to do what they did. So it started as just trying to hover around them and shoulder surf. Then, they would notice me taking an interest in it and show me a few things. A command here and some network connections there, I felt like a hacker or something typing into a black computer terminal screen configuring these network devices. And finally, that team wanted to send me to their school to learn, fully, how to do what they did. I could not have been more excited. Some people in the class thought the material was dry. I enjoyed every minute. And when the class concluded and I got a certificate showing that I knew a thing or two and I was ready to make things happen on our next exercise. And when the time came, I set up my radios AND helped set up the network. This was so fulfilling, to know I could do my original tasks but I could also help the mission by becoming a multitool and helping in other areas. This was great for many reasons: command and control had their comms in quicker and further, my radio team was confident in their abilities and the satellite/network team moved more smoothly. I removed some of the burdens on my networking counterparts and they had confidence I knew what I was doing and could concentrate on higher-level tasks. Win-win.

So now that I have moved over to the civilian side, I love it when someone from maybe a helpdesk position asks about what I'm doing and why: "HECK YES, get over here, do you have a pen and paper? Here, use mine! Check this out!". If it engages them and maybe they want to see more, great. If maybe it's not something they're interested in, also great. They took the time to poke at a potential interest and possibly learn a new skill. I was definitely curious about programming at some point. It will continue to be an important part of network engineering for the foreseeable future and for IT in general, but I am not naturally interested in it after a few college courses. I can do it and have done it for work, but I'm not excited about it. And I think that's okay. But I tried it. Someone took the time to explain it, I applied it and, personally, was not enthused. But maybe someone else will because they tried it. So, should this be made formal in some way? Should there be a curriculum and a schedule and a classroom? I'd say it wouldn't hurt to have both. I learned what I love now through both informal and formal settings. By shoulder surfing and getting pointers and by sitting in a classroom led by an instructor. I'd say they were both helpful. For some, the formality can feel like grade school again. They're going to be tested and that makes some folks nervous. But at the end of it, they could achieve a certificate or some other credentials showing that they passed. Informal settings are more relaxed. But maybe they don't have an objective and the learner is just seeing what it's all about. I think this is where interest is fueled. You get to see the cool stuff happen but don't have to execute it yourself or be on the hook for not doing it correctly just yet. It's the monkey-see portion of monkey-see-monkey-do. It's equally important in my opinion.

And now that I'm working on a curriculum to help others in help desk positions learn network engineering, I see the importance of an introductory portion of the class where demos are conducted. Maybe they are curious about what happens to those tickets for network issues they escalate. What is the next step and how might a network engineer approach its resolution? Why that approach? If possible, solve a ticket live right in front of a class. Monkey-see.

Once they have seen how and why, the class might move on to hands-on or some sort of OJT instruction. Effectively, the training wheels come off but the instructor is still holding the seat upright. And after enough time doing these things, maybe they feel confident trying these tasks at-will or as an intermediary to the network engineer (insert "Associate to the Regional Manager" joke here for all the fans of The Office); like a pre-escalation or, sub-tier. Now there exists a full circle where that person who had the interest to learn more about network engineering or was trying to move into network engineering is now performing that work. And I would say being able to do that is so fulfilling for the learner, as a learner myself. And this method could be implemented between every "step" in a career path. There are limiting factors like everyone's time and also the resources that are taken from one task and shifting it to another. But I would argue that the price of this shift is more than recouped when the organization now has defined roles AND continual learners overlapping, at a minimum, dual roles. Things that would usually be simply escalated may start being resolved or troubleshot at a lower level leaving more time for those at senior levels more time to work and accomplish those higher-level objectives. And learners get to see and do what is the next step for them in their careers.
Win-win.