In a dynamic world of IT Systems Ops and DevOps, effective cross-training is a constant challenge. Skill-ups are essential for both individual growth and team success. Over many years of experience as a PM, manager, and mentor I have developed a philosophy that emphasizes self-reliance, initiative, and continuous learning. Found below is my (imperfect, but effective) personal manifesto on cross-training. In writing my own contribution to what I believe is key to developing proficient and empowered teams, I have seen what does and doesn't work. Below is my own still-evolving approach that has had success...
Teaching the WHERE or the WHAT, Not Always the WHY or the HOW
I can provide you with the WHERE or WHAT—system documentation (server information, IP addresses, and other essential resources needed to begin task work, or troubleshooting); however, I won't always have the time to delve into the WHY (a technology config, decision made, etc), nor the in-depth HOW of every process. We are so busy everyday documenting the WHAT (function) and the WHERE (location) info items I describe above, that it leaves precious little-to-no time for writing deep explanatory tutorials with click-by-click or CLI steps in a procedure: that is where your own skills-growth must rise to the occasion.
I am talking about First Principles training, something each of us in IT or DevOps must always pursue on any area of tech that we are operating in. First Principles helps us learn the fundamentals, and are what you need before any mentor can really help you in the knowing of the How and Why of any technology you are working with. Getting the nuances of an IT or DevOps system takes time because depth-of-understanding comes mostly from hands-on experience. Also required is your own personal initiative, and (again) time. While I can guide you to resources briefly cover fundamentals about a technology or tool, uncovering the why and how is ultimately your journey: and I cannot make the journey for you. I can only try to make be helpful for your learning, but I can't make it easy. Make sense?
Learning fundamentals of any technology is a path of personal exploration and practice, sometimes on your own time. Taking your own time to push through learning First Principles is how you get started at anything in this line of work, and the first steps to getting good at anything in tech! If you put in your time on basics, same as everybody else, then you will find the peer-help you want is more readily-available to you. Learning is a flow between personal time invested and collaboration: never one or the other.
But most people want ALL learning to be collaborative, most of the time: I'm sorry, but that will never be the case. The deepest, best learning is a combination of personal time and collaboration, and early in your journey it's probably 70% personal learning + 30% mentoring. So putting in your time personally in learning anything in tech (building your own lab, coding your own Powershell script, or configuring your own network/server gear) is how you get the fundamentals of this stuff! And getting fundamentals nailed is the way to even know enough to ask the right questions, to learn more! So First Principles (and taking the time to learn them) is everything when you are trying to get mentored effectively in any technology job. You, yourself, and learning those First Principles are the gateway to mastery of anything, always.
And if you don't have that kind of time (and I get it, I truly do) -- you at least owe it to your teammates to train-up to a point where you can at least use system Documentation (the where and the what) as best you can to independently contribute. Just understand: if you don't have time for skillset-growth in an area -- no one owes you their time away from their own tasks...to help you fill in all of the blanks, all of the time.
Setting Clear Expectations and Providing Support
We're all adults and professionals at work, so senior engineers and mentors' Job 1 is to trust in your ability to take ownership of challenging tasks, and of your fundamental skills-development. But a good Team Lead, manager, or mentor will always set clear expectations for outcomes needed on a task, and tech you will work with. And they should always ensure you have the tools and support you need; however, I expect junior engineers to begin the work without requiring a lot of immediate step-by-step guidance or hand-holding. This may sound sonewhat harsh or flip, but understand -- I want you to bother with getting stuck first before seeking help! Needing numerous questions asked/answered at the start of a task is not helping anybody. Dive in first!! Explore and take initiative to solve problems independently, and then seek assistance when needed. This leads to better support from your local SME and teammates! In Enterprise IT and DevOps, your performance is directly-measured by outcomes and accountability -- and part of accountability is working independently (at least at first) toward the outcome or result you are trying for. Fair or not, being a self-starter is your currency for being able to call-in enthusiastic support and assistance from other skilled team members!
Embrace Challenges, And Seek Help When You Get Truly Stuck
Some people are uncomfortable starting something new, or jumping in cold. They are afraid they'll look dumb, or unknowledgable. That's human, but understand: challenges and discomfort are opportunities for growth! So as a mentor I always encourage reports or teammates to tackle obstacles head-on and make a genuine opening-effort to overcome them. If you find yourself truly stuck, exhausting resources after you start -- I'm of course there to assist. But remember what I said above about currency -- when you come to to a good mentor for help, they will always ask what you've already tried first. This approach ensures you're actively engaged in some kind of problem-solving process and were learning.
Remember that independently trying first is everything in troubleshooting and learning: joyfully get stuck, do it with zeal! Because that is where the real learning happens in tech jobs, and where geeks like myself get motivated to enthusiastically help! If you ask for help without having tried much (without getting stuck first) we're going to have a chat, and you're probably going to receive this blog post. 😂
Pro Tip: The secret to getting enthusiastic support from your local SME or uber nerd is--trying to solve the problem independently, and be ok (even excited) to get stuck first before firing-off an email thread or asking for help. If you operate this way, the help and support you receive is fierce and powerful. If you don't, the help you receive may be unmotivated, uninterested, and sometimes tired.
tl;dr: Being a self-starter (and putting in the time, first, to even get stuck) is your currency for being able to call-in enthusiastic support from your team!
Autonomy and Professional Growth
Once I set a clear expectation or outcome, I'll step back and let you do your job. No mentor would ever do otherwise, if they care about you learning. This autonomy empowers you to develop your expertise and confidence. I do you no favors if I am doing something for you immediately. A deeper understanding of our systems (the WHY and the HOW) is best gained through experience, persistence, and self-directed learning. Going straight to "help!!" teaches us nothing.
Taking Initiative for Your Own Training
While I'm not responsible for always identifying the external training you might need, I fully support your professional development! If you discover a compelling training opportunity from a certified third party that relates to our work or where you can improve, bring it to my attention. I'm always open to considering valuable resources that can enhance our team's capabilities. That said, it's also not my job to set up educational curriculum, either: I need you to honestly assess your own blind-spots and identify technology areas you yourself are interested in learning. Do that, and I will fight every CFO and C-Suite for training budget funds to get you resources. Don't and...well, I got my own self-learning and training goals to attend to. Come see me when you find something you're passionate about learning, something exciting and of value for the team!
Take-Aways
If this all felt like a "teach a man to fish" talk, it very much was. 😉 I believe in throwing the fisherman right into some waist-high water, to catch a few fish on their own, before moving on to the big fish and angler tricks. I do neither of us any favors if I am just doing "cross-train theater": show and tell, such as "click here / type that", before you even understand the fundamentals of what I am showing you. 😉 But if you're game, and you put in the time it takes learning first-principles of something, some great things will happen and your teammates and mentors will cheer you on!
To foster a team environment where everyone takes initiative, learns proactively, and contributes effectively -- I believe people must leave their comfort zones, to build confidence. I do this by specifically not documenting deep inanely-detailed HOW documentation (which is a symptom of internal skill issues, usually) and having Process Pocumentation be brief and augmented by System Documentation. Team leaders should always lead by example here. Help enthusiastically, but always always first ask what has been tried. If we all aren't continuously learning, we're failing ourselves and our team mission.
Last tl;dr: by focusing on self-reliance and continuous learning, we actually all grow together and meet the challenges in our field head-on. Embrace this approach, and you can work collaboratively on powerful teams that achieve amazing outcomes and shared success!