Your IT Career as an RPG
Editor’s note:
I’m absolutely thrilled to have my friend and giant in the IT community Matt Bradford as a guest author this week. Matt reached out to me after my April 7th post and had a fantastic idea for a blog that I thought was just too good to leave as an idea. To my great delight, he offered to write the post that follows. Matt is a Senior Technical Marketing Manager at VMware, focusing on vRealize and Cloud Management content. He is a co-host of Cloud Management Monthly, he runs the vExpert Cloud Management program, and just launched a bi-weekly live stream called vRealize This Live! You can reach Matt on Twitter at @VMSpot.
Previously on Transformational Technologist, Steve Athanas described the parallels between playing a video game about pirates and working as a team in the world of IT. To summarize the post, Steve describes an epic battle between two pirate ships where his crew find themselves on a sinking ship that's on fire, with no sails… all while taking on heavy cannon fire. With a massive crew it's entirely plausible that each of these catastrophes could be tended to, but of course that's not the case in Steve's story. Instead, they need to balance doing it all just enough to get away from the enemy. That means mending the sails and bailing just enough water to get moving, but not before patching the holes in the ship. And what about the fire raging in the galley?
For any of us who've worked in IT long enough (and probably any other industry for that matter) this sounds all too familiar. Having too many 'priority one' tasks and not enough hands on-deck means you either acknowledge that you can't tend to every task, or you run yourselves ragged trying to. The only rational option is carefully measured prioritization. Placing your crew's focus on the tasks that are critical to the ship, and tabling those that aren't - all while being fully aware that some things will suffer as a result.
It’s a very insightful observation from someone like Steve who oversees the ship. He is more concerned with the bigger picture and what gets done rather than how each task is accomplished. He's likely not going to be concerned whether his crew is bailing out the ship with wooden buckets or chamber pots, so long as there is less water inside the ship than before. On the flip side, the crew is for sure concerned with the big picture of whether the ship stays afloat – after all, they’re on it. However, their primary focus is on the minutia of working out the most efficient way to get each task done.
Making sure tasks are done efficiently includes looking at those around you and considering their strengths and finding a good balance of talents. Because let's face it: when you're gearing up for a raid you don't want everyone to be a paladin. I mean they can't even wield the helm of disintegration for crying out loud! In the world of role-playing games, classes are the foundation of any character. They describe the underlying traits and behavior upon which you build your character. It may help to think about a recent project or task that you've undergone. Reflect on who was working with you and consider what class each character - I mean team member - would be.
The adventurous Warrior, who hates meetings and anything that gets in the way of forward progress. We're here to get work done after all!
The mighty Wizard, capable of casting incredible scripts to clear any technological roadblock. Usually carries a printed copy of Stack Overflow under their arm.
The shifty Bard, who can sway the strongest of wills. This is who you want negotiating for that budget increase.
The invisible Rogue, who can make changes undetected. Change management is just a bunch of bureaucratic nonsense anyway.
The fierce Barbarian, friend of the warrior and lifter of heavy things. The finisher of tasks.
Now, consider which class you are. Do you feel like you fit into any of these roles? Or are you the shapeshifting Druid, able to be whatever your team needs? The Druid is a special class that we’ll discuss later.
These classes describe one important aspect of you and your teammates: your personalities. Working with a group of people containing the perfect blend of personality traits can make or break any job. Personalities are not the only thing we should be concerned with when thinking about team composition, though, as character classes do not dictate technical skills. Just being a rogue doesn’t make you a skilled Linux administrator, does it? Just like in the game, you will pick up skills as you progress through your levels of play; your skills come from a series of decisions you’ve had to make over time, and these are your talent trees.
None of us were born with a keyboard in hand and knowledge of BGP routing. These things take time and decisions must be actively made to learn these skills and to grow our talent trees. A few examples of different talent trees would be networking, cloud computing, databases, microservices, and hardware. Many of us started developing our talent trees well before we thought about IT as a career. Most IT Pros I know started with hardware, as it’s often the most accessible option for enthusiasts and therefore tends to be the first. We started by learning the basic components: the keyboard, the disk drive, the monitor, and the sound card (if you were lucky) and grew from there.
Maybe you upgraded the family computer and gained skills in loading drivers and avoiding those annoying IRQ conflicts. Many of these skills can be acquired outside of formal learning. For example, my father used to repair Commodore VIC-20s and 64s for the local schools which exposed me to integrated circuits and passive components.
Many schools offer varying levels of formal programming classes, so perhaps this was your second talent tree. I remember early on in school learning how to program a little turtle to draw graphics in Logo. My father also taught me BASIC from a very early age and we had books full of games that we bought at Radio Shack. I’d spend my weekends typing out the lines of code in the book on our Commodore 64 and after some time a fun game would appear – though, honestly the programming was the best part. As a result of these experiences, I would turn in text adventure games that I wrote instead of the book reports assigned by my teachers. There were also more advanced Java and Visual Basic courses we could take in High School and College.
Right there we already have two talent trees budding before the age of 18 that will pay dividends later in life. Perhaps you had even more trees starting to grow. It seems that anything is possible until we learn that time is our biggest constraint and for many of us means we will only be able to focus on a few talent trees rather than the entire forest in order to develop any of them deeply. Nothing is immediate and time must also be spent learning the pre-requisites. For example, you need to learn about partitions and file systems before you can jump in to learning about enterprise SAN storage and LUNs. In the world of IT, it’s also a given that these talent trees will always sprout new branches and trees focused on entirely new disciplines will eventually appear.
As time goes on, we find ourselves converging our focus on fewer and fewer talent trees until eventually we must decide what final few trees we’re really going to focus on. If you’re lucky, this decision is primarily driven by your passion, but in most cases it’s probably a mix of passion and organizational necessity. Perhaps your team lost a valued member, and you need to fill the gap. Maybe it’s a new technology that will change the way your organization does business and maintains competitiveness. Or perhaps you’ve found yourself in a position where learning a certain skill will line you up for a promotion with a bigger salary. If you’re still in your early career, one piece of advice is to be mindful and deliberate in choosing what talent trees you’re investing in now, as this will alter the trajectory of your occupation massively ten or fifteen years down the road.
Let’s get back to the Druid – we haven’t forgotten about them, right? At one point or another, we’ve probably all found ourselves playing this role. Instead of investing heavily in a few trees, Druids spread themselves out in an attempt to learn it all. It’s a fun and exciting idea to step in and handle the networking on one project while also migrating AD to the cloud for another. After all, variety is the spice of life and who wants to be stuck doing one thing, right? The problem with being a Druid is that it has significant limitations in the long run. For the individual, they are generally spread thin enough that they aren’t the masters of any discipline, subjecting them to career risk.
Look at it this way: is the team best served by having an amateur designing a stretched layer 2 network? Maybe this is an attractive option in the short term to meet the needs of the project currently at hand. But eventually everyone may realize they should have contracted a master network architect to take the design in a different direction that will benefit the organization in the long run. One place a Druid may have an edge is on their resume. Having proficiencies in a lot of technologies can make them look like an attractive candidate on paper. However, hiring managers need to be conscious of Druids – and be sure they know how deep that knowledge goes. I’m not saying Druids are bad; many of them can be hired for a lower cost than a master and can be effective in the role over time. But don’t forget that they’ve only invested enough time to learn the pre-requisites, and mistakes will almost certainly be made along the way. If you’re willing to accept that risk, then hire away.
And lastly, let’s not overlook your various talent trees outside of your profession. Learning how to fix your car can benefit your troubleshooting skills which will have a positive impact across all your talent trees. Having hobbies like woodworking can give a buff to your happiness which also benefits your performance at work. Building relationships also gives buffs to your happiness and charisma and could pay off in better job opportunities down the road. Of course, let’s not forget the home lab as this is the training ground upon which you build your skills. Yes, your career can also be your hobby if you so choose, and if you’re really passionate. Consider your previous experiences. Have you worked in IT all along or did you have any jobs in other industries? What about college? Is your degree in computer science or something else? Think about the talent trees you developed through these experiences and how they might benefit your career today.
No matter what the game or the quest may be, we all have roles to play. Focusing our time building out a few talent trees while saying no to others is not an easy skill to learn. Just having a basic awareness of other talent trees is often enough. Time must be budgeted between your professional and personal life and learning to say no to distractions is critical to striking that balance. Otherwise, you may find yourself spending all your time at work and having none left to battle adversarial pirate ships or raid dungeons.
Questions for Reflection:
What class do you think you are? What class would other people think you are?
What talent trees are you focusing on to grow your skills and career? Do you think they’re the right ones?
Have you ever been tempted to be the Druid? How did it work out? Is there a role where you would actually want a Druid?
Why does Steve write blog posts? Why doesn’t Matt always write them? They’re like way better, right?
[Editor’s note: I’ll allow this last part, because I enjoyed the post so much. Show Matt some love in the comments!]