The Lone Sysadmin

One of my favorite tricks lately to make people understand how serious I am about things is to get them to sign a form.

You want to run your server without backups? I don’t recommend it at all, but I’ll do whatever you say. Just sign this form acknowledging that you know the risks, you know you could lose all your data at any time for any reason (including things I might do), and regardless of cause you don’t hold me accountable for anything.

You want to let your employee take a machine out of the building without following our procedures for wiping the drives? We have a policy against that and it’s a terrible idea, but no big deal. Here’s the form to sign saying that you take complete responsibility for all the data, sensitive or otherwise, on that machine. Why do you have to sign this? Well, this way when the data on that machine leaks out and causes identity theft, etc. I have a “get out of jail free” card. Yes, jail.

The thing is, nobody ever wants to sign these forms and put their name, in writing, on a really bad idea.

Whose fault is it?

It doesn’t matter. Get the problem fixed.

You can figure out who is at fault when you’re discussing how to prevent the problem in the future.

Seth Godin has an interesting post today about stress. His perspective is as a marketer, but his point is universal: people are stressed out almost all the time.

For us system administrators, do we ever just ask ourselves if something we’re doing, a system we’re building, even a tool we’re implementing for ourselves will create or reduce stress?

Why not?

I know some of the tools I use cause more stress than if I didn’t have them, to save very small amounts of time, gather almost useless information, or achieve some political goal. What if we could plot user stress versus time saved? Would we choose our tools, our applications, our systems differently?

Technical presentations are very Darwinian. Do a good one and you get invited to do another. Do one badly and you won’t get any more practice. I’ve survived a number of them now, likely because the audiences got such good sleep during the talk that they tell their friends. :-) Joking aside, I think these six things I do for each presentation have helped a lot. I share them with you.

1. Know your audience and talk at their level.

Before I give a presentation I ask the folks who are coordinating the event about the people I’ll be talking to. Are they advanced users or newbies? Windows, Mac, or UNIX people? Application developers or system administrators? All these help me get a feel for what I need to talk about, and how to talk about it. In a presentation about virtualization will I need to explain all the concepts from the ground up, or can I skip to the advanced topics?

If you are giving a presentation to a general audience you have to aim for the lowest common denominator. However, if you are giving a talk that is billed as advanced, treat your audience that way. Treating advanced users like beginners and vice versa is a great way to lose your audience.

2. The 10/20/30 rule is key.

I am a huge fan of the Guy Kawasaki 10/20/30 rule: 10 slides, 20 minutes, no less than a 30 point font. Keep things short, easy to read, and remember that people are there to hear you talk, not to read your slides. Think of your slides as an outline: a few words, graphics, and photos to help people understand what you’re talking about. A slide is not a bunch of notes, it’s the illustration to a story you’re telling.

I keep any notes separate so I can publish them after the presentation, but also so the audience cannot see them during the presentation. If I talk about code samples, scripts, or output from command-line utilities I’ll put short, easy-to-read blurbs in the slides but publish whole samples or URLs in my notes afterwards.

I go over 10 slides a lot of times because I always opt for bigger, simpler, more readable slides. In that regard I always make graphs and graphics their own whole slide. Since a graph’s legend often gets strange when it is 30 points I skip that and put simple labels in the graph itself. I always avoid color combinations of red & green or blue & yellow for any color blind folks.

3. Pre-authenticate & set everything up in advance.

Is part of your presentation going to be a demo, or require authenticating? Get logged in and set up ahead of time. You’ll save time during the presentation as well as confirm that whatever you are demoing can be connected to (and if you can’t connect someone else can work on the fix while you start talking). More importantly, you’ll also lessen the risk of doing something dumb while the audience watches, like typing your password in the username field. I hate when I do that, and it’s always because I’m answering a question and logging in at the same time.

4. Create another user on your laptop.

I use my laptop for a lot of different things. I don’t want to have to worry about what is in my browser cache, or sitting on my desktop (like a proposal for a client or something). To help this I created a second user on my laptop just for presentations. I set the background to black and made sure it gets its own profile in Firefox and iTunes.

5. Get a good presentation clicker.

I use a Logitech Presenter and it’s easily the coolest device for doing a presentation. First, it’s RF-based so I can wander around. I hate standing behind a boring desk or lectern just so I can advance my slides. Second, it has a timer in it that vibrates, so you know if you need to speed up or slow down. Last, it has a laser pointer. A picture may be worth a thousand words but being able to point at the screen to explain something, especially when answering questions during demos, is priceless.

6. If you feel like you’re losing the audience stop and take some questions.

Stopping for a short Q&A part way through is a great way to wake people up and find out if you’re above or below their technical level. If nobody asks any questions it might signal that they’re lost, the presentation is too basic, or they’re asleep. In my experience if you’ve got good content someone will ask a question and you’ll know where you stand. At the very least a short pause will give you a brief chance to take a deep breath, drink some water, and regroup.

There are lots of other great resources out there. My list here is no substitute for some of the great tutorials, checklists, and tips from people that are professional presenters. Here are a few I really like:

• Garr Reynolds’ Presentation Tips. He also runs the blog “Presentation Zen” which I read. I especially like his analysis of Steve Jobs’ presentations.
• In addition to the aforementioned 10/20/30 rule, Guy Kawasaki has a lot of good material in his blog. I really like his tips on “How to Get a Standing Ovation” and “The Art of Schmoozing.”
• Lifehacker often has articles about presentations. A good one is their recent “Rock Your Presentation with the Right Tools and Apps.” Just don’t forget that like everything else in life, the more complex your presentation gets the more likely it is that something will go wrong.

Some reasons I think lying on your resumé is a bad idea.

People, in general, aren’t good enough at lying to get all the details right.

One little lie ends up needing a whole network of lies to support it. Especially during an interview. You said that you’ve run large mail servers at your previous job. What software did you use? What did you do about spam? Viruses? If you lie about your experience you need to lie about all the details of that experience, too. That gets tricky, because it all has to mesh perfectly.

Even if you can get all the details right you’ll act funny or seem like you’re lying when people ask you about these things. People, in general, are not good enough at lying to mask the “I’m lying, please bust me” body language. You know what? Humans are really good at reading body language, even subconsciously.

Your prospective employer actually knows the truth, or knows someone who knows the truth.

A lot of people working in IT know each other. We talk to each other, run into each other at conferences, and go drink beer together. A lot of times we’ll have worked together at companies, done consulting together, or even have the same hobbies. And once in a while the topic turns to “hey, a guy you work with is applying for one of our open positions. What do you think of them?”

I will never hold the desire to go find a better job against someone, sabotage their chances if the person if I think they’re an asset to our organization, or tell anybody at their current employer anything. I’ve been in that position and it sucks, and as a result I am often a big advocate for the person. Everybody should have the option to go somewhere else if they don’t like quite what they’re doing now.

It gets tough, though, when in the course of conversation it is determined that the person is lying on their resume. In one memorable case it was someone taking credit for something I had done, and the friend that was asking me knew I’d been the guy that did that work. Now, I don’t know all the legalities of hiring someone (that’s what HR is for) but I do know it gets a lot harder when you’ve lied to someone who knows the truth already.

You don’t know who will read your resume. It could be a former coworker, a friend of your boss, or a complete stranger. You don’t know what they’ll know about you already, or what they can find out. So keep the fiction to a minimum.

A background check will show information that conflicts with your story.

Did you fudge dates, overstate your education on your resume, or try to hide something in your past? If it is a matter of public record it is easy to check, and it is better if you explain it up front than appear like you’re trying to hide it. Remember that during a hiring process people are asking themselves “would this person be a good asset to the team?” If people think you’re hiding things you aren’t going to get hired. Instead, find a truthful way to explain it that makes you look good, or at least indicate you learned something.

Heck, even just making up a story about falling in love with a traveling nurse and moving with her to Hawaii to surf for six months is a better way to go. Of course, that might get you in trouble, too, should you run into someone who lived in Hawaii…

At some point you’ll have to do what you claimed you can do.

If an employer is asking questions about things on you’re resume it is probably because you’ll have to do them as part of your job. If that’s the case, and you lied about being able to do something, people will know that right away. You might be able to get away with it if it is simple and can be looked up on the web, but if you are hired to do an HP OpenView implementation and you haven’t ever used OpenView you are probably in trouble.

The big downside to this, aside from getting fired, is then having to explain all of this to the next interview committee.

You just don’t need to lie.

Lying is a house of cards that, more often than not, comes tumbling down. Even if it doesn’t come tumbling down right away there is always the chance that someone in the future will discover the lie. With all the open source software out there, with freely-available server operating systems like Linux, FreeBSD, or even Solaris, and with free developer access to software like Oracle, there is no reason you can’t put a little experience behind your claims.

Besides, training is easy. Most employers know that they can always fill a technical knowledge gap with a book or a training course. Hiring someone who has the right mindset and will fit into the company is the real challenge. So instead of lying be truthful, be honest, be confident, be that person they want to hire, even if you aren’t perfect. Nobody is.

(heard at the theater during a rehearsal)

“Why’d you put your bottle in the trough?” asks the director.

“Keepin’ it cold,” replies the actor, smugly. I’m in character.

“You mean ‘wet’ — that water is really warm.” No you aren’t.

“Huh?”

“It’s a trough, in the sun, in Oklahoma, in summer.” He walks away.

“Huh.”

It’s hard to be in character when you have no idea where your character is.

Four people now have sent me the link to Seth Godin’s “Bobcasting” post.[0]

“I call it that because instead of reaching the masses, it’s just about reaching Bob.”

As a guy named Bob I couldn’t agree more. :-)

In all seriousness, though, his idea is dead on. The key is control. End-user control. Most information doesn’t need to be a popup, an email, or an instant message. It just needs to be out there so that when I’m ready for it I can get it.

As a sysadmin I see this a lot with folks building email alerts into everything. Some of my coworkers get hundreds of status email messages a week, saying everything is good and reporting statistics like number of new user accounts, queries per second, etc. Why can’t that be an RSS feed which can be read at their leisure? Why can’t the instant messages and email be reserved for the things that do really need attention?

——————–

[0] I was doing a lot of traveling last year and was looking for a book to read while flying home from San Francisco. I picked up Small Is the New Big and have been reading his blog ever since.

Guy Kawasaki has a great interview with Jeffrey Pfeffer, author of What Were They Thinking? Two quotes stand out for me:

“sometimes…the best leadership is less leadership. No seed can grow if it is dug up and examined every week, and for people to innovate and get things done, sometimes they need some time and space and resources.”

It does take the right touch, though. Some folks will not get things done when given time and space, and some will flourish. The trick is to know who is who and treat them accordingly.

For example, I like to let a big problem “stew” for a few days before I start working on it. This bothers some of my coworkers who mistake the lack of visible progress for lack of work, and then step in to intervene, sometimes every day. The net result is that I get nothing done because all of my time is spent dealing with the course corrections. If we had stayed on the original course I’d be done.

“…people can’t be creative if they are exhausted. And when people work when they are tired, they make mistakes. If we have learned anything from the quality movement, it is that the cost of finding and fixing mistakes is greater than the cost of preventing them.”

This is why I hate off-hours maintenance windows. What condition am I in at 5 AM? Tired. What do I do when I’m tired? All sorts of things, and I’m sometimes just lucky that the users aren’t awake to see me mess up. The same is true of a long work week. When I am pulling a 70 hour work week because of upgrades, maintenance, etc. I build downtime in there so I stay sharp. My downtime comes in the form of sleeping in, taking a day off, or sometimes just not working on that project one day mid-week to give my brain a break.