Everything Sysadmin - @YesThatTom

  Download PDF version of this article PDF

How SysAdmins Devalue Themselves

And how to track on-call coverage


Thomas A. Limoncelli

Q: Dear Tom, How can I devalue my work? Lately I've felt like everyone appreciates me, and, in fact, I'm overpaid and underutilized. Could you help me devalue myself at work?

A: Dear Reader, Absolutely! I know what a pain it is to lug home those big paychecks. It's so distracting to have people constantly patting you on the back. Ouch! Plus, popularity leads to dates with famous musicians and movie stars. (Just ask someone like Taylor Swift or Leonardo DiCaprio.) Who wants that kind of distraction when there's a perfectly good video game to be played?

Here are some time-tested techniques that everyone should know.

Work more than 40 hours each week

This is the simplest, and possibly the most common, technique used by sysadmins. You can easily cut your hourly worth in half by working 80 hours each week. Start by working late one or two nights a week. Then add weekends. Soon you'll be well on your way to a full 80 hours.

Working beyond the hours you are paid is free labor for the company. This reduces your average hourly rate. Why hire more sysadmins when you are willing to take up the slack? Overpaid CEOs say things like, "My pay is commensurate with my responsibilities." Notice that they don't relate their pay to how many hours they work. Neither should you.

Mock what you don't like

If you don't like Microsoft, call it Microsquish. Don't say open source; say "open sores." The more you can sound like a 12-year-old, the better.

If you want to devalue yourself, throw professionalism out the door. Show your disrespect in the most childish way possible. I know one engineer who spells the operating system that he doesn't like "Windoze," even in e-mails to his co-workers and clients who use it. Way to go!

Interrupt other people

Nothing says "I don't want to be respected" like not showing respect to other people. That's why it is important not to let people finish their sentences. Once you've heard enough to know the general idea, just start barking out your reply. It shows you don't care about what other people are saying and they'll return that lack of respect to you.

Not letting people finish their sentences shows them how smart you are. Your brain is so powerful you've developed ESP. Prove it by answering their questions before they've told you what the problems are.

Respect is a two-way street. It's like a boomerang. You show others your disrespect, and they send it right back at ya.

Don't document or automate your operations

This point is a little controversial. Some people think that they increase their value by refusing to document anything. It makes them unfireable. The truth is that employees who keep playbooks and other documentation up to date are highly valued by managers.

Likewise, some sysadmins fear that if they write too much automation, it will put them out of a job. The truth is that if you automate a task out of existence, there will always be more tasks waiting to be automated. The person who does this is a workforce-multiplier: one person enabling others to do the work of many. That's highly valuable.

Therefore, if you want to devalue yourself, don't document or automate. Assure everyone that you'll document something later: resist the temptation to update wikis as you perform a task. When asked to automate anything, just look the person in the eye, sigh, and say, "I'm too busy to save time by automating things."

Focus on technology, not business benefits

That new server you want to buy is awesome, and if the business can't understand that, yell louder.

Some people disagree. They think that each technology purchase should be justified in terms of how it will benefit the business in ways that relate to money or time—for example, a server that will consolidate all sales information, making it possible for salespeople to find the information they need, when they need it. How boring. It's much more fun to explain that it is 20T of SSD-accelerated storage, Intel 5655 CPUs, and triple-redundant power supplies.

If you want to devalue yourself, describe projects in ways that obscure their business value. Use the most detailed technical terms and let people guess the business reason. Act as if the business is there to serve technology, not the other way around.

Only hire people that look like you

Diversity is about valuing the fact that people with different backgrounds bring different skills to the table. Studies find that the addition of a single person with a different background improves a team's productivity.

Productivity? Sounds like the opposite of devaluing yourself. To truly devalue yourself, make sure everyone on your team thinks the same way, has the same skills and similar backgrounds, and makes all the same mistakes.

As I wrote earlier, respect is a two-way street. If you want to devalue yourself, don't value differences.

Be the weird one

Be "the weird one" in your company. It doesn't matter that your co-workers don't understand your obscure references to LOTR, Animaniacs, and Dune. The spice must flow so we can make the bologna to put in our slacks before we head to Mount Doom. Pretend you don't notice the confused looks you get. Surely everyone has read Dune. Don't explain your cultural references and don't stop making them just because nobody understands them.

Many may consider someone who is diverse to be weird, but these are two different concepts. Diversity is about valuing differences. Being weird is about being oblivious to other people's reactions. Diversity requires a commitment to educating and being educated. Being weird is the opposite.

Everyone should be free to fly a freak-flag. If you want to devalue yourself, never explain.

Refer to the server room as the Shire. Don't say "happy birthday," say "happy hatchling day." Any time something has a red button, ask if it is candy-like.

Be difficult to find

You can't be valuable if you don't exist. If you are difficult to find or aren't available when people need you, you aren't providing value to anyone.

Work strange hours. Don't arrive until noon—unless the corporate culture is to arrive at noon; then arrive early.

Either way, make sure your work hours don't overlap well with the people who need you.

Conclusion

If we all make a concerted effort, then all sysadmins, as a community, can make sure that the role of system administrator stays devalued for a very long time.

Q: Dear Tom, We have a very simple on-call schedule, but all the substitutions needed during December make it quite complex. How should we organize it better? For example, our team has a week-long on-call schedule (Monday to Monday). During November and December, however, there is a flurry of e-mail with people requesting to trade days to accommodate various family and holiday responsibilities.

How can we manage all these trades without a zillion e-mails?

A: Dear Reader, You can make a simple on-call trading forum using a shared spreadsheet like Google Sheets.

Create a spreadsheet with the first column being the list of dates. Even though your on-call schedule is weekly, list the individual days. The next column should list who is on call, and a third column can list who is the secondary on call, and so on. Add a column called Notes.

Share the spreadsheet with the team and encourage everyone to use the Notes column to indicate "substitute needed." Someone looking to accumulate favors can find people who need substitutes. Once the substitution is found, update the columns and erase the note.

You now have a way to find unsatisfied requests (look for notes), and you can even do fancy things like write formulas to indicate mistakes such as the same person being both on call and the secondary on call.

Obviously, any substitutions also need to be updated in your monitoring system's pager-duty schedule. I know of no such system, however, that will manage the horse-trading of on-call days so fluidly. The fact that the spreadsheet is multiuser means that no one person has to coordinate it. The entire process becomes self-organizing.

Another useful shared spreadsheet to create is one that charts who will be available when during the holiday season. When you are on call and need assistance, it is good to know whom you can call and who was planning on being out of cellphone range that day. It saves time and frustration.

Another benefit to putting together such a chart is that it lets you check for coverage gaps ahead of time. For example, if only two people on your team know how to fix MongoDB problems, you can use the chart to make sure that at least one of them is available at any given time.

At StackOverflow we set up the availability spreadsheet as follows. The first column lists each day from November 1 until January 7. This covers all the major holidays and then some.

There is a column for each person on the operations team. We share the spreadsheet and ask everyone to enter "available," "not available," or "semi-available" in each cell. "Semi-available" means they are not working but can be reached in an emergency. "Not available" means they will not have any network or cell access. Conditional formatting turns the cells red, green, or yellow as appropriate. These phrases/colors are placed somewhere on the spreadsheet so that people can copy and paste them.

There are some additional columns that we find useful. We list who is on call in one column. Another column is for notes such as "office closed" or reminders of conferences or other potential events. We also place borders on cells to indicate the start of each week. Figure 1 shows an example spreadsheet.

On-call spreadsheet for holiday coverage

Thomas A. Limoncelli is an author, speaker, and system administrator. He is a site reliability engineer at Stack Overflow, Inc. in New York City. His books include The Practice of Cloud Administration (http://the-cloud-book.com) and Time Management for System Administrators. He blogs at EverythingSysadmin.com and tweets at @YesThatTom.

Copyright © 2015 held by owner/author. Publication rights licensed to ACM.

acmqueue

Originally published in Queue vol. 13, no. 9
Comment on this article in the ACM Digital Library





More related articles:

Adam Oliner, Archana Ganapathi, Wei Xu - Advances and Challenges in Log Analysis
Computer-system logs provide a glimpse into the states of a running system. Instrumentation occasionally generates short messages that are collected in a system-specific log. The content and format of logs can vary widely from one system to another and even among components within a system. A printer driver might generate messages indicating that it had trouble communicating with the printer, while a Web server might record which pages were requested and when.


Mark Burgess - Testable System Administration
The methods of system administration have changed little in the past 20 years. While core IT technologies have improved in a multitude of ways, for many if not most organizations system administration is still based on production-line build logistics (aka provisioning) and reactive incident handling. As we progress into an information age, humans will need to work less like the machines they use and embrace knowledge-based approaches. That means exploiting simple (hands-free) automation that leaves us unencumbered to discover patterns and make decisions.


Christina Lear - System Administration Soft Skills
System administration can be both stressful and rewarding. Stress generally comes from outside factors such as conflict between SAs (system administrators) and their colleagues, a lack of resources, a high-interrupt environment, conflicting priorities, and SAs being held responsible for failures outside their control. What can SAs and their managers do to alleviate the stress? There are some well-known interpersonal and time-management techniques that can help, but these can be forgotten in times of crisis or just through force of habit.


Thomas A. Limoncelli - A Plea to Software Vendors from Sysadmins - 10 Do’s and Don’ts
A friend of mine is a grease monkey: the kind of auto enthusiast who rebuilds engines for fun on a Saturday night. He explained to me that certain brands of automobiles were designed in ways to make the mechanic’s job easier. Others, however, were designed as if the company had a pact with the aspirin industry to make sure there are plenty of mechanics with headaches. He said those car companies hate mechanics. I understood completely because, as a system administrator, I can tell when software vendors hate me. It shows in their products.





© ACM, Inc. All Rights Reserved.