No, not backups as in SQL Server backups, but who to tag when someone is out or so slammed with tasks that they could use a little help.

The Biggest Presentation of Our Careers

My second year in the US Air Force, my unit's commander was to give a full fledged multimedia presentation to some 3,000 attendees of the Air Force Information Technology Conference (AFITC). Such things are standard practice today, but in 1996, we were really pushing the envelope. We had one airman who had figured out and understood the multimedia program and had put together the entire presentation. He was a genius at such things and he did an outstanding job. But during one of the test runs there was a glitch, likely due to the software. This airman understood the application well enough to fix the glitch and get the presentation going again. Me and the other co-chair for the conference talked about what happened and how to prepare for it if it happened during the actual presentation. It was then that the realization hit that this airman was the only one we could tap who could overcome such a glitch and get the presentation back on track. As we were talking about this, we also realized that the airman who had coded the online registration system for the conference was the only one in the group who knew the system. We had allowed two "single points of failure" to occur in what was then (and might still be) the largest IT conference for the Department of Defense. Needless to say, we did a lot of sweating that year. Thankfully, things went off with no real issues.

Playing the Role of Super Backup

The following year for the AFITC, I didn't have a prominent position like the year before. I had done my term as conference co-chair and was looking for something more low key and behind the scenes. So I was talking with the airman who had written the registration application and learned he was going to switch over from a CGI based C program to building it in ASP with a (don't snicker, Brent Ozar) Microsoft Access Jet database back-end. I asked a simple question, "Who else in the tech branch is a programmer?" Blank stare. That wasn't the answer I was hoping for.

Our shop was divided into two branches. The program management shop had the project managers for the IT contracts we managed. Our shop managed most of the IT contracts the USAF was allowed to order off of. The other branch was the technical branch, which supported the program management branch. Because of an edict just as I was putting in for my Air Force assignment as a senior at The Citadel, officers weren't programmers any longer. So I was a project manager. Joy. I had additional duties as the webmaster because my bosses knew that just being a project manager wasn't going to cut it. And I realized that I was the only programmer in the project management branch from my time as webmaster. So that meant the only person in the shop who could be his backup was me. I was the only one with a programming background. So backup on the registration system I became. And I subsequently spent a lot of time over in the tech branch. Before I knew it, I ended up taking over other backup responsibilities for the conference, too. It was decided that since I needed to be on the technical team supporting the conference because of the registration system, that it didn't make sense for me to be spending my time on other teams where an officer might traditionally serve. That didn't bother me any, and I jumped in and learned what I needed to learn.

From Backup to Primary on Two Fronts

The first day of the conference, onsite registration was going really well. Then one of the network guys noticed some unusual activity was on the shared network for the vendors. That airman who was primary on the registration system? He was also the best security analyst we had. So that meant he had to rotate off the registration system to go figure out what was going on. We ended up figuring out one of the vendors was doing some sniffing they shouldn't have been doing. And we quickly dispatched one of the conference chairs to give them a cease and desist message. But during the time it took to figure out what was going on, I ended up being in charge of the registration system. Because I was prepared to be the backup, we were fine.

Later in the conference, the technical chair had to go back to the base to get something for the conference (a piece of equipment broke and we didn't have a replacement on site). Because I was the most knowledgable across all the technical fronts, being the backup on most of them, I ended up getting pressed into duty as the technical chair while he was gone. We had prepared for just such an event and when the technical chair said over the radio, "The Reverend (my handle) has the tech lead," everyone switched over immediately. If you've never worked a large conference, even when everything is going smoothly there's a lot of chatter because there's a lot that has to be coordinated and checked. Switching over could have been a major issue. But because we had anticipated the need, we all made sure we were prepared for it.

Rank and Position Doesn't Matter

In both cases I was a backup to someone I outranked. Both people were enlisted and I was an officer. My commander would normally have been hesitant to set up a situation where an officer was a backup to an enlisted person, but he knew everyone involved and he knew we just wanted to see the job done and done right. It was about the unit succeeding, and with that mindset, personal egos and agendas have no place. Because we all had that attitude, we were able to carry out what needed to be done without a lot of fuss. It worked so well that the following year, with a brand new commander, we asked to do the same thing again. He balked until it was pointed out that everything went flawlessly the year before. His trust in us was rewarded, we had another successful conference with no major hiccups on the technical side.

Applying This to IT

When it comes to meeting requirements and expectations, no one person can do it all. Even if you have just an awesome talent on the team, at some point the team has to face one of the following scenarios:

• Mr. Super-Guru is out sick and truly unable to work.
• Ms. Super-Guru #2 is on a well-deserved vacation and is unreachable.
• You want to send Mr. Super-Guru and Ms. Super-Guru #2 to training but that puts them out of office.
• The two Super-Gurus have higher priority tasks and can't break away.

Having personnel capable of backing up every responsibility within a team is crucial for the long-term success of the team. And these can't be backups in name only. They need to know how to do the job. What the standard expectations are, what the normal procedures are, and what are the likely exceptions are all things a backup has to be familiar with. Yes, this means training and sharing and it means time away from that person's primary taskings. But in my experience, it's absolutely essential.

And the backup responsibilities need to be shared around based on skillset and availability. That means that those senior members of the team may be a backup to a junior member for a particular tasking. I have a friend who is a senior Active Directory administrator and security analyst. He is very good at what he does. But he doesn't like taking on backup duties for other systems or for those who are technically lower on the totem pole than he is. This is absolutely the wrong attitude to have. It's about the team succeeding.

Why Is It about the Team Succeeding?

Perception is one good reason if there is no other motivation. When a team does poorly, the perception of those outside of the team is often that everyone on the team failed. It doesn't matter that we had no role to play in the failure. We are part of the team. The team failed. Therefore, in their eyes, we failed. However, exceptional performers are almost always noticed for when a team has a track record of doing well. It may take a bit of time for our particular stars to get noticed, but it will happen. After all, the more folks we help, the more of a possibility someone is going to mention it to the right person at the right time.

Another reason is if we aren't a good backup to others, they may not inclined to be a good backup to us. Then nobody wins. We have infighting within the team, things don't get done in a timely manner, and the folks who are expecting or needing those things to get done aren't happy. And then we have that team does poorly so everyone on the team has failed perception staring at us right between the eyes. So it behooves us to support one another, even if it may seem "below our position" to do so, and to support one another as best as we can.

And not only must each person be prepared as a backup and willing to do the job, but who the backups are needs to be communicated to everyone who might need to know. This does require prior planning and coordination. But speaking from experience, I've seen what happens when someone gets pressed into duty as a backup and no one knows said person is the backup. Then either multiple people start working on the same thing or folks outside the team starting calling in to try and find out who the backup is, tying up team members who shouldn't have been bothered. Put these three things together, and the team should be in good shape.Neglect any of the three, and problems tend to become bigger than they should be.