January/February 2018 issue of acmqueue

The January/February issue of acmqueue is out now

Everything Sysadmin

System Administration

  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.


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.


Originally published in Queue vol. 13, no. 9
see this item in the ACM Digital Library



Adam Oliner, Archana Ganapathi, Wei Xu - Advances and Challenges in Log Analysis
Logs contain a wealth of information for help in managing systems.

Mark Burgess - Testable System Administration
Models of indeterminism are changing IT management.

Christina Lear - System Administration Soft Skills
How can system administrators reduce stress and conflict in the workplace?

Thomas A. Limoncelli - A Plea to Software Vendors from Sysadmins - 10 Do's and Don'ts
What can software vendors do to make the lives of sysadmins a little easier?


(newest first)

Luke | Thu, 28 Apr 2016 19:42:08 UTC

Right on, on the section about documentation and automation being a value-add for organizations.

colin | Fri, 12 Feb 2016 13:40:57 UTC

Another idea for calendar management:

Schedule a blackout date over the holiday period. We know that allot of staff are taking leave so lets cut down the workload then (if possible).

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.