Showing results for 
Search instead for 
Did you mean: 
Create Post

The Just Us League

Level 13

The original Justice League consisted of seven superheroes: Superman, Aquaman, Flash, Green Lantern, Martian Manhunter, Batman, and Wonder Woman. In a parallel universe, there is the IT Justice League, a union of IT superheroes that aims to protect IT organizations and their users from the perils of application downtime, high latency, and IT disasters. As IT pros, we like to think we possess superpowers of our own. Sometimes those powers are used for good; sometimes for evil. Most of the time, we use them to keep our jobs.

To have a successful, long career in IT, you can’t operate in a silo. You simply can't accomplish organizational, global goals by walking alone. Plus, life's too short to walk the journey all alone. In other words, it's best to share your IT pains and gains. Moreover, most of us are neither blessed with innate talents like Superman and Wonder Woman nor are we blessed with endless resources and capital like Bruce Wayne/Batman or Aquaman. Heck, even with the greatest willpower, we can't create something out of anything like Green Lantern or morph objects based on our desires like Martian Manhunter. In spite of this, we still stand and deliver when called upon, such as when trouble befalls our applications. Teamwork, collaboration, and community make integrating and delivering application services a much easier and more gratifying experience.

This is where the challenge of the Just Us League appears. The Just Us League is one where everyone knows your name and you just fit in because it’s always been that way. But what if you’re not a part of the original Just Us League? How do you join? What are the rules for joining and participating in the Just Us League? What practical tips do you use to open the Just Us League to include new-to-you people? How do you incorporate the trust but verify modus operandi to make sure you sure you are nurturing vibrant and growing teams, collaboration, and community? Let me know in the comment section below.

Level 14

Wow... what a great way of expressing the issue.

I have always used the "trust but verify" mode.... Users understand that when I commit to looking at it, I will find the underlying problem, they also know that when the problem is identified or resolved, I will explain it in "layman's" terms so their eyes don't glaze over. Most importantly I treat the users and others involved in the issue with respect,

Lastly, an educated user community is key to obtaining trust in IT, that effort has always worked for me for "*ahem* several years", whenever I join an organization.

Hats Off to kong.yang​ for a great topic.

Level 15

Give a nerf gun to the new 'cadet' to welcome them to the team.   The following month or so after they need to earn their superhero nickname, usually based on something they do differently or a quirky habit or possibly something they did wrong.

Occasionally give them some love by filling up the battery compartment of their mouse with skittles or removing/hiding the wheels from their chair. Eventually you will be amazed and find out what their superpower is!


bobmarley​, that sounds like the format we use with probies in the fire service.

We use it as a tool to see how they deal with stress and frustration under fire (pun intended).

They learn from it as well....

Teach your children well, and they will not stray from the path.  (Or they'll be fired.)

  1. Select incoming people for their great interpersonal skills, not just their certifications.  They must have a personality you're happy to be with because that's part of their nature.  You'll have a hard time changing their personality flaws, or teaching them to get along with everyone.  Focus on personality first because you can train a good person to do technical things, but it's MUCH harder teaching a technical person to be pleasant to others.  It's a gift to find a person who knows how to to listen well, to include others, to never talk down to someone or not be confrontational, to be open to new ideas, and to be willing to sacrifice their own ideas for someone else's.   Start with good people.  This above all else!
  2. Introduce them to your environment from a high level, then drill down slowly into what used to be called "silos".  Teach them what they need to know to fix problems, do great designs, and to be free to think outside any boxes when troubleshooting.
  3. Alternately:
    1. Take them to the Layer 1 environment and have them work there, meeting line people and affected end users.
    2. Then move them up to Layer 2 and have them supporting VLAN's and switching.
    3. Introduce them to your Layer three, and show them how to diagnose and troubleshoot and configure EIGRP and BGP (or whatever alphabet soup you own).
    4. Move up the OSI model, introducing your newbies to protocols, polices, and the teams that work intimately with them, and the customers that rely on them.
  4. Show them where your documentation resides, and ask for their input on how to improve it.  Be patient when they ask about what may be obvious to you.  And have them start contributing to that documentation until they can feel they own a product and its support, and they've become the go-to person for that subject matter.
  5. Introduce your new staff to high level administrators and point out each others' strengths, so the Newb knows who signs their paycheck and who buys new employees and hardware and support contracts  Then C-Level has a name to go with a face when there's something that must be done.
  6. Teach your Newbs the Layers 8, 9, and 10 that are unique to your organization.  Maybe those layers are Budget, Religion, and Politics, also known as Funding, OS/Hardware preference (Apple vs. Android, PC/Windows versus Linus, IBM versus you-name-it, SQL versus Oracle), and the inner workings of the pecking order so no one is snubbed or slighted (CIO/CEO/CFO--you don't want to ever see or cause a C-Level argument among them).  These upper levels "areas of sensitivity" could be as simple as who got the corner office with the windows, or Ford vs. Chevy, or anything rational or irrational.  Teach your new person to respect every person, and to listen twice as much as speak (we have two ears and one mouth for a reason.).
  7. Train your people to success, not to failure.  By this I mean teach them the correct way to operate, then test them on it.  If/when they fail, don't simply tell them what they did wrong and move on.  Instead, work the problem over so they can create a successful outcome.  It leaves them with a better flavor in their mouths, and you become their trusted leader and peer instead of a tyrant.
  8. Praise your peers and Newbs publicly when they succeed.  We have an internal company newsletter and I regularly am so impressed with some of my coworkers that I write a story about their great work and share it there, for the whole company to recognize.
  9. When there's something a Newb or team member does that must be changed, explain it to them in private so they never are embarrassed in front of others.  Take a "together we can make this even better" attitude, rather than a confrontational one.
  10. Admit when you're wrong.  Say you're sorry in public.  It takes a strong person to do this, but that action only builds confidence and trust from others.  When they know you won't spend time making excuses or shifting blame, and when you can carry the burden of responsibility squarely on your own shoulders,you've set an example for all to follow.

By the time your incoming people have had OTJ and some formal training and worked on some great / challenging projects, you'll develop trust in them, and they in you.  And they've slowly joined your Just Us League.

Do more than just work tasks together if you want your team to smile and be glad to work with each other.  Find ways to build camaraderie monthly at work, and every few weeks after work or on weekends.  I take my team out boating on the Duluth / Superior Harbor and have pizza delivered to the boat.  A warm evening and smooth water with scenic vistas around us--it's a special treat they enjoy, and that I love to share.  We've also gone on outings to an indoor pistol range and made bang-bang noises and laughed at how awful our aim is.  And we've eaten out and had good clean fun at a bar or two.  And we're closer because of it.

Maybe this is above & beyond, but you know your league is tight when you can count on your work peers to show up at your house when a storm has dropped a tree on it, or to be there for you  when you need help moving, or when your car's broken down or you've hit a deer and need a tow and a ride to work or home.

Find out each others' hobbies and share what each are proud of.  My coworkers are amazed when they see me play sax and keyboards and bass in a theatrical production or a wedding dance.  And I'm amazed at their hobbies, too.  Seeing & sharing & talking and being respectful of all.  That's a good way to live & build a Just Us League.



I'm a big proponent of documentation. In relation to this subject, I really like checklists. I know most IT types don't like documentation and especially checklists - they seem unnecessary and/or elementary. But I'll use an example that many of us have experienced.

Several years ago the team I worked on had a request from a department to build a couple of servers. This was a pretty casual environment so everything was done on the phone. The "server guy" built 2 servers with the specs that they had discussed and turned it over to the requestor, who then got the vendor involved for configurations. Several weeks go by and the deadline is upon them. They turn up the server for some final testing and it is miserably slow. Now with deadlines looming and pressure applied the "casual environment" becomes quite heated. The server guy gets the angry call demanding an explanation of why the servers are so slow. He calmly stated that he had built what was requested. Which simply stoked the fires.

Long story short the customer, in this case, hadn't really looked at the requirements, the vendor didn't look at the servers they were provided and the server guy took it that the two of them had decided on the configuration. It was an easy fix, but the tense situation could and should have been avoided. I took it upon myself to build a spreadsheet with dropdowns for the various options. Now when a server or servers are needed the form is sent to the requestor and they are built from that document. It may not solve the root problems but prevents finger pointing and allows for better communications.

Level 20

I've had to deal with some of this recently when two divisions of the company merged together.  This means selecting the right tools going forward and some internal competition that goes on.

Again documentation is key. You can also ensure that those who wish to be the big fish end up in smaller and smaller ponds.

Level 12

I agree on the documentation. One of the first tasks we assign to newbies is to review and update the documentation for their area. Not only do they learn what's what, but we get better insight on them by how they complete this task.

My hiring techniques aim for contributions to the team and the bottom line. Those are tangibles and measurable. But I also value personality. I want a team of different personality types, perspectives, backgrounds, experiences, and such. I am a strong proponent in diversity.

As for assimilation of new talent... I'll give them room to move. I believe that everyone is an adult, a professional. If they tied their own shoes and found their way into the office this morning they can practice good judgment. However, they do not start at the top of the ladder. They need to understand humility and start with the grunt work, menial tasks, work that no one has bothered to streamline or automate (the real go-getters come back to me with plans to automate said tasks!). Also, they spend the first few weeks shadowing my senior admins learning not just the tech ropes but how we interface with the business.

I could go on for days about the nuances. But much like the Justice League the diverse characters are what makes it entertaining, interesting, enriching...

Level 12

The idea of onboarding new staff one OSI layer at a time is brilliant! I am going to try this the next chance I get!

As you do that, consider what you're discovering about them, and what you're asking them to learn.

  • Document these two items
  • Use this information to create pertinent test questions
  • Submit incoming staff to the questions as part of written and practical examinations

Not only will you end up knowing their strengths and weaknesses, but you'll easily discover the areas to budget for training.

It's great to be able to decide to hire the competent people who are already well trained for your environment, but it's even better to efficiently turn people with good personalities into resources that are competent troubleshooters and designers.

More than one of our local I.T. corporations use both a written exam and a practical hands-on test with Test Equipment, to prove a person is more than just a "paper MCSE".

And you'll avoid this problem:


Level 21

I think it really helps to reinforce that we are all normal people outside of the office as well and a great way to do this is with company sponsored team events.  We recently had our team go out for dinner and pool and then we broke into two different groups and did escape rooms which was a super fun event.

Level 15


About the Author
Mo Bacon Mo Shakin' Mo Money Makin'! vHead Geek. Inventor. So Say SMEs. vExpert. Cisco Champion. Child please. The separation is in the preparation.